Struktura aktualizacji w czasie rzeczywistym

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 rezerwacji CheckAvailability 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) LUB inventory.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

.

Uwaga: name, merchant_id, service_id i należy określić konkretne pole, które ulega zmianie. Wszystkie pozostałe pola są opcjonalne. W niektórych okoliczności, wiele pól może się zmienić jednocześnie, w tym przypadku oddziel przecinkami pola updateMask (np. updateMask=partySize,startTime).

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

Uwaga: funkcja zastępowania RTU dostępności jest dostępna/wymagana tylko w przypadku i integrację społeczną. Jeśli nie masz pewności, skontaktuj się z osobą kontaktową w Google.

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.
  • Zbiorczo zastępuj
• 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"
        }
      ]

Uwaga: jeśli nie będzie już dostępności (spots_open to 0), to 2 możliwe formaty wysłania żądania zastąpienia do interfejsu Inventory API.

• Jawna specyfikacja: jest to zalecana metoda, jeśli mają spots_total > 1

    {
      "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": "0",
              "spotsTotal": "2",
              "availabilityTag": "1000001"
            }
          ]
        }
      ]
    }
  

• Pusta specyfikacja: zalecane tylko wtedy, gdy spots_total = 1 dostępnych dla większości sprzedawców i usług.

    {
    "extendedServiceAvailability": [
      {
        "merchantId": "1001",
        "serviceId": "12310",
        "startTimeRestrict": "2014-10-02T15:01:23.045123456Z",
        "endTimeRestrict": "2014-10-02T19:01:23.045123456Z",
        "availability": [
          {}
        ]
      }
    ]
  }
  

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

Uwaga: aktualizacje w czasie rzeczywistym powinny obejmować wszystkie schedule_exceptions dla które zostały zarezerwowane. Dzieje się tak, ponieważ metoda API zastępuje dostępność usługi i sprzedawcy. Jeśli zastępujesz go czymś innym, zawierać pełne informacje o dostępności usługi oraz uwzględnić wszystkie zarezerwowane boksy.

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.