Варианты использования обновлений в реальном времени
Обновления в реальном времени всегда должны выпускаться в следующих сценариях:
- Когда пользователь отменяет бронирование в вашей системе, и слот становится доступным.
- Когда пользователь бронирует бронирование через Центр действий, а слот доступности больше не доступен.
- Когда бронирование, сделанное через Центр действий, отменено с вашей стороны, например, напрямую продавцом. Вам нужно будет обновить бронирование, а также наличие мест, поскольку исходное место теперь снова доступно.
Кроме того, если вы реализуете Availability replace RTU , обновления в реальном времени должны выпускаться в следующих сценариях:
- Когда продавец меняет свое расписание (доступность) в вашей системе.
- Когда пользователь бронирует бронирование в вашей системе, а слот доступности больше не доступен.
- Если вы используете устаревшую интеграцию с
CheckAvailability
, при вызовеCheckAvailability
сервера бронирования возвращается инвентарь, который не соответствует фактическому инвентарю.
Не все вызовы Maps Booking API являются обязательными. Следующие пункты являются обязательными:
-
notification.partners.bookings.patch
(BookingNotification.UpdateBooking
)
В зависимости от типа интеграции также может быть доступно или необходимо следующее:
-
inventory.partners.availability.replace
(InventoryUpdate.BatchServiceAvailability
) ИЛИinventory.partners.merchants.services.availability.replace
(InventoryUpdate.ReplaceServiceAvailability
)
Обновить бронирование RTU
В случае обновления бронирования Центра действий (например, отмены или изменения) в вашей системе необходимо отправить notification.partners.bookings.patch
( BookingNotification.UpdateBooking
).
Изменяемые поля
-
status
-
startTime
-
duration
-
partySize
-
paymentInformation.prepaymentStatus
Пример отмены
Request: PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/<PARTNER_ID>/bookings/<BOOKING_ID>?updateMask=status Body: { "name": "partners/<PARTNER_ID>/bookings/<BOOKING_ID>", "merchantId": "10001", "serviceId": "1001", "startTime": "2014-10-02T15:01:23.045123456Z", "duration": "3000s", "status": "CANCELED" }
Наличие Заменить RTU
Для обновления доступности доступны два типа методов замены:
- Пакетная замена (
InventoryUpdate.BatchServiceAvailability
): полностью заменяет данные о доступности для продавца и нескольких служб.- Примечание. Этот пакетный вызов не гарантирует атомарность. Будут возвращены только успешно обновленные слоты доступности.
- Одиночная замена (
InventoryUpdate.ReplaceServiceAvailability
): полностью заменяет доступность для одного продавца и услуги.
Для получения более подробной информации используйте следующую ссылку .
Обновления в реальном времени должны использовать ту же структуру доступности, что и данные, отправляемые через каналы. Они должны использовать один из:
-
spotsOpen
-
recurrence
Выбор метода замены для вызова
Используйте следующее руководство, чтобы определить, какой метод замены более подходит:
- Влияет ли одно бронирование на несколько услуг? Например, стрижка и окрашивание (каждая из которых представляет собой отдельную услугу) заказываются у стилиста, поэтому все услуги, привязанные к стилисту для этого временного интервала, должны быть удалены.
- Ваша система будет время от времени синхронизироваться с Google, отправляя все изменения доступности с момента последнего обновления (не рекомендуется).
- Пакетная замена
- Примечание. Мы ожидаем, что RTU инвентаризации будет отправлен в течение 5 минут после обновления на вашей стороне. Поэтому вам следует проверять и отправлять обновления не реже, чем каждые 5 минут.
- Ничего из этого не применимо?
- Одиночная замена
- Примечание. Вы можете использовать несколько вызовов одиночной замены для эмуляции вызова пакетной замены, но было бы более эффективно использовать один вызов пакетной замены.
Обновления в режиме реального времени: открытый формат спотов
Важно использовать один и тот же формат для каналов, сервера бронирования и обновлений в реальном времени.
Фрагмент фида spots_open
выглядит так:
Фрагмент фида
"availability": [ { "merchant_id": "1001", "service_id": "12310", "spots_open": 2, "spots_total": 2, "start_sec": 1412263800, # October 02, 2014 15:30:00 "duration_sec": 1800, "availabilityTag": "1000001" } ]
Для API обновления инвентаря формат тела запроса на замену, когда забронировано место на 15:30:
Заменить фрагмент обновления в реальном времени
{ "extendedServiceAvailability": [ { "merchantId": "1001", "serviceId": "12310", "startTimeRestrict": "2014-10-02T15:01:23.045123456Z", "endTimeRestrict": "2014-10-02T19:01:23.045123456Z", "availability": [ { "startTime": "2014-10-02T15:30:00.00Z", "duration": "3600s", "spotsOpen": "1", "spotsTotal": "2", "availabilityTag": "1000001" } ] } ] }
Вот пример того, что мы ожидаем в следующем ежедневном канале, если будет забронировано новое место в 15:30:
Фрагмент фида
"availability": [ { "merchant_id": "1001", "service_id": "12310", "spots_open": 1, "spots_total": 2, "start_sec": 1412263800, # October 02, 2014 15:30:00 "duration_sec": 1800, "availabilityTag": "1000001" } ]
Обновления в реальном времени: формат повторения
Важно использовать один и тот же формат для каналов, сервера бронирования и обновлений в реальном времени.
Фид, использующий повторение, выглядит так:
Фрагмент фида
"availability": [ { "merchant_id": "1001", "service_id": "12310", "spots_open": 1, "spots_total": 1, "start_sec": 1540890000, # October 30, 2018 9:00:00 AM "duration_sec": 1800, "recurrence": { "repeat_every_sec": 1800, "repeat_until_sec": 1540918800 # October 30, 2018 5:00:00 PM }, "schedule_exception": [ { "time_range": { "begin_sec": 1540902600, # October 30, 2018 12:30:00 PM "end_sec": 1540904400 # October 30, 2018 1:00:00 PM } } ], } ]
Для API обновления инвентаря формат тела запроса на замену, когда зарезервировано место на 15:30, выглядит следующим образом:
{ "extendedServiceAvailability": [ { "merchantId": "1001", "serviceId": "12310", "startTimeRestrict": "2018-10-30T15:01:23.045123456Z", "endTimeRestrict": "2018-10-30T19:01:23.045123456Z", "availability": [ { "startTime": "2018-10-30T15:30:00.00Z", "duration": "3600s", "spotsOpen": "1", "scheduleException": [ { "timeRange": { "startTime": "2018-10-30T12:30:00.00Z", "endTime": "2018-10-30T13:00:00.00Z" } }, { "timeRange": { "startTime": "2018-10-30T15:30:00.00Z", "endTime": "2018-10-30T16:00:00.00Z" } } ] } ] } ] }
Вот пример того, что ожидается в следующем ежедневном канале. Обратите внимание, что это доступность всей службы для этого продавца, а также все его предыдущие и новые schedule_exceptions
:
Фрагмент фида
"availability": [ { "merchant_id": "1001", "service_id": "12310", "spots_open": 1, "spots_total": 1, "start_sec": 1540890000, # October 30, 2018 9:00:00 AM "duration_sec": 1800, "recurrence": { "repeat_every_sec": 1800, "repeat_until_sec": 1540918800 # October 30, 2018 5:00:00 PM }, "schedule_exception": [ { "time_range": { "begin_sec": 1540902600, # October 30, 2018 12:30:00 PM "end_sec": 1540904400 # October 30, 2018 1:00:00 PM } }, { "time_range": { "begin_sec": 1540913400, # October 30, 2018 3:30:00 PM "end_sec": 1540915200 # October 30, 2018 4:00:00 PM } } ], } ]
Когда отправлять обновления в режиме реального времени
Обновления в режиме реального времени должны отправляться постоянно при изменении доступности. Это в дополнение к подробной информации о доступности, которую необходимо отправлять один раз в день, чтобы обеспечить синхронизацию доступности между вашей системой и системой Google.