Przypadki użycia aktualizacji w czasie rzeczywistym
Aktualizacje w czasie rzeczywistym muszą być zawsze publikowane w tych sytuacjach:
- gdy użytkownik anuluje rezerwację w Twoim systemie i slot staje się dostępny;
- Gdy użytkownik zarezerwuje rezerwację w Centrum działań, a dostępny przedział czasu nie jest już dostępny.
- Gdy rezerwacja dokonana w Centrum działań zostanie anulowana po Twojej stronie, na przykład przez sprzedawcę. Musisz zaktualizować rezerwację i dostępność, ponieważ pierwotny przedział czasowy jest znowu dostępny.
Jeśli dodatkowo wdrożysz specyfikację Availability Replace RTU, aktualizacje w czasie rzeczywistym powinny być wydawane w tych sytuacjach:
- Gdy sprzedawca zmieni harmonogram (dostępność) w Twoim systemie.
- Gdy użytkownik zarezerwuje rezerwację w Twoim systemie, a slot dostępności przestanie być dostępny.
-
Jeśli używasz starszej metody integracji z
CheckAvailability, wywołanie serwera rezerwacjiCheckAvailabilityzwraca zasoby reklamowe, które nie odpowiadają rzeczywistym zasobom.
Nie wszystkie wywołania interfejsu API Rezerwacji w Mapach są wymagane. Wymagane są te informacje:
-
notification.partners.bookings.patch(BookingNotification.UpdateBooking)
W zależności od typu integracji mogą być dostępne lub wymagane te opcje:
inventory.partners.availability.replace(InventoryUpdate.BatchServiceAvailability) LUBinventory.partners.merchants.services.availability.replace(InventoryUpdate.ReplaceServiceAvailability)
Aktualizacja rezerwacji RTU
Jeśli w Twoim systemie wprowadzono zmiany w rezerwacji w Centrum działań (np. anulowanie lub modyfikacja), musisz wysłać wiadomość notification.partners.bookings.patch (BookingNotification.UpdateBooking).
Pola, które można modyfikować
statusstartTimedurationpartySizepaymentInformation.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ąp RTU
Dostępne są 2 rodzaje metod zastępowania, które umożliwiają aktualizowanie dostępności:
-
Zastępowanie zbiorcze (
InventoryUpdate.BatchServiceAvailability): całkowicie zastępuje dane o dostępności dla sprzedawcy i wielu usług.- Uwaga: to wywołanie zbiorcze nie gwarantuje wykonania operacji w ramach jednej transakcji. Zwrócone zostaną tylko zaktualizowane sloty dostępności.
-
Pojedyncze zastąpienie (
InventoryUpdate.ReplaceServiceAvailability): całkowicie zastępuje dostępność dla jednego sprzedawcy i usługi.
Więcej informacji znajdziesz w tym dokumentie.
Aktualizacje w czasie rzeczywistym muszą używać tej samej struktury dostępności co dane przesyłane w plikach danych. Muszą użyć jednego z tych elementów:
spotsOpenrecurrence
Wybieranie metody zastępowania do wywołania
Aby określić, która metoda zastępowania jest najbardziej odpowiednia, skorzystaj z tego przewodnika:
- Czy na jedną rezerwację mają wpływ różne usługi? Na przykład strzyżenie i koloryzacja (każda z tych usług jest osobną usługą) są zarezerwowane u stylisty, więc wszystkie usługi powiązane ze stylistą w tym przedziale czasowym 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 zbiorcze
- Uwaga: spodziewamy się, że odpowiedź RTU dotycząca zapasów zostanie wysłana w ciągu 5 minut od momentu wprowadzenia zmiany po Twojej stronie. Dlatego należy sprawdzać i wysyłać aktualizacje co najmniej co 5 minut.
- Nie ma żadnej z tych opcji?
- Single Replace
- Uwaga: możesz użyć wielu wywołań zastępowania pojedynczych wartości, aby emulować wywołanie zastępowania zbiorczego, ale wydajniej będzie użyć pojedynczego wywołania zastępowania zbiorczego.
Aktualizacje w czasie rzeczywistym: otwarty format Spots
Ważne jest, aby używać tego samego formatu w plikach danych, na serwerze rezerwacji i w przypadku aktualizacji w czasie rzeczywistym.
Fragment kodu kanału spots_open wygląda tak:
Krótki opis 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ąpienia, gdy rezerwacja została dokonana na godzinę 15:30:
Zastąp fragment kodu aktualizującego 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 oczekujemy w następnym codziennym pliku danych, jeśli zostanie zarezerwowany nowy slot na godzinę 15:30:
Krótki opis 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, aby używać tego samego formatu w plikach danych, na serwerze rezerwacji i w przypadku aktualizacji w czasie rzeczywistym.
Plik danych, który używa powtórzeń, wygląda tak:
Krótki opis 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ępczego, gdy rezerwacja została dokonana o 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 tego, czego oczekujemy w następnym pliku danych dziennych. Pamiętaj, że chodzi o dostępność całej usługi dla tego sprzedawcy, w tym wszystkich jego wcześniejszych i nowych schedule_exceptions:
Krótki opis 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 bez przerwy, gdy tylko zmienia się dostępność. Jest to dodatkowy, kompleksowy plik danych o dostępności, który należy przesyłać raz dziennie, aby zapewnić synchronizację dostępności między Twoimi systemami a systemami Google.