Структурирование обновлений в реальном времени

Варианты использования обновлений в реальном времени

Обновления в реальном времени всегда должны выпускаться в следующих сценариях:

  • Когда пользователь отменяет бронирование в вашей системе, и слот становится доступным.
  • Когда пользователь бронирует бронирование через Центр действий, а слот доступности больше не доступен.
  • Когда бронирование, сделанное через Центр действий, отменено с вашей стороны, например, напрямую продавцом. Вам нужно будет обновить бронирование, а также наличие мест, поскольку исходное место теперь снова доступно.

Кроме того, если вы реализуете Availability replace RTU , обновления в реальном времени должны выпускаться в следующих сценариях:

  • Когда продавец меняет свое расписание (доступность) в вашей системе.
  • Когда пользователь бронирует бронирование в вашей системе, а слот доступности больше не доступен.
  • Если вы используете устаревшую интеграцию с CheckAvailability , при вызове CheckAvailability сервера бронирования возвращается инвентарь, который не соответствует фактическому инвентарю.

Не все вызовы Maps Booking API являются обязательными. Следующие пункты являются обязательными:

В зависимости от типа интеграции также может быть доступно или необходимо следующее:

Обновить бронирование 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 ): полностью заменяет данные о доступности для нескольких продавцов и служб.
    • Примечание. Этот пакетный вызов не гарантирует атомарность. Будут возвращены только успешно обновленные слоты доступности.
  • Одиночная замена ( 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.