Estructura actualizaciones en tiempo real

Casos de uso para las actualizaciones en tiempo real

Las actualizaciones en tiempo real siempre deben emitirse en las siguientes situaciones:

  • Cuando un usuario cancela una reserva en tu sistema y el horario disponible está disponible.
  • Cuando un usuario hace una reserva a través de Reserva con Google y el horario disponible deja de estar disponible.
  • Cuando se cancela una reserva a través de Reserva con Google, por ejemplo, directamente mediante el comercio. Deberás actualizar la reserva y la disponibilidad, porque el horario original ahora está disponible nuevamente.

Además, si implementas la RTU de reemplazo de disponibilidad, las actualizaciones en tiempo real deben emitirse en las siguientes situaciones:

  • Cuando un comercio cambia su horario (disponibilidad) en tu sistema
  • Cuando un usuario hace una reserva en tu sistema y el horario disponible deja de estar disponible.
  • Si usas la integración heredada con CheckAvailability, cuando una llamada al servidor de reservas CheckAvailability muestra un inventario que no coincide con el inventario real.

No todas las llamadas a la API de Maps Booking son obligatorias. Los siguientes elementos son obligatorios:

Según el tipo de integración, es posible que las siguientes opciones también estén disponibles o se requieran:

Actualizar RTU de la reserva

En caso de que se realice una actualización de una reserva de Reserva con Google (p.ej., cancelada o modificada) en tu sistema, se debe enviar un notification.partners.bookings.patch (BookingNotification.UpdateBooking).

Campos modificables

  • status
  • startTime
  • duration
  • partySize
  • paymentInformation.prepaymentStatus

Ejemplo de cancelación

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 de Availability Replace

Hay dos tipos de métodos de reemplazo disponibles para actualizar tu disponibilidad:

  • Reemplazar por lotes (InventoryUpdate.BatchServiceAvailability): Reemplaza por completo los datos de disponibilidad de un comercio y varios servicios.
    • Nota: Esta llamada por lotes no garantiza la atomicidad. Solo se mostrarán los horarios disponibles actualizados correctamente.
  • Reemplazo único (InventoryUpdate.ReplaceServiceAvailability): Reemplaza por completo la disponibilidad de un solo comercio y servicio.

Usa la siguiente referencia para obtener más detalles.

Las actualizaciones en tiempo real deben usar la misma estructura de disponibilidad que los datos que se envían a través de los feeds. Deben usar una de las siguientes opciones:

  • spotsOpen
  • recurrence

Consulta la guía de estructura de disponibilidad a fin de determinar qué formato es mejor para ti.

Elija un método de reemplazo para llamar

Usa la siguiente guía para determinar qué método de reemplazo es más adecuado:

  • ¿Se ven afectados varios servicios con una sola reserva? Por ejemplo, un corte de cabello y una tintura (cada uno es un Service distinto) se reservan con un estilista, por lo que se deben quitar todos los servicios vinculados al estilista para ese horario.
  • De vez en cuando, tu sistema se sincronizará con el de Google mediante el envío de todos los cambios de disponibilidad desde la última actualización (no recomendado).
    • Reemplazo por lotes
    • Nota: Esperamos que la RTU del inventario se envíe 5 minutos después de que se realice una actualización. Por lo tanto, debes revisar y enviar actualizaciones al menos cada 5 minutos.
  • ¿Ninguna de estas opciones es válida?
    • Reemplazo único
    • Nota: Puedes usar varias llamadas de reemplazo de un solo reemplazo para emular una llamada de reemplazo por lotes, pero sería más eficiente usar una sola llamada de reemplazo por lotes.

Actualizaciones en tiempo real: Formato abierto de spots

Es importante que uses el mismo formato en todos los feeds, el servidor de reservas y las actualizaciones en tiempo real.

Un fragmento del feed spots_open se ve así:

Fragmento de feed

   "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"
          }
    ]

En el caso de la API de actualización de inventario, reemplaza el formato del cuerpo de la solicitud para cuando se reserve un horario de 3:30 p.m.:

Cómo reemplazar el fragmento de actualizaciones en tiempo real

  {
    "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"
          }
        ]
      }
    ]
  }

A continuación, te mostramos un ejemplo de lo que esperamos en el siguiente feed diario, si se reserva un horario nuevo a las 3:30 p.m.:

Fragmento de feed

"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"
        }
      ]

Actualizaciones en tiempo real: Formato de recurrencia

Es importante que uses el mismo formato en todos los feeds, el servidor de reservas y las actualizaciones en tiempo real.

Un feed con recurrencia tiene el siguiente aspecto:

Fragmento de feed

  "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
              }
            }
          ],
        }
      ]

En el caso de la API de Inventory Update, el formato de cuerpo de la solicitud de reemplazo para el horario disponible de un horario disponible de 3:30 p.m. tiene el siguiente aspecto:

  {
    "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"
                }
              }
            ]
          }
        ]
      }
    ]
  }

Este es un ejemplo de lo que se espera en el próximo feed diario. Ten en cuenta que es la disponibilidad del servicio completo para ese comercio, junto con todas sus schedule_exceptions anteriores y nuevas:

Fragmento de feed

   "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
              }
            }
          ],
        }
      ]

Cuándo enviar actualizaciones en tiempo real

Las actualizaciones en tiempo real deben enviarse de forma continua cada vez que cambie la disponibilidad. Esto se suma a un feed de disponibilidad completo que se debe enviar una vez al día, para garantizar que la disponibilidad se sincronice entre tu sistema y el de Google.