आरटीयू का इस्तेमाल मुख्य रूप से उन अपडेट के लिए किया जाता है जिनके बारे में आपको पहले से पता नहीं होता. जैसे, आपातकालीन स्थिति में बंद होने की जानकारी या ऐसा मेटाडेटा जो समय-समय पर बदलता रहता है (जैसे, पहुंचने का अनुमानित समय). अगर आपको बदलाव तुरंत नहीं दिखाने हैं, तो बैच फ़ीड के डेटा को शामिल करने की सुविधा का इस्तेमाल करें. रीयल-टाइम में अपडेट होने की प्रोसेस में पांच मिनट से ज़्यादा समय नहीं लगता.
Google Cloud Platform का सेटअप
- GCP प्रोजेक्ट सेट अप करें. आरटीयू एपीआई को ऐक्सेस करने के लिए, GCP प्रोजेक्ट की ज़रूरत होती है.
- food-support@google.com को एडिटर का ऐक्सेस दें
- अपने Google पीओसी को GCP प्रोजेक्ट नंबर के बारे में बताएं.रीयल-टाइम अपडेट की सुविधा काम करने के लिए, आपका GCP प्रोजेक्ट, Actions Center खाते से जुड़ा होना चाहिए.
- Maps Booking API चालू करें:
- GCP में, एपीआई और सेवाएं > लाइब्रेरी पर जाएं.
- “Google Maps Booking API” खोजें.
- सैंडबॉक्स इंस्टेंस (“Google Maps Booking API (Dev)”) ढूंढें और चालू करें पर क्लिक करें
- प्रोडक्शन इंस्टेंस (“Google Maps Booking API”) ढूंढें और चालू करें पर क्लिक करें
- अपने GCP प्रोजेक्ट के लिए, एडिटर की भूमिका वाला सेवा खाता बनाएं. ज़्यादा जानकारी के लिए, सेवा खाता सेटअप करना लेख पढ़ें.
- पक्का करें कि आपने बैच फ़ीड को उस एनवायरमेंट में अपलोड किया हो जिसमें रीयल-टाइम अपडेट पर काम किया जा रहा है.
- एपीआई की पुष्टि करने के लिए, हम आपको अपनी पसंद की भाषा में Google क्लाइंट लाइब्रेरी इंस्टॉल करने का सुझाव देते हैं. OAuth स्कोप के तौर पर “https://www.googleapis.com/auth/mapsbooking” का इस्तेमाल करें. नीचे दिए गए कोड के सैंपल में, इन लाइब्रेरी का इस्तेमाल किया गया है. ऐसा न करने पर, आपको टोकन एक्सचेंज को मैन्युअल तरीके से मैनेज करना होगा. इसके बारे में OAuth 2.0 का इस्तेमाल करके, Google API को ऐक्सेस करना लेख में बताया गया है.
सेवा खाते का सेटअप
Google के एपीआई को पुष्टि किए गए एचटीटीपीएस अनुरोध भेजने के लिए, आपको सेवा खाते की ज़रूरत होती है. जैसे, रीयल-टाइम अपडेट एपीआई.
सेवा खाता सेट अप करने के लिए, यह तरीका अपनाएं:
- Google Cloud Platform Console को ऐक्सेस करें.
- Actions Center पर मौजूद आपके खाते से भी एक Google Cloud प्रोजेक्ट जुड़ा हुआ है. अगर वह प्रोजेक्ट पहले से नहीं चुना गया है, तो उसे चुनें.
- बाईं ओर मौजूद मेन्यू में, सेवा खाते पर क्लिक करें.
- सेवा खाता बनाएं पर क्लिक करें.
- सेवा खाते का नाम डालें और बनाएं पर क्लिक करें.
- भूमिका चुनें के लिए, प्रोजेक्ट > एडिटर चुनें.
- जारी रखें पर क्लिक करें.
- उपयोगकर्ताओं को सेवा खाते का ऐक्सेस देने के लिए, उन्हें जोड़ें. हालांकि, यह ज़रूरी नहीं है. इसके बाद, हो गया पर क्लिक करें.
- आपने अभी जो सेवा खाता बनाया है उसके लिए, ज़्यादा > कुंजी बनाएं पर क्लिक करें.
- फ़ॉर्मैट के तौर पर JSON चुनें और बनाएं पर क्लिक करें.
- सार्वजनिक/निजी पासकोड का नया जोड़ा जनरेट होने के बाद, उसे अपने कंप्यूटर पर डाउनलोड करें.
एपीआई का इस्तेमाल करना
रीयल-टाइम अपडेट एपीआई, दो तरह की कार्रवाइयों के साथ काम करता है: अपडेट करना और मिटाना. रीयल-टाइम अपडेट एपीआई के ज़रिए नई इकाइयां नहीं जोड़ी जा सकतीं. अगर आपने एक ही एपीआई अनुरोध में कई अपडेट शामिल किए हैं, तो रीयल-टाइम अपडेट को बैच किया जा सकता है. एक एपीआई कॉल में, ज़्यादा से ज़्यादा 1,000 अपडेट एक साथ किए जा सकते हैं. हमारा सुझाव है कि अगर मुमकिन हो, तो आरटीयू के ज़रिए अपडेट भेजने के लिए, फ़्रीक्वेंसी के हिसाब से अपडेट भेजने के बजाय, ट्रिगर के हिसाब से अपडेट भेजने का तरीका इस्तेमाल करें. इसका मतलब है कि जब आपके सिस्टम में डेटा में बदलाव हो, तब Google को रीयल-टाइम अपडेट भेजें.
रीयल-टाइम अपडेट एपीआई, सैंडबॉक्स और प्रोडक्शन, दोनों एनवायरमेंट में काम करता है. सैंडबॉक्स एनवायरमेंट का इस्तेमाल, एपीआई अनुरोधों की जांच करने के लिए किया जाता है. वहीं, प्रोडक्शन एनवायरमेंट का इस्तेमाल, ऑर्डर करने की पूरी प्रोसेस को कंट्रोल करने वाले उपयोगकर्ताओं को दिखने वाले कॉन्टेंट को अपडेट करने के लिए किया जाता है.
- सैंडबॉक्स -
partnerdev-mapsbooking.googleapis.com - प्रोडक्शन -
mapsbooking.googleapis.com
एंडपॉइंट
रीयल-टाइम अपडेट करने वाले एपीआई में, इन्वेंट्री अपडेट के लिए आने वाले अनुरोधों को मैनेज करने के लिए दो एंडपॉइंट होते हैं:
- अपडेट -
/v1alpha/inventory/partners/PARTNER_ID/feeds/google.food_service/record:batchPush - मिटाएं -
/v1alpha/inventory/partners/PARTNER_ID/feeds/google.food_service/record:batchDelete
पैरामीटर PARTNER_ID, Actions Center में खाता और उपयोगकर्ता पेज पर देखा जा सकता है. इसके बारे में नीचे दिए गए स्क्रीनशॉट में बताया गया है.
ऊपर दिए गए स्क्रीनशॉट में, PARTNER_ID की वैल्यू 10000001 को उदाहरण के तौर पर लिया गया है. सैंडबॉक्स और प्रोडक्शन में एपीआई अनुरोध भेजने के लिए, पूरे यूआरएल यहां दिए गए उदाहरणों की तरह दिखेंगे.
सैंडबॉक्स से जुड़ा अपडेट
https://partnerdev-mapsbooking.googleapis.com/v1alpha/inventory/partners/10000001/feeds/google.food_service/record:batchPush
सैंडबॉक्स मिटाएं
https://partnerdev-mapsbooking.googleapis.com/v1alpha/inventory/partners/10000001/feeds/google.food_service/record:batchDelete
प्रोडक्शन से जुड़ा अपडेट
https://mapsbooking.googleapis.com/v1alpha/inventory/partners/10000001/feeds/google.food_service/record:batchPush
Production DELETE
https://mapsbooking.googleapis.com/v1alpha/inventory/partners/10000001/feeds/google.food_service/record:batchDelete
इकाइयां अपडेट की जा रही हैं
अपनी इन्वेंट्री में मौजूद इकाइयों को अपडेट करने के लिए, एचटीटीपी पोस्ट अनुरोध में update एंडपॉइंट का इस्तेमाल करें. हर POST अनुरोध में, 10000001 पैरामीटर के साथ-साथ एक JSON पेलोड शामिल होना चाहिए. इस पेलोड में वह इकाई शामिल होनी चाहिए जिसे आपको अपडेट करना है.
ध्यान दें: पक्का करें कि आपके रोज़ के डेटा फ़ीड में, रीयल-टाइम अपडेट एपीआई के ज़रिए सबमिट किए गए सभी बदलाव शामिल हों. ऐसा न करने पर, हो सकता है कि आपका डेटा पुराना हो.
अनुरोध के पेलोड को अपडेट करना
अनुरोध का मुख्य हिस्सा, रिकॉर्ड की सूची वाला एक JSON ऑब्जेक्ट होता है. हर रिकॉर्ड, अपडेट की जा रही इकाई से मेल खाता है. इसमें proto_record फ़ील्ड और generation_timestamp फ़ील्ड शामिल होता है. generation_timestamp फ़ील्ड से, इकाई के अपडेट होने का समय पता चलता है:
{
"records": [
{
"proto_record":"ServiceData PROTO",
"generation_timestamp":"UPDATE_TIMESTAMP"
}
]
}ServiceData PROTO: अपडेट की जा रही ServiceData इकाई का प्रोटो या JSON अनुवाद.UPDATE_TIMESTAMP: पक्का करें कि आपने अपने बैकएंड सिस्टम में, इकाई के जनरेट होने का टाइमस्टैंप शामिल किया हो. अगर इस फ़ील्ड को शामिल नहीं किया जाता है, तो इसे उस समय पर सेट किया जाएगा जब Google को अनुरोध मिलेगा.batchPushअनुरोध के ज़रिए किसी इकाई को अपडेट करते समय,generation_timestampफ़ील्ड का इस्तेमाल इकाई के वर्शन के लिए किया जाता है. रिलेशनल इन्वेंट्री स्कीमा में, समय की वैल्यू का सही फ़ॉर्मैट देखें.
- पेलोड बॉडी का साइज़ 5 एमबी से ज़्यादा नहीं होना चाहिए.
- साइज़ कम करने के लिए, व्हाइटस्पेस हटाएं.
batchPushअनुरोध में ज़्यादा से ज़्यादा 1,000 अपडेट हो सकते हैं.
उदाहरण
ईटीए अपडेट करना
मान लें कि आपको डिलीवरी सेवा के ईटीए को 30 से 60 मिनट से बदलकर 60 से 90 मिनट करना है. आपके अपडेट में, पूरी सेवा इकाई के लिए JSON होना चाहिए.
मान लें कि कोई सेवा इकाई इस तरह दिखती है:
{ "service": { "service_id": "service/entity002", "service_type": "DELIVERY", "parent_entity_id": "entity002", "lead_time": { "min_lead_time_duration": "600s", "max_lead_time_duration": "1800s" }, "action_link_id": "delivery_link/entity002" } }
एचटीटीपी पोस्ट के ज़रिए किए गए रीयल-टाइम अपडेट यहां दिए गए हैं. अनुरोध के मुख्य हिस्से को पढ़ने में आसानी हो, इसके लिए उसे फ़ॉर्मैट किया गया है:
POST v1alpha/inventory/partners/PARTNER_ID/feeds/google.food_service/record:batchPush Host: mapsbooking.googleapis.com Content-Type: application/json { "records": [{ "proto_record": { "@type": "type.googleapis.com/food.ordering.service.v1.ServiceData", "service" : { "service_id" : "23456/delivery", "service_type" : "DELIVERY", "parent_entity_id" : "23456", "disabled" : "false", "action_link_id": "delivery_link/entity002", "lead_time" : { "min_lead_time_duration" : { "seconds": "3600" }, "max_lead_time_duration" : { "seconds": "5400" } } } }, "generation_timestamp": "2023-09-13T17:11:10.750Z" }] }
एक से ज़्यादा इकाइयों को अपडेट करना
एक ही एपीआई कॉल में, रेस्टोरेंट की कई इकाइयों को अपडेट करने के लिए, अनुरोध के मुख्य हिस्से के proto_record फ़ील्ड में कई रिकॉर्ड शामिल करें.
POST v1alpha/inventory/partners/PARTNER_ID/feeds/google.food_service/record:batchPush Host: mapsbooking.googleapis.com Content-Type: application/json { "records": [{ "proto_record": { "@type": "type.googleapis.com/food.ordering.service.v1.ServiceData", "service" : { "service_id" : "23456/delivery", "service_type" : "DELIVERY", "parent_entity_id" : "23456", "disabled" : "false", "action_link_id": "delivery_link/entity002", "lead_time" : { "min_lead_time_duration" : { "seconds": "1800" }, "max_lead_time_duration" : { "seconds": "3600" } } } }, "generation_timestamp": "2023-09-13T17:11:10.750Z" }, { "proto_record": { "@type": "type.googleapis.com/food.ordering.service.v1.ServiceData", "fee" : { "fee_id" : "12345/delivery_fee", "fee_type" : "DELIVERY", "fixed_amount" : { "currency_code" : "USD", "units" : "10", "nanos" : "0" }, "service_ids": ["service/entity002"] } }, "generation_timestamp" : "2023-09-13T17:11:10.750Z" }] }
इकाइयां मिटाना
अपनी इन्वेंट्री से इकाइयों को मिटाने के लिए, एचटीटीपी POST अनुरोध में DELETE एंडपॉइंट का इस्तेमाल करें. हर POST अनुरोध में PARTNER_ID पैरामीटर के साथ-साथ JSON पेलोड भी शामिल होना चाहिए. इसमें उस इकाई का आइडेंटिफ़ायर होता है जिसे आपको मिटाना है.
ध्यान दें: पक्का करें कि आपके रोज़ के डेटा फ़ीड में, रीयल-टाइम अपडेट एपीआई के ज़रिए सबमिट किए गए सभी बदलाव शामिल हों. ऐसा न करने पर, हर दिन बैच में डेटा ट्रांसफ़र करने की प्रोसेस, रीयल-टाइम में किए गए बदलावों को बदल देगी.
POST v1alpha/inventory/partners/PARTNER_ID/feeds/google.food_service/record:batchDelete Host: mapsbooking.googleapis.com Content-Type: application/json { "records": [{ "proto_record": { "@type": "type.googleapis.com/food.ordering.service.v1.ServiceData", "service" : { "service_id" : "23456/delivery" } }, "delete_time": "2023-09-13T17:11:10.750Z" }, { "proto_record": { "@type": "type.googleapis.com/food.ordering.service.v1.ServiceData", "fee" : { "fee_id" : "12345/delivery_fee" } }, "delete_time" : "2023-09-13T17:11:10.750Z" }] }
इकाइयां जोड़ना
नई इकाइयां जोड़ने के लिए, रीयल-टाइम अपडेट का इस्तेमाल न करें. इससे डेटा में अंतर आ सकता है. इसके बजाय, बैच फ़ीड का इस्तेमाल करें.
पुष्टि और एपीआई रिस्पॉन्स कोड
रीयल-टाइम अपडेट एपीआई कॉल पर दो तरह की पुष्टि की जाती है:
- अनुरोध के लेवल पर - इन पुष्टि करने वाले फ़ंक्शन से यह पता चलता है कि पेलोड, स्कीमा के मुताबिक है या नहीं. साथ ही, हर
proto_recordमेंidऔरtypeफ़ील्ड मौजूद हैं या नहीं. ये जांचें सिंक्रोनस होती हैं और इनके नतीजे, एपीआई रिस्पॉन्स बॉडी में दिखते हैं. जवाब के तौर पर 200 कोड और खाली JSON बॉडी{}का मतलब है कि पुष्टि करने की ये प्रोसेस पूरी हो गई हैं. साथ ही, उस अनुरोध में मौजूद इकाइयों को प्रोसेस करने के लिए लाइन में लगा दिया गया है. 200 के अलावा कोई और रिस्पॉन्स कोड मिलने का मतलब है कि पुष्टि करने की एक या उससे ज़्यादा प्रोसेस पूरी नहीं हुई हैं. इसलिए, पूरे अनुरोध को अस्वीकार कर दिया गया है. इसमें पेलोड में मौजूद सभी इकाइयां शामिल हैं. उदाहरण के लिए, अगर किसीproto_recordमें@typeमौजूद नहीं है, तो गड़बड़ी का यह जवाब दिखता है:
{ "error": { "code": 400, "message": "Record:{...}", "status": "INVALID_ARGUMENT", "details": [ { "@type": "type.googleapis.com/google.rpc.DebugInfo", "detail": "[ORIGINAL ERROR] generic::invalid_argument: Failed to parse one or more rtu records. Record:... The entity type could not be extracted from the entity value." } ] }
- इकाई-स्तर: पेलोड में मौजूद हर इकाई (proto_record) की पुष्टि, स्कीमा के हिसाब से की जाती है. पुष्टि के इस चरण में आने वाली समस्याओं की जानकारी, एपीआई रिस्पॉन्स में नहीं दी जाती है. इन्हें सिर्फ़ Actions Center के आरटीयू रिपोर्टिंग डैशबोर्ड में रिपोर्ट किया जाता है.
ध्यान दें: 200 रिस्पॉन्स कोड का मतलब यह नहीं है कि सभी इकाइयों को सही तरीके से शामिल कर लिया गया है.
एपीआई कोटा
रीयल-टाइम एपीआई अपडेट के लिए,हर 60 सेकंड में 1, 500 अनुरोधों का कोटा होता है. इसका मतलब है कि औसतन हर सेकंड में 25 अनुरोध किए जा सकते हैं. कोटा से ज़्यादा अनुरोध होने पर, Google गड़बड़ी का यह मैसेज दिखाता है:
{
"error": {
"code": 429,
"message": "Insufficient tokens for quota ...",
"status": "RESOURCE_EXHAUSTED",
"details": [...]
}
}इस समस्या को ठीक करने के लिए, कॉल को तब तक फिर से करें, जब तक यह काम न करे. इसके लिए, कॉल के बीच के समय को लगातार बढ़ाते रहें. अगर आपका कोटा नियमित तौर पर खत्म हो जाता है, तो एक एपीआई अनुरोध में ज़्यादा इकाइयां शामिल करें. एक एपीआई कॉल में ज़्यादा से ज़्यादा 1,000 इकाइयां शामिल की जा सकती हैं.
प्रोसेस में लगने वाले समय के बारे में रीयल-टाइम अपडेट
रीयल-टाइम अपडेट के ज़रिए अपडेट की गई इकाई को प्रोसेस होने में पांच मिनट लगते हैं.