Примеры использования обновлений в реальном времени
Обновления в режиме реального времени должны выпускаться всегда в следующих случаях:
- Когда пользователь отменяет бронирование в вашей системе, и освободившееся место становится доступным.
- Когда пользователь бронирует номер через Центр действий, а доступное время больше недоступно.
- Если бронирование, оформленное через Центр действий, отменяется с вашей стороны, например, непосредственно продавцом, вам потребуется обновить бронирование, а также информацию о наличии мест, поскольку первоначальное место снова стало доступно.
Кроме того, если вы внедряете функцию замены доступных устройств RTU , обновления в реальном времени должны выполняться в следующих сценариях:
- Когда продавец меняет свое расписание (доступность) в вашей системе.
- Когда пользователь бронирует место в вашей системе, а доступное время больше недоступно.
- Если вы используете устаревшую интеграцию с
CheckAvailability, то при вызовеCheckAvailabilityчерез сервер бронирования возвращается информация о наличии мест, которая не соответствует фактическому количеству мест.
Не все вызовы API Maps Booking являются обязательными. Следующие являются обязательными:
-
notification.partners.bookings.patch(BookingNotification.UpdateBooking)
В зависимости от типа интеграции могут быть доступны или необходимы следующие возможности:
-
inventory.partners.availability.replace(InventoryUpdate.BatchServiceAvailability) ORinventory.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": "2025-01-02T15:01:23.045123456Z", "duration": "3000s", "status": "CANCELED" }
Наличие. Замена RTU.
Для обновления вашей доступности доступны два типа методов замены:
- Пакетная замена (
InventoryUpdate.BatchServiceAvailability): Полностью заменяет данные о доступности для нескольких продавцов и сервисов.- Примечание: Этот пакетный вызов не гарантирует атомарность. Будут возвращены только успешно обновленные слоты доступности.
- Single Replace (
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": 1735831800, # January 02, 2025 15:30:00
"duration_sec": 1800,
"availabilityTag": "1000001"
}
]Для API обновления инвентаря формат тела запроса на замену, используемый при бронировании места на 15:30:
Заменить фрагмент кода обновления в реальном времени
{
"extendedServiceAvailability": [
{
"merchantId": "1001",
"serviceId": "12310",
"startTimeRestrict": "2025-01-02T15:01:23.045123456Z",
"endTimeRestrict": "2025-01-02T19:01:23.045123456Z",
"availability": [
{
"startTime": "2025-01-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": 1735831800, # January 02, 2025 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.