रीयल-टाइम अपडेट का स्ट्रक्चर

रीयल-टाइम अपडेट के इस्तेमाल के उदाहरण

रीयल-टाइम अपडेट, इन स्थितियों में हमेशा जारी किए जाने चाहिए:

• जब कोई उपयोगकर्ता आपके सिस्टम पर बुकिंग रद्द करता है और स्लॉट उपलब्ध हो जाता है.
• जब कोई उपयोगकर्ता, Actions Center के ज़रिए बुकिंग करता है और बुकिंग के लिए उपलब्ध स्लॉट अब उपलब्ध नहीं है.
• जब Actions Center के ज़रिए की गई बुकिंग को आपकी ओर से रद्द किया जाता है. उदाहरण के लिए, कारोबारी या कंपनी सीधे तौर पर बुकिंग रद्द करती है. आपको बुकिंग के साथ-साथ उपलब्धता की जानकारी भी अपडेट करनी होगी, क्योंकि मूल स्लॉट अब फिर से उपलब्ध है.

इसके अलावा, अगर आपने आरटीयू की जगह पर उपलब्धता की जानकारी देने की सुविधा लागू की है, तो इन स्थितियों में रीयल-टाइम अपडेट जारी किए जाने चाहिए:

• जब कोई कारोबारी या कंपनी, आपके सिस्टम पर अपना शेड्यूल (उपलब्धता) बदलती है.
• जब कोई उपयोगकर्ता आपके सिस्टम पर बुकिंग करता है और बुकिंग के लिए उपलब्ध स्लॉट अब उपलब्ध नहीं है.
• अगर CheckAvailability के साथ लेगसी इंटिग्रेशन का इस्तेमाल किया जा रहा है, तो बुकिंग सर्वर CheckAvailability कॉल से ऐसी इन्वेंट्री मिलती है जो असल इन्वेंट्री से मेल नहीं खाती.

Maps Booking API के सभी कॉल ज़रूरी नहीं हैं. ये चीज़ें ज़रूरी हैं:

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

इंटिग्रेशन के टाइप के आधार पर, ये चीज़ें भी उपलब्ध हो सकती हैं या इनकी ज़रूरत पड़ सकती है:

• inventory.partners.availability.replace (InventoryUpdate.BatchServiceAvailability) या inventory.partners.merchants.services.availability.replace (InventoryUpdate.ReplaceServiceAvailability)

बुकिंग आरटीयू अपडेट करें

अगर आपके सिस्टम पर Actions Center की बुकिंग में कोई बदलाव किया गया है (जैसे, रद्द या बदला गया), तो notification.partners.bookings.patch (BookingNotification.UpdateBooking) भेजा जाना चाहिए.

बदले जा सकने वाले फ़ील्ड

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

ध्यान दें: name, merchant_id, service_id, और बदलाव वाला फ़ील्ड तय किया जाना चाहिए. अन्य सभी फ़ील्ड में जानकारी देना ज़रूरी नहीं है. कुछ मामलों में, एक साथ कई फ़ील्ड बदले जा सकते हैं. ऐसे में, updateMask में फ़ील्ड को कॉमा से अलग करें (जैसे, updateMask=partySize,startTime).

सदस्यता रद्द करने का उदाहरण

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": "2025-01-02T15:01:23.045123456Z",
  "duration": "3000s",
  "status": "CANCELED"
}

Availability Replace RTU

ध्यान दें: उपलब्धता की जानकारी देने वाले RTU को बदलने की सुविधा, सिर्फ़ कुछ तरह के इंटिग्रेशन के लिए उपलब्ध है या ज़रूरी है. अगर आपको इस बारे में नहीं पता, तो कृपया अपने Google POC से संपर्क करके पुष्टि करें.

उपलब्धता की जानकारी अपडेट करने के लिए, दो तरह के रिप्लेसमेंट के तरीके उपलब्ध हैं:

• एक साथ कई वैल्यू बदलना (InventoryUpdate.BatchServiceAvailability): इससे कई कारोबारियों या कंपनियों और सेवाओं के लिए, उपलब्धता का डेटा पूरी तरह से बदल जाता है.
  • ध्यान दें: इस बैच कॉल से, ऐटॉमिकिटी की गारंटी नहीं मिलती. सिर्फ़ उपलब्धता के उन स्लॉट की जानकारी मिलेगी जिन्हें अपडेट किया गया है.
• एक बार में बदलाव करना (InventoryUpdate.ReplaceServiceAvailability): इससे किसी एक कारोबारी या कंपनी और सेवा के लिए, उपलब्धता की जानकारी पूरी तरह से बदल जाती है.

ज़्यादा जानकारी के लिए, कृपया यहां दिया गया रेफ़रंस इस्तेमाल करें.

रीयल-टाइम अपडेट में, उपलब्धता के लिए वही स्ट्रक्चर इस्तेमाल किया जाना चाहिए जो फ़ीड के ज़रिए भेजे गए डेटा में इस्तेमाल किया जाता है. उन्हें इनमें से किसी एक का इस्तेमाल करना होगा:

• spotsOpen
• recurrence

कॉल करने के लिए, बदलने का तरीका चुनना

बदलाव करने का कौनसा तरीका ज़्यादा सही है, यह तय करने के लिए यहां दी गई गाइड का इस्तेमाल करें:

• क्या एक से ज़्यादा कारोबारियों या कंपनियों पर असर पड़ा है? उदाहरण के लिए, एक ही अनुरोध में कई कारोबारियों या कंपनियों के लिए उपलब्धता की जानकारी बदलें.
  • एक साथ कई वीडियो में बदलाव करना
• आपका सिस्टम, Google के सिस्टम के साथ समय-समय पर सिंक होता रहेगा. इसके लिए, वह पिछले अपडेट के बाद से उपलब्धता में हुए सभी बदलावों को भेजेगा. हालांकि, हमारा सुझाव है कि ऐसा न करें.
  • एक साथ कई वीडियो में बदलाव करना
  • ध्यान दें: हमें उम्मीद है कि इन्वेंट्री आरटीयू, आपकी ओर से अपडेट होने के पांच मिनट के अंदर भेज दिया जाएगा. इसलिए, आपको कम से कम हर पांच मिनट में अपडेट की जांच करनी चाहिए और उन्हें भेजना चाहिए.
• इनमें से कोई भी विकल्प लागू नहीं होता या आपको सिर्फ़ एक कारोबारी या सेवा को अपडेट करना है?
  • एक बार में एक ही शब्द बदलना
  • ध्यान दें: एक साथ कई आइटम बदलने के लिए, एक बार में एक आइटम बदलने वाले कई कॉल का इस्तेमाल किया जा सकता है. हालांकि, एक साथ कई आइटम बदलने वाले एक कॉल का इस्तेमाल करना ज़्यादा असरदार होगा

रीयल-टाइम अपडेट: Spots Open Format

सभी फ़ीड, बुकिंग सर्वर, और रीयल-टाइम अपडेट में एक ही फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है.

spots_open फ़ीड स्निपेट ऐसा दिखता है:

फ़ीड स्निपेट

   "availability": [
          {
            "merchant_id": "1001",
            "service_id": "12310",
            "spots_open": 2,
            "spots_total": 2,
            "start_sec": 1735831800, # January 02, 2025 15:30:00
            "duration_sec": 1800,
            "availabilityTag": "1000001"
          }
    ]

इन्वेंट्री अपडेट करने वाले एपीआई के लिए, अनुरोध के मुख्य हिस्से का फ़ॉर्मैट बदलें. यह तब होता है, जब दोपहर 3:30 बजे का स्लॉट बुक हो जाता है:

रीयल-टाइम अपडेट वाले स्निपेट को बदलना

  {
    "extendedServiceAvailability": [
      {
        "merchantId": "1001",
        "serviceId": "12310",
        "startTimeRestrict": "2025-01-02T15:01:23.045123456Z",
        "endTimeRestrict": "2025-01-02T19:01:23.045123456Z",
        "availability": [
          {
            "startTime": "2025-01-02T15:30:00.00Z",
            "duration": "3600s",
            "spotsOpen": "1",
            "spotsTotal": "2",
            "availabilityTag": "1000001"
          }
        ]
      }
    ]
  }

यहां एक उदाहरण दिया गया है. इसमें बताया गया है कि अगर दोपहर 3:30 बजे का नया स्लॉट बुक हो जाता है, तो हम अगले दिन के फ़ीड में क्या उम्मीद करते हैं:

फ़ीड स्निपेट

"availability": [
        {
          "merchant_id": "1001",
          "service_id": "12310",
          "spots_open": 1,
          "spots_total": 2,
          "start_sec": 1735831800, # January 02, 2025 15:30:00
          "duration_sec": 1800,
          "availabilityTag": "1000001"
        }
      ]

ध्यान दें: अगर कोई प्रॉडक्ट उपलब्ध नहीं है (spots_open की वैल्यू 0 है), तो Inventory API के लिए, प्रॉडक्ट बदलने का अनुरोध भेजने के दो तरीके हैं.

• साफ़ तौर पर जानकारी देना: अगर आपके पास spots_total > 1 है, तो यह तरीका इस्तेमाल करने का सुझाव दिया जाता है

    {
      "extendedServiceAvailability": [
        {
          "merchantId": "1001",
          "serviceId": "12310",
          "startTimeRestrict": "2025-01-02T15:01:23.045123456Z",
          "endTimeRestrict": "2025-01-02T19:01:23.045123456Z",
          "availability": [
            {
              "startTime": "2025-01-02T15:30:00.00Z",
              "duration": "3600s",
              "spotsOpen": "0",
              "spotsTotal": "2",
              "availabilityTag": "1000001"
            }
          ]
        }
      ]
    }

• स्पेसिफ़िकेशन की वैल्यू मौजूद नहीं है: इसका सुझाव सिर्फ़ तब दिया जाता है, जब ज़्यादातर कारोबारियों या कंपनियों और सेवाओं के लिए spots_total = 1 की वैल्यू मौजूद न हो.

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

रीयल-टाइम अपडेट: बार-बार होने वाले इवेंट का फ़ॉर्मैट

सभी फ़ीड, बुकिंग सर्वर, और रीयल-टाइम अपडेट में एक ही फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है.

बार-बार होने वाली घटना के लिए इस्तेमाल किया जाने वाला फ़ीड इस तरह दिखता है:

फ़ीड स्निपेट

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

इन्वेंट्री अपडेट एपीआई के लिए, जब दोपहर 3:30 बजे का स्लॉट बुक हो जाता है, तब अनुरोध के मुख्य हिस्से का फ़ॉर्मैट इस तरह दिखता है:

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

ध्यान दें: रीयल-टाइम अपडेट में, बुक किए गए सभी स्लॉट के लिए schedule_exceptions शामिल होने चाहिए. इसकी वजह यह है कि एपीआई का तरीका, उस खास सेवा और कारोबारी या कंपनी के लिए उपलब्धता की जानकारी को बदल देता है. अगर आपको इसे किसी दूसरी सेवा से बदलना है, तो उस सेवा की उपलब्धता के बारे में पूरी जानकारी देनी होगी. साथ ही, बुक किए गए सभी स्लॉट शामिल करने होंगे.

यहां एक उदाहरण दिया गया है, जिसमें बताया गया है कि अगले रोज़ के फ़ीड में क्या जानकारी होनी चाहिए. ध्यान दें कि यह उस कारोबारी या कंपनी के लिए पूरी सेवा की उपलब्धता है. साथ ही, इसके सभी पिछले और नए schedule_exceptions:

फ़ीड स्निपेट

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

रीयल-टाइम अपडेट कब सबमिट करने चाहिए

उपलब्धता में बदलाव होने पर, रीयल-टाइम अपडेट लगातार भेजे जाने चाहिए. यह उपलब्धता की पूरी जानकारी देने वाले फ़ीड के अलावा है. इस फ़ीड को हर दिन एक बार सबमिट किया जाना चाहिए, ताकि यह पक्का किया जा सके कि आपकी और Google की सिस्टम के बीच उपलब्धता की जानकारी सिंक हो गई है.