Przypadki użycia aktualizacji w czasie rzeczywistym
Aktualizacje w czasie rzeczywistym należy zawsze przeprowadzać w tych przypadkach:
- Gdy użytkownik anuluje rezerwację w Twoim systemie i boks będzie dostępny.
- Gdy użytkownik zarezerwuje rezerwację w Zarezerwuj z Google i przedział dostępności nie będzie już dostępny.
- Gdy np. sprzedawca anuluje rezerwację dokonaną za pomocą funkcji Zarezerwuj z Google, u Ciebie. Musisz zaktualizować rezerwację oraz dostępność, ponieważ pierwotny przedział jest już ponownie dostępny.
Dodatkowo, jeśli wdrożysz funkcję Zastąpienie RTU dostępności, aktualizacje w czasie rzeczywistym powinny być udostępniane w tych przypadkach:
- Gdy sprzedawca zmieni swój harmonogram (dostępność) w Twoim systemie.
- Gdy użytkownik zarezerwuje rezerwację w Twoim systemie i przedział dostępności nie będzie już dostępny.
-
Jeśli korzystasz ze starszej integracji z
CheckAvailability
, wywołanie serwera rezerwacjiCheckAvailability
zwraca zasoby reklamowe, które nie są zgodne z rzeczywistymi zasobami reklamowymi.
Nie wszystkie wywołania interfejsu API Map Google są wymagane. Wymagane są:
-
notification.partners.bookings.patch
(BookingNotification.UpdateBooking
)
W zależności od typu integracji dostępne mogą być też te dane:
inventory.partners.availability.replace
(InventoryUpdate.BatchServiceAvailability
) LUBinventory.partners.merchants.services.availability.replace
(InventoryUpdate.ReplaceServiceAvailability
)
Aktualizacja RTU rezerwacji
W przypadku aktualizacji w systemie Zarezerwuj z Google (np. anulowania lub zmodyfikowania) należy wysłać notification.partners.bookings.patch
(BookingNotification.UpdateBooking
).
Pola do zmodyfikowania
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ąpiła RTU
Dostępne są 2 typy metod zastępowania dostępne do zaktualizowania dostępności:
-
Batch Replace (
InventoryUpdate.BatchServiceAvailability
): powoduje całkowite zastąpienie danych o dostępności sprzedawcy i wielu usług.- Uwaga: to wywołanie zbiorcze nie gwarantuje atrakcyjności. Zwrócone zostaną tylko przedziały dostępności, które zostały zaktualizowane.
-
Pojedyncze zastąpienie (
InventoryUpdate.ReplaceServiceAvailability
): całkowicie zastępuje dostępność dla jednego sprzedawcy i jednej usługi.
Więcej informacji znajdziesz w tym artykule.
Aktualizacje w czasie rzeczywistym muszą korzystać z tej samej struktury dostępności co dane wysyłane w plikach danych. Muszą one mieć:
spotsOpen
recurrence
Wybieranie metody zastępowania
Ten przewodnik pomoże Ci określić, która metoda zastępowania jest odpowiednia:
- Czy w ramach jednej rezerwacji wpływa kilka usług? Na przykład strzyżenie i kolorowanie (każda z nich jest osobna usługa) jest zarezerwowane u fryzjera, dlatego wszystkie usługi powiązane z tym stylem powinny zostać usunięte.
- Twój system będzie od czasu do czasu synchronizować się z Google, wysyłając wszystkie zmiany dostępności od ostatniej aktualizacji (niezalecane).
- Zastępowanie grupowe
- Uwaga: raport RTU o zasobach zostanie wysłany w ciągu 5 minut od aktualizacji, która pojawi się po Twojej stronie. Dlatego należy sprawdzać i wysyłać aktualizacje co najmniej co 5 minut.
- Żadna z tych opcji nie pasuje?
- Pojedyncze zastąpienie
- Uwaga: możesz użyć wielu jednokrotnych wywołań zastępowania do emulowania wsadowej operacji zastępowania, ale lepszym rozwiązaniem jest zastosowanie pojedynczej operacji zastępowania.
Aktualizacje w czasie rzeczywistym: Spot Spot Open
W plikach danych, na serwerze rezerwacji i w czasie rzeczywistym należy używać tego samego formatu.
Fragment kodu kanału spots_open
wygląda tak:
Fragment kodu kanału
"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 treść zastępowania żądania jest zarezerwowana na termin 15:30:
Zastąp fragment 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, czego można się spodziewać w następnym kanale dziennym, jeśli zostanie zarezerwowany nowy przedział czasu o 15:30:
Fragment kodu kanału
"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
W plikach danych, na serwerze rezerwacji i w czasie rzeczywistym należy używać tego samego formatu.
Plik danych z powtarzaniem wygląda tak:
Fragment kodu kanału
"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 treść zastępczych żądań w przypadku rezerwacji przedziału czasu 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, czego można się spodziewać w następnym pliku danych. Pamiętaj, że jest to cała dostępność usługi u tego sprzedawcy oraz wszystkie poprzednie i nowe schedule_exceptions
:
Fragment kodu kanału
"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 w sposób ciągły po każdej zmianie dostępności. Jest to uzupełnienie kompleksowego pliku danych o dostępności, który należy przesyłać raz dziennie, aby mieć pewność, że informacje o dostępności są synchronizowane między systemami Twojej firmy i Google.