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

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

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

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

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

• जब कोई व्यापारी/कंपनी/कारोबारी आपके सिस्टम पर, अपना शेड्यूल (खरीदारी के लिए उपलब्धता) बदलता है.
• जब कोई उपयोगकर्ता आपके सिस्टम पर बुकिंग करता है और उपलब्धता स्लॉट उपलब्ध नहीं होता.
• 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)

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

अगर आपके सिस्टम पर, कार्रवाई केंद्र की किसी बुकिंग (उदाहरण के लिए, बुकिंग रद्द करना या बदलाव करना) में कोई अपडेट किया जाता है, तो आपको 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": "2014-10-02T15:01:23.045123456Z",
  "duration": "3000s",
  "status": "CANCELED"
}

RTU में प्रॉडक्ट की उपलब्धता बदलें

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

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

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

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

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

• spotsOpen
• recurrence

कॉल करने के लिए कोई प्रतिस्थापन विधि चुनना

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

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

रीयल-टाइम अपडेट: स्पॉट ओपन फ़ॉर्मैट

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

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

फ़ीड स्निपेट

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

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

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

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

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

फ़ीड स्निपेट

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

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

• साफ़ तौर पर जानकारी देने वाली जानकारी: अगर आपके पास 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"
            }
          ]
        }
      ]
    }
  

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

    {
    "extendedServiceAvailability": [
      {
        "merchantId": "1001",
        "serviceId": "12310",
        "startTimeRestrict": "2014-10-02T15:01:23.045123456Z",
        "endTimeRestrict": "2014-10-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 के सिस्टम के बीच सिंक हो.