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

Structurer des mises à jour en temps réel

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

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

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

En outre, 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 son horaire (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, un appel CheckAvailability au 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 obligatoires. 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)

Mise à jour de la réservation RTU

Si une réservation Actions Center a été modifiée (par exemple, annulée ou modifiée) sur votre système, un notification.partners.bookings.patch (BookingNotification.UpdateBooking) doit être envoyé.

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 dans updateMask par une virgule (par exemple, updateMask=partySize,startTime).

Exemple d'annulation

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é d'un marchand et de plusieurs services.
- Remarque: Cet appel par lot ne garantit pas l'atomicité. Seuls les créneaux de disponibilité mis à jour sont renvoyés.
Remplacement unique (InventoryUpdate.ReplaceServiceAvailability) : remplace complètement la disponibilité d'un marchand et d'un service donnés.

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

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

spotsOpen
recurrence

Choisir une méthode de remplacement à appeler

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

Plusieurs services sont-ils concernés par une seule réservation ? Par exemple, une coupe de cheveux et une coloration (qui sont deux services distincts) sont réservées auprès d'un coiffeur. Tous les services associés à ce coiffeur pour ce créneau horaire doivent donc être supprimés.
- Remplacement par lot
Votre système se synchronisera de temps en temps avec celui de Google en envoyant toutes les modifications de disponibilité depuis la dernière mise à jour (non recommandé).
- Remplacement par lot
- Remarque: L'inventaire RTU devrait être envoyé dans les cinq minutes suivant une mise à jour de votre côté. Vous devez donc vérifier et envoyer les mises à jour au moins toutes les cinq minutes.
Aucune de ces situations ne correspond ?
- Remplacement unique
- Remarque: Vous pouvez utiliser plusieurs appels de remplacement uniques pour émuler un appel de remplacement par lot, mais il est plus efficace d'utiliser un seul appel de remplacement par lot.

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

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

Un extrait de flux spots_open se présente comme suit:

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 lorsqu'un créneau de 15h30 est réservé :

Remplacer l'extrait de code 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"
          }
        ]
      }
    ]
  }

Voici un exemple de ce que vous devriez voir dans le prochain flux quotidien si un nouvel emplacement est réservé à 15h30 :

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:S'il n'y a plus de disponibilité (spots_open est égal à 0), il existe deux formats d'envoi de la requête de remplacement pour l'API Inventory.

Spécification explicite:il s'agit de la méthode recommandée si vous disposez de 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:cette option n'est recommandée que si spots_total = 1 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 la récurrence

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

Un flux qui utilise la récurrence se présente comme suit:

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 lorsqu'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 horaires réservés. En effet, la méthode d'API remplace la disponibilité pour ce service et ce marchand spécifiques. Si vous le remplacez par un autre, il doit s'agir des informations complètes sur la disponibilité de ce service et inclure tous ses créneaux réservés.

Voici un exemple de ce que vous devez inclure dans le prochain flux quotidien. Notez qu'il s'agit de la disponibilité de l'ensemble du service pour ce marchand, ainsi que de tous ses schedule_exceptions précédents et nouveaux:

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 mises à jour en temps réel

Les mises à jour en temps réel doivent être envoyées en continu chaque fois que la disponibilité change. En plus de cela, vous devez envoyer un flux de disponibilité complet une fois par jour pour vous assurer que la disponibilité est synchronisée entre vos systèmes et ceux de Google.