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 agendamentoCheckAvailability
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:
-
notification.partners.bookings.patch
(BookingNotification.UpdateBooking
)
Dependendo do tipo de integração, as seguintes opções também podem estar disponíveis ou ser necessárias:
inventory.partners.availability.replace
(InventoryUpdate.BatchServiceAvailability
) OUinventory.partners.merchants.services.availability.replace
(InventoryUpdate.ReplaceServiceAvailability
)
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.