Przypadki użycia aktualizacji w czasie rzeczywistym
Aktualizacje w czasie rzeczywistym muszą być zawsze udostępniane w następujących sytuacjach:
- Gdy użytkownik anuluje rezerwację w Twoim systemie, przedział czasu zmieni się i dostępności informacji.
- Gdy użytkownik zarezerwuje rezerwację w Actions Center oraz przedział dostępności nie jest już dostępny.
- Jeśli rezerwacja dokonana w Actions Center zostanie anulowana na Twoim bezpośrednio przez sprzedawcę. Konieczne będzie zaktualizowanie rezerwacji, a także dostępności, ponieważ pierwotny przedział został ustawiony jest znów dostępna.
Ponadto, jeśli zastosujesz Dostępność zastępująca RTU, Aktualizacje w czasie rzeczywistym powinny być udostępniane w następujących przypadkach:
- Gdy sprzedawca zmieni swój harmonogram (dostępność) w Twoim systemie.
- Gdy użytkownik dokonuje rezerwacji w Twoim systemie i przedziału dostępności nie jest już dostępna.
-
Jeśli korzystasz ze starszej integracji z
CheckAvailability
gdy serwer rezerwacjiCheckAvailability
wywołanie zwraca zasoby reklamowe, które nie są zgodne z rzeczywistymi zasobami.
Nie wszystkie wywołania interfejsu Maps Booking API są wymagane. Te elementy są obowiązkowe:
-
notification.partners.bookings.patch
(BookingNotification.UpdateBooking
)
W zależności od typu integracji dostępne lub wymagane mogą być też:
inventory.partners.availability.replace
(InventoryUpdate.BatchServiceAvailability
) LUBinventory.partners.merchants.services.availability.replace
(InventoryUpdate.ReplaceServiceAvailability
)
Zaktualizuj RTU rezerwacji
W przypadku aktualizacji rezerwacji w Centrum działań (np. anulowania lub
zmodyfikowane) w systemie,
notification.partners.bookings.patch
(BookingNotification.UpdateBooking
)
adres e-mail.
Pola, które można modyfikować
status
startTime
duration
partySize
paymentInformation.prepaymentStatus
Przykład anulowania
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" }
Dostępność zastępująca RTU
Istnieją 2 rodzaje metod zastępowania, które pozwalają zaktualizować dostępność:
-
Zbiorcza zamiana (
InventoryUpdate.BatchServiceAvailability
): Całkowicie zastępuje dane o dostępności w przypadku jednego sprzedawcy i wielu usług Google.- Uwaga: to wywołanie zbiorcze nie gwarantuje skuteczności. Tylko zostaną zwrócone przedziały dostępności, które zostały zaktualizowane.
-
Pojedyncze zastąpienie (
InventoryUpdate.ReplaceServiceAvailability
): Całkowicie zastępuje dostępność jednego sprzedawcy i danej usługi.
Użyj następujących referencje, by dowiedzieć się więcej .
Aktualizacje w czasie rzeczywistym muszą korzystać z tej samej struktury dostępności co dane przesyłanych za pomocą plików danych. Musi używać jednej z tych metod:
spotsOpen
recurrence
Wybieranie metody zastąpienia połączenia
Skorzystaj z poniższego przewodnika, aby sprawdzić, która metoda zastępowania jest skuteczniejsza odpowiednie:
- Czy jedna rezerwacja ma wpływ na wiele usług? Na przykład strzyżenie i kolorowania (każda jest odrębną Usługą) umawia się u fryzjera, usługi powiązane ze stylistą dla tego przedziału czasu powinny zostać usunięte.
- System będzie od czasu do czasu synchronizować się z Google, wysyłając wszystkie
zmiany dostępności od ostatniej aktualizacji (niezalecane).
- Zbiorczo zastępuj
- Uwaga: RTU dotyczący zasobów reklamowych zostanie wysłana w ciągu 5 minut od przeprowadzenia aktualizacji po Twojej stronie. Dlatego należy sprawdzać i wysyłać wszelkie aktualizacje co najmniej co 5 minut.
- Żadna z tych sytuacji nie pasuje do Twojej sytuacji?
- Pojedyncza wymiana
- Uwaga: możesz użyć wielu pojedynczych wywołań funkcji zastąpienia, aby emulować funkcji zastępowania, ale lepiej jest użyć pojedynczego połączenie zbiorcze z zastąpieniem
Aktualizacje w czasie rzeczywistym: otwarty format Spotów
Ważne jest używanie tego samego formatu w plikach danych, na serwerze rezerwacji na bieżąco.
Fragment pliku danych spots_open
wygląda tak:
Fragment pliku danych
"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" } ]
W przypadku interfejsu Inventory Update API format treści żądania zastępującego Zarezerwowano przedział na 15:30:
Zastąp fragment kodu z aktualizacjami w czasie rzeczywistym
{ "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" } ] } ] }
Oto przykład tego, czego spodziewamy się w następnym dziennym pliku danych, jeśli nowe miejsce na stronie Zarezerwowano na 15:30:
Fragment pliku danych
"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" } ]
Aktualizacje w czasie rzeczywistym: format powtarzania
Ważne jest używanie tego samego formatu w plikach danych, na serwerze rezerwacji na bieżąco.
Przykład pliku danych z powtarzaniem:
Fragment pliku danych
"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 } } ], } ]
W przypadku interfejsu Inventory Update API format treści żądania zastępującego Rezerwacja na 15:30 wygląda tak:
{ "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" } } ] } ] } ] }
Oto przykład treści, które powinny się pojawić w następnym dziennym pliku danych. Zwróć uwagę, że
to dostępność całej usługi dla tego sprzedawcy oraz wszystkie
poprzednia i nowa treść (schedule_exceptions
):
Fragment pliku danych
"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 } } ], } ]
Kiedy przesyłać aktualizacje w czasie rzeczywistym
Aktualizacje w czasie rzeczywistym powinny być wysyłane na bieżąco po każdej zmianie dostępności. Jest to uzupełnienie kompleksowego pliku danych o dostępności, który należy przesyłane raz dziennie, aby zapewnić synchronizację dostępności między Twoimi systemami i Google.