Como estruturar atualizações em tempo real

Casos de uso para atualizações em tempo real

As atualizações em tempo real precisam ser sempre emitidas nos seguintes cenários:

  • Quando um usuário cancela uma reserva no seu sistema, e o slot se torna disponíveis.
  • Quando um usuário faz uma reserva na Central de ações e não está mais disponível.
  • Quando uma reserva feita pela Central de ações é cancelada no seu por exemplo, diretamente pelo comerciante. Será necessário atualizar o reserva, bem como a disponibilidade, porque o horário original agora é disponível novamente.

Além disso, se você implementar RTU de substituição de disponibilidade As atualizações em tempo real devem ser enviadas nos seguintes cenários:

  • Quando um comerciante altera a programação (disponibilidade) dele no seu sistema.
  • Quando um usuário faz uma reserva no seu sistema e o horário disponível não está mais disponível.
  • Se você estiver usando uma integração legada com CheckAvailability, quando um servidor de agendamento CheckAvailability A chamada retorna um inventário que não corresponde ao inventário real.

Nem todas as chamadas da API Maps Booking são obrigatórias. Os seguintes itens são obrigatórios:

Dependendo do tipo de integração, as seguintes opções também podem estar disponíveis ou ser necessárias:

Atualizar RTU de agendamento

Caso uma atualização tenha sido feita em um agendamento da Central de ações (por exemplo, cancelamento ou modificado) no seu sistema, notification.partners.bookings.patch (BookingNotification.UpdateBooking) deve ser enviado.

Campos modificáveis

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

Exemplo de cancelamento

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 substituição de disponibilidade

Há dois tipos de métodos de substituição disponíveis para atualizar seu disponibilidade:

  • Substituição em lote (InventoryUpdate.BatchServiceAvailability): Substitui completamente os dados de disponibilidade de um comerciante e vários serviços.
    • Observação: essa chamada em lote não garante a atomicidade. Somente horários disponíveis atualizados com sucesso serão retornados.
  • Substituição única (InventoryUpdate.ReplaceServiceAvailability): Substitui completamente a disponibilidade de um único comerciante e serviço.

Use o seguinte: referência para mais detalhes.

As atualizações em tempo real precisam usar a mesma estrutura de disponibilidade que os dados que são enviadas pelos feeds. Eles precisam usar uma das seguintes opções:

  • spotsOpen
  • recurrence

Como escolher um método de substituição para chamar

Use o guia a seguir para ajudar a determinar qual método de substituição é mais adequado:

  • Uma única reserva afeta vários serviços? Por exemplo, corte de cabelo e a coloração (cada um é um serviço distinto) é reservado com um estilista, para que todos serviços vinculados ao estilista naquele horário devem ser removidos.
  • O seu sistema sincronizará com o do Google periodicamente enviando todos os mudanças de disponibilidade desde a última atualização (não recomendado).
    • Substituição em lote
    • Observação: esperamos que a RTU de inventário seja enviada em até cinco minutos após a atualização do seu lado. Por isso, verifique e envie as atualizações pelo menos a cada cinco minutos.
  • Nenhum desses casos se aplica?
    • Substituição única
    • Observação: você pode usar várias chamadas de substituição única para emular uma chamada de substituição em lote, mas seria mais eficiente usar uma única chamada de substituição em lote

Atualizações em tempo real: formato Spots Open

É importante usar o mesmo formato nos feeds, no servidor de agendamento e atualizações em tempo real.

Um snippet de feed spots_open tem esta aparência:

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

Na API Inventory Update, o formato do corpo da solicitação de substituição para quando um O horário é reservado às 15h30:

Substituir snippet de atualizações em tempo 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"
          }
        ]
      }
    ]
  }

Veja um exemplo do que esperamos no próximo feed diário, se um novo espaço em O horário das 15h30 é reservado:

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

Atualizações em tempo real: formato de recorrência

É importante usar o mesmo formato nos feeds, no servidor de agendamento e atualizações em tempo real.

Um feed que usa recorrência tem esta aparência:

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

Na API Inventory Update, o formato do corpo da solicitação de substituição para quando um O horário das 15h30 é reservado tem esta aparência:

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

Veja um exemplo do que é esperado no próximo feed diário. Note que é a disponibilidade de todo o serviço para o comerciante e todos os schedule_exceptions anterior e nova:

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

Quando enviar atualizações em tempo real

As atualizações em tempo real precisam ser enviadas continuamente sempre que a disponibilidade mudar. Isso é mais um feed de disponibilidade abrangente que deve ser enviados uma vez por dia, para garantir que a disponibilidade seja sincronizada entre seu sistema e os do Google.