ज़मीन पर काम कर रहे डिवाइसों से, करीब-करीब रीयल-टाइम में मिलने वाले सिग्नल कारोबारों के लिए कई तरह से काम के होते हैं. उदाहरण के लिए, कारोबार इन कामों के लिए इनका इस्तेमाल कर सकते हैं:
- अपने डिवाइसों की परफ़ॉर्मेंस को मॉनिटर करना और शुरू में ही संभावित समस्याओं की पहचान करना
- सटीक ETA और ट्रैक करने की जानकारी देकर, ग्राहक सेवा को बेहतर बनाएं
- कमियों की पहचान करके उन्हें ठीक करें और लागत कम करें
- चालक के व्यवहार पर निगरानी रखने और संभावित खतरों की पहचान करके सुरक्षा को बेहतर बनाएं
- ड्राइवर के रूट और शेड्यूल को ऑप्टिमाइज़ करके, समय को बेहतर बनाएं
- वाहन की जगह और सेवा के घंटों को ट्रैक करके, नियमों का पालन करें
इस दस्तावेज़ में बताया गया है कि डेवलपर Google Maps प्लैटफ़ॉर्म के "मोबिलिटी सेवाएं" ("लास्ट माइल फ़्लीट सलूशन" (LMFS) या "मांग पर राइड और डिलीवरी सलूशन" (ओडीआरडी) से मिलने वाले सिग्नल को कार्रवाई करने लायक कस्टम इवेंट में कैसे बदल सकते हैं. GitHub पर उपलब्ध फ़्लीट इवेंट रेफ़रंस सलूशन के मुख्य सिद्धांत और डिज़ाइन से जुड़े फ़ैसले भी इसमें शामिल हैं.
यह दस्तावेज़ इनके लिए काम का है:
- आर्किटेक्ट को Google Maps Platform की "मोबिलिटी सेवाओं" और इसके मुख्य कॉम्पोनेंट "Fleet Engine" के बारे में जानकारी है. "मोबिलिटी सेवाओं" का इस्तेमाल करने वाले नए लोगों के लिए, हमारा सुझाव है कि आप लास्ट माइल फ़्लीट सलूशन और/या मांग पर राइड और डिलीवरी सलूशन की जानकारी लें. ऐसा आपकी ज़रूरतों के हिसाब से किया जाएगा.
- ऐसे आर्किटेक्ट जो Google Cloud के बारे में जानते हैं. जो लोग Google Cloud का इस्तेमाल पहली बार कर रहे हैं उनके लिए Google Cloud पर स्ट्रीमिंग डेटा पाइपलाइन बनाना, पहले से पढ़ने का सुझाव दिया जाता है.
- अगर आपको अन्य एनवायरमेंट या सॉफ़्टवेयर स्टैक को टारगेट करना है, तो Fleet Engine के इंटिग्रेशन पॉइंट और ज़रूरी बातों को समझने पर ध्यान दें. ये बातें लोगों के लिए अब भी लागू होनी चाहिए.
- ऐसे लोग जो यह जानना चाहते हैं कि जहाज़ों से इवेंट कैसे बनाए जा सकते हैं और उनका इस्तेमाल कैसे किया जा सकता है.
इस दस्तावेज़ के आखिर में, आपको स्ट्रीमिंग सिस्टम के मुख्य एलिमेंट और ध्यान रखने वाली बातों के बारे में बुनियादी जानकारी मिल जाएगी. साथ ही, आपको Google Maps Platform और Google Cloud से मिलने वाले उन ब्लॉक की बुनियादी जानकारी भी मिल जाएगी जो फ़्लीट इवेंट रेफ़रंस सलूशन बनाते हैं.
फ़्लीट इवेंट रेफ़रंस सलूशन की खास जानकारी
फ़्लीट इवेंट रेफ़रंस सलूशन एक ओपन सोर्स सलूशन है. इसकी मदद से, मोबिलिटी ग्राहक और पार्टनर को Fleet Engine और Google Cloud के कॉम्पोनेंट के बारे में मुख्य इवेंट जनरेट करने में मदद मिलती है. फ़िलहाल, रेफ़रंस सलूशन लास्ट माइल फ़्लीट सलूशन इस्तेमाल करने वाले ग्राहकों को मांग पर राइड और डिलीवरी की सुविधा देता है.
यह समाधान, टास्क या यात्राओं से जुड़े खास डेटा में हुए बदलावों के आधार पर अपने-आप इवेंट जनरेट करता है. इन इवेंट का इस्तेमाल, हिस्सेदारों को इस तरह की सूचनाएं भेजने या अपने सभी डिवाइसों के लिए अन्य कार्रवाइयों को ट्रिगर करने के लिए किया जा सकता है.
- टास्क आने के समय में बदलाव का अनुमानित समय
- टास्क पहुंचने के समय के हिसाब से, ETA में बदलाव
- टास्क आने में बचा हुआ समय
- टास्क पहुंचने में बची हुई दूरी
- Task के नतीजे की स्थिति में बदलाव
रेफ़रंस सलूशन के हर कॉम्पोनेंट को आपके कारोबार की ज़रूरतों के हिसाब से पसंद के मुताबिक बनाया जा सकता है.
लॉजिकल बिल्डिंग ब्लॉक
डायग्राम : नीचे दिए गए डायग्राम में हाई लेवल के बिल्डिंग ब्लॉक दिखाए गए हैं, जो फ़्लीट इवेंट रेफ़रंस सलूशन बनाते हैं
रेफ़रंस सलूशन में ये कॉम्पोनेंट शामिल होते हैं:
- इवेंट सोर्स: जहां से ओरिजनल इवेंट की स्ट्रीम आती है. "लास्ट माइल फ़्लीट सलूशन" या "मांग पर राइड और डिलीवरी सलूशन" में क्लाउड लॉगिंग के साथ इंटिग्रेशन है. इससे डेवलपर के लिए उपलब्ध इवेंट स्ट्रीम में फ़्लीट इंजन के आरपीसी कॉल लॉग को बदला जा सकता है. यही मुख्य सोर्स है, जिसे इस्तेमाल किया जा सकता है.
- प्रोसेस जारी है: इस ब्लॉक में रॉ आरपीसी कॉल लॉग को, स्थिति में बदलाव के इवेंट में बदला जाता है. इसकी गिनती लॉग इवेंट की स्ट्रीम से की जाती है. ऐसे बदलाव का पता लगाने के लिए, इस कॉम्पोनेंट को एक स्टेट स्टोर की ज़रूरत होती है, ताकि बदलाव का पता लगाने के लिए आने वाले नए इवेंट की तुलना पिछले इवेंट से की जा सके. ऐसा हो सकता है कि इवेंट में हमेशा
पसंद की सारी जानकारी शामिल न हो. ऐसे मामलों में, यह ब्लॉक ज़रूरत के मुताबिक
बैकएंड को कॉल कर सकता है.
- स्टेट स्टोर: कुछ प्रोसेसिंग फ़्रेमवर्क, अपने-आप ही इंटरमीडिएट डेटा हमेशा उपलब्ध कराते हैं. हालांकि, अगर आपको अपना डेटा स्टोर नहीं करना है, तो खुद से स्थिति सेव करने के लिए, ये वाहन और इवेंट टाइप के लिए अलग-अलग होने चाहिए. इसलिए, K-V डेटा को लंबे समय तक बनाए रखने के लिए सेवा सही होती है.
- सिंक (कस्टम इवेंट): स्थिति में बदलाव का पता लगाए गए ऐसे किसी भी ऐप्लिकेशन या सेवा के लिए उपलब्ध कराया जाना चाहिए जिसे इसका फ़ायदा मिल सके. इसलिए, डाउनस्ट्रीम इस्तेमाल करने के लिए, इस कस्टम इवेंट को इवेंट डिलीवरी सिस्टम पर पब्लिश किया जा सकता है.
- डाउनस्ट्रीम सेवा: ऐसा कोड जो जनरेट किए गए इवेंट का इस्तेमाल करता है और आपके इस्तेमाल के हिसाब से खास कार्रवाइयां करता है.
सेवा चुनना
जब "लास्ट माइल फ़्लीट सलूशन" या "ऑन-डिमांड राइड्स ऐंड डिलीवरी सलूशन" (2023 की तीसरी तिमाही के आखिर में उपलब्ध होगा) के लिए रेफ़रंस सलूशन लागू करने की बात आती है, तो "सोर्स" और "सिंक '' के लिए टेक्नोलॉजी चुनने का विकल्प आसान होता है. दूसरी ओर, "प्रोसेस जारी है" में कई विकल्प मौजूद हैं. रेफ़रंस समाधान ने Google की इन सेवाओं को चुना है.
डायग्राम : इस डायग्राम में, रेफ़रंस सलूशन लागू करने के लिए Google Cloud सेवा को दिखाया गया है
क्लाउड प्रोजेक्ट का लेआउट
हमारा सुझाव है कि आप डिफ़ॉल्ट रूप से कई प्रोजेक्ट के डिप्लॉयमेंट का इस्तेमाल करें. ऐसा इसलिए है, ताकि Google Maps Platform और Google Cloud के इस्तेमाल के डेटा को साफ़-साफ़ अलग किया जा सके और उन्हें बिलिंग के लिए आपकी पसंद के मुताबिक बनाया जा सके.
इवेंट का स्रोत
"लास्ट माइल फ़्लीट सॉल्यूशन" और "ऑन-डिमांड राइड और डिलीवरी सलूशन" क्लाउड लॉगिंग पर एपीआई अनुरोध और रिस्पॉन्स पेलोड लिखें. क्लाउड लॉगिंग, पसंद की एक या उससे ज़्यादा सेवाओं को लॉग डिलीवर करता है. Cloud Pub/Sub को रूट करना यहां सबसे अच्छा विकल्प है. इससे, लॉग को कोडिंग के बिना ही इवेंट स्ट्रीम में बदला जा सकता है.
- लॉग करना | फ़्लीट परफ़ॉर्मेंस (LMFS उपयोगकर्ताओं के लिए)
- लॉग करना | यात्रा और ऑर्डर प्रोग्रेस (ओडीआरडी उपयोगकर्ताओं के लिए)
- Pub/Sub पर रूट किए गए लॉग देखना : लॉग इन करना → Pub/Sub इंटिग्रेशन की खास जानकारी
सिंक
Google Cloud में, Cloud Pub/Sub करीब-करीब रीयल टाइम में मैसेज डिलीवर करने का पसंदीदा सिस्टम है. जिस तरह सोर्स के इवेंट, Pub/Sub में डिलीवर किए जाते हैं उसी तरह कस्टम इवेंट भी Pub/Sub पर डाउनस्ट्रीम इस्तेमाल के लिए पब्लिश किए जाते हैं.
डेटा प्रोसेस करना
ये कॉम्पोनेंट, इवेंट प्रोसेस करने में भूमिका निभाते हैं. दूसरे बिल्डिंग ब्लॉक की तरह, प्रोसेसिंग वाले कॉम्पोनेंट भी बिना सर्वर वाले होते हैं और इनकी स्केलिंग होती है.
- शुरुआती रिलीज़ के लिए, कंप्यूट प्लैटफ़ॉर्म के तौर पर Cloud Functions
- बिना सर्वर वाली टेक्नोलॉजी की लागत को मैनेज करने के लिए, स्केलिंग कंट्रोल का इस्तेमाल करें
- Fleet Engine से जुड़े एपीआई के लिए क्लाइंट लाइब्रेरी की उपलब्धता के आधार पर, Java को प्रोग्रामिंग भाषा माना जाता है. इससे एपीआई को आसानी से लागू किया जा सकता है
- सरकारी स्टोर के तौर पर Cloud Firestore
- सर्वरलेस की-वैल्यू स्टोर
- अपस्ट्रीम और डाउनस्ट्रीम कॉम्पोनेंट के साथ इंटिग्रेशन पॉइंट के तौर पर, Cloud Pub/Sub
- करीब-करीब रीयल-टाइम इंटिग्रेशन
फ़ंक्शन को डिफ़ॉल्ट सेटिंग के साथ ऐसे ही इस्तेमाल किया जा सकता है, लेकिन इन्हें फिर से कॉन्फ़िगर भी किया जा सकता है. कॉन्फ़िगरेशन पैरामीटर, डिप्लॉयमेंट स्क्रिप्ट की मदद से सेट किए जाते हैं और इन्हें संबंधित टेराफ़ॉर्म मॉड्यूल README में दर्ज किया जाता है.
*ध्यान दें: इस रेफ़रंस सलूशन में, ऐसे अन्य तरीकों को रिलीज़ करने की योजना है जिनसे अलग-अलग ज़रूरी शर्तों को पूरा करने में मदद मिल सकती है.
डिप्लॉयमेंट
पहचान फ़ाइल के डिप्लॉयमेंट की प्रोसेस को बार-बार किया जा सकता है. साथ ही, इसे अपनी पसंद के मुताबिक बनाया जा सकता है, सोर्स कोड से कंट्रोल किया जा सकता है, और सुरक्षित बनाया जा सकता है. इसके लिए, terraform को ऑटोमेशन टूल के तौर पर चुना गया है. टेरेस पर सबसे ज़्यादा इस्तेमाल किया जाने वाला IaC (कोड के तौर पर इंफ़्रास्ट्रक्चर) टूल है, जो Google Cloud के साथ बेहतर तरीके से काम करता है.
- Google Cloud Platform प्रोवाइडर: ऐसे संसाधन के दस्तावेज़ जो "Google Cloud Platform की सेवा देने वाली कंपनी" के साथ काम करता हो
- Terraform इस्तेमाल करने के सबसे सही तरीके: Google Cloud में अपनाने के सबसे अच्छे तरीके के बारे में बेहतर दिशा-निर्देश
- Terraform Registry: ऐसे अतिरिक्त मॉड्यूल जो Google और समुदाय के साथ काम करते हैं
टेराफ़ॉर्म मॉड्यूल
एक बड़ा मोनोलिथिक रेफ़रंस सलूशन डिप्लॉयमेंट मॉड्यूल बनाने के बजाय, ऑटोमेशन के ऐसे ब्लॉक हैं जिन्हें फिर से इस्तेमाल किया जा सकता है. इन्हें Teraform मॉड्यूल के तौर पर लागू किया गया है. इन्हें अलग से इस्तेमाल किया जा सकता है. मॉड्यूल कई तरह के कॉन्फ़िगर किए जा सकने वाले वैरिएबल उपलब्ध कराते हैं. इनमें से ज़्यादातर की डिफ़ॉल्ट वैल्यू होती हैं, ताकि आप तेज़ी से अपना काम शुरू कर सकें. हालांकि, इन्हें अपनी ज़रूरतों और प्राथमिकताओं के हिसाब से कस्टमाइज़ किया जा सकता है.
रेफ़रंस सलूशन में शामिल मॉड्यूल:
- फ़्लीट इंजन लॉगिंग कॉन्फ़िगरेशन: Fleet Engine के साथ इस्तेमाल करने के लिए, क्लाउड लॉगिंग से जुड़े कॉन्फ़िगरेशन को ऑटोमेट करें. रेफ़रंस सलूशन में, इसका इस्तेमाल Fleet Engine से जुड़े लॉग को किसी तय Pub/Sub विषय पर रूट करने के लिए किया जाता है.
- फ़्लीट इवेंट क्लाउड फ़ंक्शन डिप्लॉयमेंट: इसमें सैंपल फ़ंक्शन कोड का डिप्लॉयमेंट शामिल होता है. साथ ही, यह सुरक्षित क्रॉस-प्रोजेक्ट इंटिग्रेशन के लिए ज़रूरी अनुमति सेटिंग के ऑटोमेशन को मैनेज भी करता है.
- पूरे रेफ़रंस सलूशन का डिप्लॉयमेंट: पिछले दो मॉड्यूल पर कॉल किया जाता है और पूरे सलूशन को रैप किया जाता है.
सुरक्षा
IAM को Google Cloud की सुरक्षा से जुड़े सबसे सही तरीकों के साथ-साथ, कम से कम अधिकारों के सिद्धांत लागू करने के लिए अपनाया गया है. जैसे, सेवा खाते की पहचान चुराना. Google Cloud की सुविधाओं के बारे में जानने के लिए, यहां दिए गए लेख पढ़ें. इनसे, आपको सुरक्षा पर ज़्यादा कंट्रोल मिलता है.
अगली कार्रवाइयां
अब आपके पास फ़्लीट इवेंट रेफ़रंस सलूशन ऐक्सेस करने और इसे एक्सप्लोर करने के लिए तैयार है. शुरू करने के लिए, GitHub पर जाएं.
अन्य जानकारी
अपनी ज़रूरी शर्तें इकट्ठा करें
हमारा सुझाव है कि आप इस प्रोसेस की शुरुआत में ही अपनी ज़रूरी शर्तें पूरी कर लें.
सबसे पहले, यह बताएं कि आपको आस-पास के रीयल टाइम इवेंट में दिलचस्पी क्यों है या आपको उन्हें इस्तेमाल करने की ज़रूरत क्यों है. यहां कुछ सवाल दिए गए हैं, जिनकी मदद से अपनी ज़रूरतों को पूरा किया जा सकता है.
- इवेंट स्ट्रीम को काम का बनाने के लिए, कौनसी जानकारी ज़रूरी है?
- क्या नतीजा सिर्फ़ Google की सेवाओं में कैप्चर किए गए या तैयार किए गए डेटा से लिया जा सकता है? इसके अलावा, क्या इंटिग्रेट किए गए बाहरी सिस्टम की मदद से, डेटा को बेहतर बनाना ज़रूरी है? अगर हां, तो वे सिस्टम क्या हैं और उनमें कौनसे इंटिग्रेशन इंटरफ़ेस उपलब्ध हैं?
- एक कारोबार के तौर पर, आपको किन मेट्रिक का आकलन करना है? इनके बारे में जानकारी कैसे दी जाती है?
- सभी इवेंट की मेट्रिक को कैलकुलेट करने के लिए, किस तरह के एग्रीगेशन की ज़रूरत होगी? लॉजिकल चरणों का लेआउट बनाने की कोशिश करें. (उदा. संसाधन की कमी वाले घंटों के दौरान परफ़ॉर्मेंस का पता लगाने के लिए, सबसे ज़्यादा व्यस्त घंटों के दौरान फ़्लीट के अलग-अलग हिस्सों में ईटीए/एटीए की तुलना, एसएलओ से करें.
- आपकी दिलचस्पी इवेंट पर आधारित मॉडल में क्यों है या बैच के बजाय? क्या यह
वीडियो स्ट्रीम होने और उसके दिखने के समय को कम करने के लिए है या ढीली जोड़ी जा सकने वाली इंटिग्रेशन
और तेज़ी से काम करने के लिए है?
- अगर इंतज़ार का समय कम करना है, तो "कम" तय करें. मिनट? सेकंड? सब-सेकंड? और इंतज़ार का समय कितना है?
- क्या आपने पहले ही एक टीम के तौर पर टेक्नोलॉजी स्टैक और इससे जुड़े कौशल में निवेश किया है? अगर हां, तो यह क्या है और इससे कौनसे इंटिग्रेशन पॉइंट मिलते हैं?
- क्या कोई ऐसी शर्त है जिसे आपके मौजूदा सिस्टम पूरा नहीं कर पाते या उसमें समस्या हो सकती है? ऐसा, आपके डिवाइसों से होने वाले इवेंट को प्रोसेस करते समय हो सकता है?
डिज़ाइन से जुड़े सिद्धांत
सोचने की प्रक्रिया अपनाना हमेशा मददगार साबित होता है. इससे एक जैसे डिज़ाइन वाले फ़ैसले लेने में मदद मिलती है. खास तौर पर, जब आपके पास चुनने के लिए कई विकल्प होते हैं.
- डिफ़ॉल्ट से आसान विकल्प.
- डिफ़ॉल्ट रूप से 'टाइम-टू-वैल्यू' पर सेट होता है. कम कोड, लोअर लर्निंग कर्व.
- इंतज़ार के समय और परफ़ॉर्मेंस के लिए, तय किए गए समय का पालन करें, न कि सबसे ज़्यादा ऑप्टिमाइज़ेशन के लिए. साथ ही, बहुत ज़्यादा ऑप्टिमाइज़ेशन से बचें, क्योंकि इससे अक्सर काम मुश्किल होता है.
- यही बात लागत के लिए भी लागू होती है. किफ़ायती रखें. हो सकता है कि आप अभी उस राज्य में न हों जहां आप कारोबार के लिए बढ़िया, लेकिन ज़्यादा महंगी सेवाएं देने का वादा करें.
- एक्सपेरिमेंट के तौर पर, स्केलिंग जितनी ज़रूरी हो सकती है उतना ही ज़रूरी है. ऐसे प्लैटफ़ॉर्म का इस्तेमाल करें जो बड़े पैमाने पर बड़े पैमाने पर बड़े पैमाने पर काम करने और बड़े पैमाने पर काम करने की सुविधा देता हो. इस तरह, बिना कुछ किए खर्च करने से बचा जा सकता है. हमेशा चालू रहने वाली इन्फ़्रास्ट्रक्चर की मदद से, परफ़ॉर्मेंस को बेहतर बनाने पर कभी-कभी विचार किया जा सकता है. ऐसा तब किया जा सकता है, जब आपको भरोसा हो कि इसकी ज़रूरतें पूरी हैं.
- निरीक्षण और मापें, ताकि आप बाद में पहचान कर सकें कि आगे कहां काम करना है.
- सेवाओं को बिना किसी रुकावट के रखें. इससे बाद में टुकड़ों को स्वैप करना आसान हो जाता है.
- आख़िर में, सुरक्षा का स्तर कम नहीं हो सकता. सार्वजनिक क्लाउड पर काम करने वाली सेवा के लिए, सिस्टम का कोई भी असुरक्षित दरवाज़ा नहीं हो सकता.
स्ट्रीमिंग कॉन्सेप्ट
अगर आपके लिए इवेंट या स्ट्रीमिंग का इस्तेमाल अभी-अभी शुरू हुआ है, तो कुछ मुख्य बातों के बारे में जानना ज़रूरी है. इनमें से कुछ कॉन्सेप्ट, बैच प्रोसेसिंग से काफ़ी अलग हो सकते हैं.
- स्केल : बैच प्रोसेसिंग से उलट, जहां आपको आम तौर पर स्ट्रीमिंग के लिए, प्रोसेस किए जाने वाले डेटा के बारे में अच्छा आइडिया मिलता है. किसी शहर में ट्रैफ़िक जाम की वजह से, उस इलाके की किसी खास जगह से अचानक बहुत सारी घटनाएं पैदा हो सकती हैं. हालांकि, ऐसी स्थिति में भी आपको उसे प्रोसेस करना होगा.
- विंडोविंग : इवेंट को एक-एक करके प्रोसेस करने के बजाय, अक्सर यही होता है कि आपको कंप्यूटेशन की इकाई के तौर पर इवेंट को छोटी "विंडो" में, टाइमलाइन पर ग्रुप करना है. विंडो तय करने की कई रणनीतियां होती हैं, जैसे "फ़िक्स विंडो (उदाहरण के लिए, हर कैलेंडर दिन)", "स्लाइडिंग विंडो (पिछले पांच मिनट के दौरान)", "सेशन विंडो (इस यात्रा के दौरान)", जिनमें से आपको इनमें से चुनना चाहिए. विंडो जितनी लंबी होगी, नतीजे देने में उतनी ही ज़्यादा देरी होगी. अपनी शर्तों को पूरा करने वाला सही मॉडल और कॉन्फ़िगरेशन चुनें.
- ट्रिगर करना : ऐसे भी मामले हैं जिनमें आपके पास बहुत लंबी विंडो रखने के अलावा कोई विकल्प नहीं होगा. फिर भी, इवेंट तैयार करने के लिए विंडो के आखिर में इंतज़ार नहीं करना चाहिए, बल्कि बीच-बीच में इंटरमीडिएट नतीजे अपनाना चाहिए. इस सिद्धांत को इस्तेमाल के उन मामलों में लागू किया जा सकता है जहां पहले झटपट नतीजे दिखाने में इसकी वैल्यू होती है और फिर बाद में उन्हें ठीक किया जा सकता है. मान लें कि डिलीवरी के 25%, 50%, 75% हिस्से पर इंटरमीडिएट स्थिति का उत्सर्जन होना चाहिए.
- ऑर्डर करना : यह ज़रूरी नहीं है कि इवेंट, सिस्टम तक उसी क्रम में पहुंचें जिस क्रम में उसे जनरेट किया गया था. खासकर मोबाइल नेटवर्क पर कम्यूनिकेशन के इस्तेमाल के मामलों में, जो देरी और जटिल रूटिंग पाथ को जोड़ता है. आपको "इवेंट का समय" (जब इवेंट असल में घटता है) और "प्रोसेस टाइम" (जब इवेंट, सिस्टम में पहुंचता है) के बीच का फ़र्क़ पता होना चाहिए और उसी के हिसाब से इवेंट को मैनेज करना चाहिए. आम तौर पर, आपको इवेंट को "इवेंट के समय" के आधार पर प्रोसेस करना है.
- मैसेज डिलीवरी - कम से कम एक बार बनाम एक बार: अलग-अलग इवेंट प्लैटफ़ॉर्म पर ये अलग-अलग तरीके से काम करते हैं. अपने इस्तेमाल के उदाहरण के आधार पर, आपको दोबारा कोशिश करने या डुप्लीकेट कॉपी हटाने की रणनीतियों पर विचार करना होगा.
- पूरी जानकारी : जिस तरह क्रम में बदलाव करने पर मैसेज गायब हो जाते हैं. ऐप्लिकेशन या डिवाइस बंद होने की ये वजहें हो सकती हैं जैसे डिवाइस की बैटरी लाइफ़, फ़ोन को अनजाने में हुआ नुकसान, टनल में कनेक्शन टूट गया हो या फिर कोई मैसेज मिला हो, जो किसी खुली जगह पर मिला हो. अधूरा होने से आपके नतीजों पर कैसे असर पड़ेगा?
यह पूरी सूची नहीं है, बल्कि यह परिचय है. यहां कुछ ऐसे लेख दिए गए हैं जिनका सुझाव दिया जाता है.
योगदानकर्ता
Google इस दस्तावेज़ का रखरखाव करता है. मूल रूप से इन योगदान देने वालों ने इसे लिखा है.
मुख्य लेखक:
- मैरी पिश्नी | प्रॉडक्ट मैनेजर, Google Maps Platform
- एथल बाओ| सॉफ़्टवेयर इंजीनियर, Google Maps Platform
- मोहनाद अल्मिस्की | सॉफ़्टवेयर इंजीनियर, Google Maps Platform
- नायोया मोरितानी | सलूशन इंजीनियर, Google Maps Platform