Лучшие практики

Следующие рекомендации применимы к сквозной интеграции резервирования Actions Center и могут быть использованы, чтобы избежать проблем с удобством использования и производительностью. Низкое качество данных может привести к удалению инвентаря.

Ленты

• Если для услуги не задана длина, задайте для параметра duration_sec в канале доступности одно из следующих значений:
  • Количество секунд, необходимое для разумного выполнения услуги.

  • Среднее количество секунд, необходимое для завершения услуги.

    Примечание. Если в фиде указана длина 0 , наша система считает этот интервал доступности недействительным и не отображает его в Центре действий.
• Сделайте поле Category в фиде продавца конкретным. Например, ресторан может указать определенный тип, например французский или японский. Подробную информацию см. в разделе «Типы мест для потенциальных значений категорий».

• Задайте условия обслуживания для конкретных продавцов в поле Terms фида продавцов, чтобы под кнопкой «Забронировать» появилось следующее примечание:

  Продолжая, вы соглашаетесь с Условиями обслуживания <merchant> .

  В данном случае «Условия обслуживания» — это ссылка, при нажатии на которую отображается текст, установленный в текстовом поле условий .

• Сжимайте каналы с помощью gzip

Сервер бронирования

Чтобы оптимизировать интеграцию Maps Booking API, выполните следующие действия:

• Всегда используйте временные метки UNIX в формате UTC.
• Создавайте уникальный идентификатор бронирования при вызове нового бронирования в API CreateBooking .

Обновления в реальном времени

Чтобы обеспечить максимальное удобство взаимодействия с пользователем во время процесса бронирования, выполните следующие действия:

• В стандартной реализации используйте API BookingNotifications, чтобы изменить время начала, продолжительность и состояние бронирования, например отмену или неявку встречи.
• При любых изменениях в бронировании в Центре действий с вашей стороны всегда отправляйте обновления бронирования в режиме реального времени из системы с помощью API BookingNotification в режиме реального времени, чтобы данные не устаревали на стороне Центра действий. Например, вы можете отменить, перенести или обновить бронирование из своей системы в Центре действий.
• Для каждого обновления бронирования из UpdateBookingRequest убедитесь, что значение UpdateBookingResponse содержит идентификатор бронирования и что все обновленные поля должны отражать новое значение.
• Если Inventory RTU реализован
  • Обновляйте доступность только партиями по 100–1000 слотов на вызов API.
  • Используйте поля *Restrict (например, startTimeRestrict ), чтобы сузить область редактирования, уменьшить размер полезных данных и избежать повторной отправки слишком большого количества неизмененных данных.
  • Если вы выделяете несколько потоков, реализуйте экспоненциальную отсрочку , чтобы предотвратить ошибки регулирования. Если вы неправильно реализуете экспоненциальную отсрочку, вы можете получить ошибку квоты RESOURCE_EXHAUSTED . Вы можете повторить экспоненциальную отсрочку, чтобы справиться с ними, но если вы обнаружите, что ваш сервер часто достигает квот при запуске ReplaceServiceAvailability , настройте свой сервер на пакетную замену для обеспечения доступности . Это решение предотвращает ошибки квоты, поскольку уменьшает количество вызовов API, которые должен выполнить ваш сервис.
• Установите ограничение времени ответа на вызов API менее одной секунды. Убедитесь, что ваш сервер может обрабатывать пять запросов в секунду (QPS) с задержкой менее секунды как минимум в 95 % случаев.