Se usó la API de Cloud Translation para traducir esta página.

Estructura las actualizaciones en tiempo real

Casos de uso para actualizaciones en tiempo real

Las Actualizaciones en tiempo real siempre se deben emitir en las siguientes situaciones:

Cuando un usuario cancela una reserva en tu sistema, y el horario disponible se convierte en disponibles.
Cuando un usuario hace una reserva a través del Centro de acciones y del el horario disponible ya no está disponible.
Cuando se cancela una reserva realizada a través del Centro de acciones en tu un lado, por ejemplo, directamente. Deberás actualizar y la disponibilidad porque el horario original ahora es nuevamente disponible.

Además, si implementas RTU de Availability Replace Las actualizaciones en tiempo real deben emitirse en las siguientes situaciones:

Ocurre cuando un comercio cambia su horario (disponibilidad) en tu sistema.
Cuando un usuario hace una reserva en tu sistema y el horario disponible ya no está disponible.
Si usas una integración heredada con CheckAvailability: cuando un servidor de reservas CheckAvailability llamada muestra inventario que no coincide con el inventario real.

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

notification.partners.bookings.patch (BookingNotification.UpdateBooking)

Según el tipo de integración, es posible que también se requiera o esté disponible lo siguiente:

inventory.partners.availability.replace (InventoryUpdate.BatchServiceAvailability) O inventory.partners.merchants.services.availability.replace (InventoryUpdate.ReplaceServiceAvailability)

Actualiza la RTU de las reservas

En caso de que se haya actualizado una reserva del Centro de Acciones (p.ej., cancelada o modificados) en tu sistema, una notification.partners.bookings.patch (BookingNotification.UpdateBooking) debe enviarse.

Campos modificables

status
startTime
duration
partySize
paymentInformation.prepaymentStatus

Nota: name, merchant_id, service_id y las se debe especificar el campo específico que está cambiando. Todos los demás campos son opcionales. En algunos en determinadas circunstancias, pueden cambiar varios campos al mismo tiempo. una coma para separar los campos en updateMask (p.ej., updateMask=partySize,startTime).

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:

Reemplazo por lotes (InventoryUpdate.BatchServiceAvailability): Reemplaza completamente los datos de disponibilidad de un comercio y varios de Google Cloud.
- Nota: Esta llamada por lotes no garantiza la atomicidad. Solo se devolverán los horarios disponibles actualizados correctamente.
Reemplazo único (InventoryUpdate.ReplaceServiceAvailability): Reemplaza completamente la disponibilidad de un solo comercio y servicio.

Usa lo siguiente: referencia para obtener más información 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 feeds. Deben usar una de las siguientes opciones:

spotsOpen
recurrence

Cómo elegir un método de reemplazo para llamar

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

¿Se ven afectados varios servicios con una sola reserva? Por ejemplo, un corte de pelo y el coloreo (cada uno es un Service distinto) se reserva con un estilista, por lo que se deben quitar los servicios vinculados al estilista de ese horario disponible.
- Reemplazo por lotes
Tu sistema se sincronizará periódicamente con el de Google al enviar todos cambios en la disponibilidad desde la última actualización (no se recomienda).
- Reemplazo por lotes
- Nota: Esperamos que la RTU del inventario se envíe en un plazo de 5 minutos después de que se produzca la actualización. de tu lado. Por lo tanto, debes revisar y enviar las actualizaciones al menos cada 5 minutos.
¿Ninguna de estas opciones es correcta?
- Reemplazo único
- Nota: Puedes usar varias llamadas de reemplazo único para emular un llamada de reemplazo por lotes, pero sería más eficiente usar un solo llamada de reemplazo por lotes

Actualizaciones en tiempo real: Spots con formato abierto

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

Un fragmento de feed spots_open se ve de la siguiente manera:

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

Para la API de Inventory Update, el formato del cuerpo de la solicitud de reemplazo para cuando un Se reserva un horario disponible para las 3:30 p.m.:

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

Este es un ejemplo de lo que esperamos en el próximo feed diario, si un nuevo horario disponible al 3:30 p.m.: Reservas:

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

Nota: Si no queda más disponibilidad (spots_open es 0), hay 2 formatos posibles para enviar la solicitud de reemplazo a la API de Inventory.

Especificación explícita: Este es el método recomendado si tienen spots_total > 1

  {
    "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": "0",
            "spotsTotal": "2",
            "availabilityTag": "1000001"
          }
        ]
      }
    ]
  }

Especificación vacía: Se recomienda solo si spots_total = 1. para la mayoría de los comercios y servicios.

  {
  "extendedServiceAvailability": [
    {
      "merchantId": "1001",
      "serviceId": "12310",
      "startTimeRestrict": "2014-10-02T15:01:23.045123456Z",
      "endTimeRestrict": "2014-10-02T19:01:23.045123456Z",
      "availability": [
        {}
      ]
    }
  ]
}

Actualizaciones en tiempo real: formato de recurrencia

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

Un feed que utiliza recurrencia se ve así:

Fragmento del 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
              }
            }
          ],
        }
      ]

Para la API de Inventory Update, el formato del cuerpo de la solicitud de reemplazo para cuando un El horario disponible de las 3:30 p.m. se reserva, es decir, de la siguiente manera:

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

Nota: Las actualizaciones en tiempo real deben contener los schedule_exceptions de la horarios disponibles que se reservaron. Esto se debe a que el método de la API reemplaza la disponibilidad para ese servicio y comerciante. Si lo reemplazas por algo más, tiene que ser la información completa sobre la disponibilidad del servicio incluir todos sus espacios reservados.

Este es un ejemplo de lo que se espera en el próximo feed diario. Observa que es la disponibilidad de todo el servicio para ese comercio y de schedule_exceptions anterior y nuevo:

Fragmento del 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 se deben enviar continuamente cada vez que cambie la disponibilidad. Esto se suma al feed de disponibilidad total que se envían una vez al día para garantizar que la disponibilidad se sincronice entre tu sistema y el de Google.