Zapier या Make ऑटोमेशन को नए जियोकोडिंग होस्ट पर माइग्रेट करना
जियोकोडिंग चरण पर बने नो-कोड ऑटोमेशन के लिए कस्टम कोड से अलग माइग्रेशन तरीका चाहिए। यह बदलाव कैसे संभालें, यहाँ बताया गया है।
बदलने से पहले प्रोवाइडर के बीच एरर कोड मैप करना
माइग्रेशन में सबसे ज़्यादा ध्यान सफल रिस्पॉन्स पर जाता है, क्योंकि डेमो में वही दिखते हैं और परीक्षण का पहला दौर आम तौर पर उन्हीं को जाँचता है। एरर रिस्पॉन्स पर बहुत कम ध्यान जाता है, और यह ठीक उल्टा है, क्योंकि जब किसी एप्लिकेशन के नीचे प्रदाता बदलता है तो प्रोडक्शन में अक्सर एरर हैंडलिंग कोड ही सबसे पहले और सबसे साफ़ दिखने वाले तरीके से टूटता है।
हर जियोकोडिंग और लोकेशन डेटा प्रदाता के विफलता बताने के अपने तरीके होते हैं: कुछ सिर्फ़ HTTP स्टेटस कोड का उपयोग करते हैं, कुछ बाकी हर तरह से 200-स्टेटस वाले JSON रिस्पॉन्स के अंदर एक status फ़ील्ड रखते हैं, कुछ "कोई परिणाम नहीं मिला" और "अमान्य अनुरोध" को अलग-अलग कोड से अलग करते हैं, और कुछ दोनों को एक सामान्य एरर में समेट देते हैं। किसी एप्लिकेशन का retry तर्क, उपयोगकर्ता को दिखने वाले एरर संदेश और मॉनिटरिंग अलर्ट आम तौर पर किसी एक विशिष्ट प्रदाता के एरर तरीकों के इर्द-गिर्द बने होते हैं, कभी-कभी बिना किसी के उस निर्भरता को स्पष्ट रूप से दर्ज किए।
प्रदाता बदलने से पहले पुराने प्रदाता के एरर रिस्पॉन्स और नए प्रदाता के एरर रिस्पॉन्स के बीच एक स्पष्ट मैपिंग टेबल बनाना सार्थक है, जिसमें कम से कम ये शामिल हों:
- मान्य लेकिन बिना मिलान वाली क्वेरी के लिए कोई परिणाम न मिलना, जो गलत ढंग से बने या अमान्य अनुरोध से अलग है
- रेट लिमिट पार होना, और क्या रिस्पॉन्स में यह जानकारी है कि दोबारा कब कोशिश करें
- ऑथेंटिकेशन विफलताएँ, जिनमें समाप्त, छूटे हुए या गलत ढंग से बने क्रेडेंशियल शामिल हैं
- प्रदाता की तरफ़ सर्वर-साइड एरर, जो क्लाइंट-साइड अनुरोध एरर से अलग हैं
- प्रदाता-विशिष्ट कोई भी status मान जिसे आपका कोड नाम या संख्या से स्पष्ट रूप से जाँचता है
My Geocode अपने एरर रिस्पॉन्स और status के तरीके /docs/errors/ पर दर्ज करता है, और हर रिस्पॉन्स में कोटा हेडर भी होते हैं: X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit और X-Quota-Reset, जो जानकारी की एक श्रेणी (कोटा और रेट की स्थिति) को कवर करते हैं जिसे कुछ प्रदाता सीधे हेडर में दिखाने के बजाय एरर रिस्पॉन्स बॉडी के अंदर छिपा देते हैं। यह जाँचना कि आपका मौजूदा retry तर्क कोटा जानकारी रिस्पॉन्स बॉडी से पार्स करता है या हेडर से, माइग्रेशन चेकलिस्ट में जोड़ने लायक एक अच्छा विशिष्ट बिंदु है, क्योंकि हेडर-आधारित कोटा जानकारी को असल डेटा के लिए उपयोग होने वाले रिस्पॉन्स पार्सिंग रास्ते को छुए बिना पढ़ना आम तौर पर आसान होता है।
मैपिंग टेबल बनाने का एक व्यावहारिक तरीका है कि सिर्फ़ दस्तावेज़ों पर भरोसा करने के बजाय टेस्ट वातावरण में पुराने और नए दोनों प्रदाताओं पर हर एरर स्थिति को जान-बूझकर पैदा करें, क्योंकि किसी भी प्रदाता पर दस्तावेज़ और असल व्यवहार हमेशा हूबहू मेल नहीं खाते। एक गलत ढंग से बना अनुरोध भेजें, जान-बूझकर एक छोटा टेस्ट कोटा खत्म करें, और एक अमान्य कुंजी भेजें, फिर दर्ज करें कि हर प्रदाता हर मामले में ठीक-ठीक क्या लौटाता है।
इस तरह का एरर मैपिंग काम शायद ही कभी माइग्रेशन की प्रोजेक्ट योजना में दिखता है क्योंकि इससे कोई दिखने वाला फ़ीचर नहीं बनता, लेकिन बाद में माइग्रेशन को कैसे याद किया जाता है, इसके लिए यह असमान रूप से ज़िम्मेदार होता है। जो माइग्रेशन सफल रिस्पॉन्स को साफ़-सुथरे ढंग से बदल देता है लेकिन एरर हैंडलिंग को टूटा छोड़ देता है, वह बदलाव के बाद के पहले हफ़्तों में उस माइग्रेशन से कहीं ज़्यादा सपोर्ट टिकट पैदा करता है जिसने सुखद रास्ता सिर्फ़ आंशिक रूप से सही किया था।