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 cas suivants:

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

De plus, si vous mettez en œuvre Disponibilité Replace – Mises à jour en temps réel, Les mises à jour en temps réel doivent être émises dans les cas suivants:

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

Tous les appels de l'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 mise à jour des mises à jour en temps réel pour les réservations

En cas de modification d'une réservation effectuée dans le Centre d'actions (par exemple, annulation ou modifiées) sur votre système, une notification.partners.bookings.patch (BookingNotification.UpdateBooking) doit être envoyé.

Champs modifiables

• status
• startTime
• duration
• partySize
• paymentInformation.prepaymentStatus

<ph type="x-smartling-placeholder">

</ph> Remarque:name, merchant_id, service_id et les attributs un champ spécifique qui change doit être spécifié. Tous les autres sont facultatifs. Dans certains plusieurs champs peuvent changer en même temps. séparez les champs dans 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

<ph type="x-smartling-placeholder">

</ph> Remarque:Le remplacement de disponibilité des mises à jour en temps réel n'est disponible/obligatoire que pour certains types de l'intégration. En cas de doute, veuillez vous adresser à votre contact Google.

Il existe deux types de méthodes de remplacement pour mettre à jour votre disponibilité:

• Batch Replace (InventoryUpdate.BatchServiceAvailability): Remplace complètement les données de disponibilité d'un marchand et plusieurs services.
  • Remarque: Cet appel par lot ne garantit pas l'atomicité. Uniquement les créneaux de disponibilité mis à jour avec succès sont renvoyés.
• Single Replace (InventoryUpdate.ReplaceServiceAvailability): Remplace complètement la disponibilité pour un seul marchand et un seul service.

Veuillez utiliser le code suivant : référence pour en savoir plus plus de détails.

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

• spotsOpen
• recurrence

Choisir une méthode de remplacement à appeler

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

• Une seule réservation a-t-elle un impact sur plusieurs services ? Par exemple, une coupe de cheveux et la coloration (chacune étant un service distinct) est réservée par un coiffeur, afin que tous les services associés au styliste pour ce créneau horaire doivent être supprimés.
  • Remplacement par lot
• Votre système se synchronisera de temps en temps avec celui de Google en envoyant modifications de la disponibilité depuis la dernière mise à jour (non recommandé).
  • Remplacement par lot
  • Remarque: La mise à jour en temps réel "Inventory" devrait être envoyée dans les cinq minutes suivant une mise à jour. de votre côté. Nous vous conseillons donc de vérifier et d'envoyer des mises à jour au moins toutes les cinq minutes.
• Aucune de ces réponses ?
  • Remplacement simple
  • Remarque: Vous pouvez utiliser plusieurs appels de remplacement uniques pour émuler une 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 ouvert Spots

Il est important d'utiliser le même format pour les flux, le serveur de réservation et 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, le format du corps de la requête de remplacement lorsqu'un Le créneau de 15h30 est réservé :

Remplacer l'extrait de code "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 à quoi nous nous attendons dans le prochain flux quotidien : 15h30 est réservée :

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

<ph type="x-smartling-placeholder">

</ph> Remarque:S'il ne reste plus de disponibilité (spots_open est égal à 0), il existe deux formats possibles pour envoyer la requête de remplacement pour l'API Inventory.

• Spécification explicite:il s'agit de la méthode recommandée si vous ont 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 valeur 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 en temps réel.

Voici à quoi ressemble un flux utilisant 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 lorsqu'un Le créneau de 15h30 est réservé, ressemble à ceci :

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

<ph type="x-smartling-placeholder">

</ph> Remarque:Les mises à jour en temps réel doivent contenir l'ensemble des schedule_exceptions pour la valeur des emplacements réservés. Cela s'explique par le fait que la méthode API remplace la disponibilité pour cette ressource et le marchand. Si vous le remplacez par autre chose, il doit fournir des informations complètes sur la disponibilité de ce service ; inclure tous ses créneaux réservés ;

Voici un exemple de ce qui est attendu dans le prochain flux quotidien. Notez qu'il correspond à la disponibilité totale du service pour ce marchand, l'ancien et le nouveau schedule_exceptions:

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

Des mises à jour en temps réel doivent être envoyées en continu dès que la disponibilité change. Cela s'ajoute à un flux "Disponibilité" complet, est envoyé une fois par jour, afin de synchroniser la disponibilité entre vos systèmes et ceux de Google.