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 appelCheckAvailabilitydu 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) OUinventory.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
statusstartTimedurationpartySizepaymentInformation.prepaymentStatus
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:
spotsOpenrecurrence
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.
- 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"
}
]
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"
}
}
]
}
]
}
]
}
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.