Cette page a été traduite par l'API Cloud Translation.

Mises à jour en temps réel de la structure

Cas d'utilisation des mises à jour en temps réel

Les Mises à jour en temps réel doivent toujours être émises dans les scénarios suivants:

Lorsqu'un utilisateur annule une réservation sur votre système et que l'emplacement devient disponible.
Lorsqu'un utilisateur effectue une réservation via le Centre d'actions et que le créneau de disponibilité n'est plus disponible.
Lorsqu'une réservation effectuée via le Centre d'actions est annulée de votre côté (par exemple, par le marchand directement). Vous devrez mettre à jour la réservation ainsi que la disponibilité, car le créneau d'origine est à nouveau disponible.

De plus, si vous implémentez Availability Replace RTU, des mises à jour en temps réel doivent être émises dans les scénarios suivants:

Lorsqu'un marchand modifie ses horaires (disponibilité) dans votre système.
Lorsqu'un utilisateur effectue une réservation sur votre système et que le créneau de disponibilité n'est plus disponible.
Si vous utilisez une ancienne intégration avec CheckAvailability, lorsqu'un appel CheckAvailability du serveur de réservation renvoie un inventaire qui ne correspond pas à l'inventaire réel.

Tous les appels d'API Maps Booking ne sont pas requis. Les éléments suivants sont obligatoires:

notification.partners.bookings.patch (BookingNotification.UpdateBooking)

Selon le type d'intégration, les éléments suivants peuvent également être disponibles ou requis:

inventory.partners.availability.replace (InventoryUpdate.BatchServiceAvailability) OU inventory.partners.merchants.services.availability.replace (InventoryUpdate.ReplaceServiceAvailability)

Mettre à jour la réservation en temps réel

En cas de mise à jour d'une réservation Actions Center (par exemple, annulée ou modifiée) dans votre système, vous devez envoyer une notification notification.partners.bookings.patch (BookingNotification.UpdateBooking).

Champs modifiables

status
startTime
duration
partySize
paymentInformation.prepaymentStatus

Remarque:name, merchant_id, service_id et le champ spécifique qui change doivent être spécifiés. Tous les autres sont facultatifs. Dans certains cas, plusieurs champs peuvent changer en même temps. Dans ce cas, séparez les champs de updateMask par une virgule (par exemple, updateMask=partySize,startTime).

Exemple de résiliation

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

Availability Replace – Mises à jour en temps réel

Deux types de méthodes de remplacement sont disponibles pour mettre à jour votre disponibilité:

Remplacement par lot (InventoryUpdate.BatchServiceAvailability) : remplace complètement les données de disponibilité pour un marchand et plusieurs services.
- Remarque: Cet appel par lot ne garantit pas l'atomicité. Seuls les créneaux de disponibilité mis à jour sont renvoyés.
Single Replace (Remplacement unique) (InventoryUpdate.ReplaceServiceAvailability) : remplace complètement la disponibilité pour un seul marchand et un seul service.

Pour en savoir plus, consultez cette documentation de référence.

Les mises à jour en temps réel doivent utiliser la même structure de disponibilité que les données envoyées via les flux. Il doit utiliser l'un des éléments suivants:

spotsOpen
recurrence

Choisir une méthode de remplacement à appeler

Utilisez le guide suivant pour déterminer la méthode de remplacement la plus adaptée:

Une seule réservation affecte-t-elle plusieurs services ? Par exemple, un salon de coiffure et de coloration (chacun étant un service distinct) est réservé auprès d'un styliste. Tous les services associés au styliste pour ce créneau horaire doivent donc être supprimés.
- Remplacement par lot
De temps en temps, votre système se synchronisera avec Google en envoyant toutes les modifications de disponibilité depuis la dernière mise à jour (non recommandé).
- Remplacement par lot
- Remarque: La mise à jour en temps réel de l'inventaire est censée être envoyée dans les cinq minutes suivant une mise à jour de votre part. Vous devez donc vérifier et envoyer des mises à jour au moins toutes les cinq minutes.
Aucune de ces options ne correspond ?
- Remplacement unique
- Remarque: Vous pouvez utiliser plusieurs appels de remplacement uniques pour émuler un appel de remplacement par lot, mais il serait plus efficace d'utiliser un seul appel de remplacement par lot.

Mises à jour en temps réel: format ouvert Spots

Il est important d'utiliser le même format dans les flux, le serveur de réservation et les mises à jour en temps réel.

Voici à quoi ressemble un extrait de flux spots_open:

Extrait de flux

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

Pour l'API Inventory Update, format du corps de la requête de remplacement au moment où un créneau de 15h30 est réservé :

Remplacer l'extrait des mises à jour en temps réel

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

Si un nouveau créneau horaire à 15h30 est réservé :

Extrait de flux

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

Remarque:Dans le cas où il ne reste plus aucune disponibilité (spots_open correspond à 0), deux formats sont possibles pour envoyer la demande de remplacement pour l'API Inventory.

Spécification explicite:méthode recommandée si vous avez 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"
          }
        ]
      }
    ]
  }

Spécification vide:n'est recommandée que si la valeur spots_total = 1 est définie pour la plupart des marchands et des services.

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

Mises à jour en temps réel: format de récurrence

Il est important d'utiliser le même format dans les flux, le serveur de réservation et les mises à jour en temps réel.

Voici à quoi ressemble un flux qui utilise la récurrence:

Extrait de flux

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

Pour l'API Inventory Update, le format du corps de la requête de remplacement au moment où un créneau de 15h30 est réservé se présente comme suit :

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

Remarque:Les mises à jour en temps réel doivent contenir tous les schedule_exceptions pour les créneaux réservés. En effet, la méthode API remplace la disponibilité pour ce service et ce marchand spécifiques. Si vous la remplacez par un autre, il doit s'agir d'informations complètes sur la disponibilité du service et inclure tous ses créneaux réservés.

Voici un exemple de ce qui est attendu dans le prochain flux quotidien. Notez qu'il s'agit de la disponibilité de l'ensemble du service pour ce marchand, ainsi que de toutes ses schedule_exceptions, anciennes et nouvelles:

Extrait de flux

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

Quand envoyer des informations en temps réel

Des mises à jour en temps réel doivent être envoyées en continu dès que la disponibilité change. Ce flux s'ajoute au flux de disponibilité complet que vous devez envoyer une fois par jour pour garantir la synchronisation de la disponibilité entre votre système et celui de Google.