रीसेलिंग और पैनल चलाना
मेरा प्रोवाइडर बंद हो जाए तो मेरे ग्राहकों का क्या होता है?
आख़िरी अपडेट , PanelCompare की संपादकीय टीम द्वारा
इसे समय रहते पकड़ना इतना मुश्किल क्यों है?
क्योंकि यह नाकामी अपनी बनावट से ही ख़ामोश होती है। API एरर को HTTP 200 के साथ एक error फ़ील्ड में लौटाता है, इसलिए कच्चा इंटीग्रेशन इसे सफल डिस्पैच के रूप में दर्ज कर लेता है। ऑर्डर पेंडिंग में पड़े रहते हैं, जो बताए गए स्टार्ट टाइम के दायरे के भीतर सामान्य दिखता है, और जब तक यह दायरा साफ़ तौर पर निकल चुका होता है, तब तक आप एक दिन के ऐसे ऑर्डर ले चुके होते हैं जिन्हें आप पूरा नहीं कर सकते।
प्रोवाइडर के ढहने की शृंखला के पीछे भी यही तंत्र है: एक Tier-1 सप्लायर बंद होता है और उसके नीचे का हर पैनल एक साथ डिलीवरी रोक देता है, बिना किसी बदनीयती के, और ख़रीदारों की शिकायत आने तक किसी को पता भी नहीं चलता।
ऐसा होने से पहले आपको क्या तैयार कर लेना चाहिए?
- 1.रिस्पॉन्स body पार्स करें, स्टेटस कोड कभी नहीं। error फ़ील्ड वाला 200 नाकामी है।
- 2.हर प्रोवाइडर का बैलेंस और सर्विसें एक शेड्यूल पर जाँचते रहें; जो प्रोवाइडर कल जवाब दे रहा था और आज नहीं, वही सबसे पहला उपलब्ध संकेत है।
- 3.जो सर्विस आप बड़ी मात्रा में बेचते हैं, उस पर कम से कम दो प्रोवाइडर जोड़ें, सस्ते वाले को मुख्य रखें, और बैकअप को मानकर नहीं, परखकर रखें।
- 4.जो ऑर्डर आप पूरे नहीं कर सकते उन्हें लेने के बजाय अपने कैटलॉग में सर्विस बंद कर दें — बंद पंक्ति से एक बिक्री जाती है, अटके ऑर्डर से एक ग्राहक।
- 5.स्टेटस नोट प्रकाशित करें। ख़रीदार उस आउटेज को माफ़ कर देते हैं जिसके बारे में उन्हें बताया गया, पर ख़ामोशी को नहीं, क्योंकि एग्ज़िट ऐसा ही दिखता है।
क्या आपको यह जवाब ग़लत लगता है?
इस बाज़ार में कीमतें, रिफिल की शर्तें और प्लेटफ़ॉर्म की नीतियाँ, सब बदलती रहती हैं, इसलिए जो जवाब सितंबर में सही था, ज़रूरी नहीं कि दिसंबर में भी सही हो। ऊपर के हर आँकड़े के साथ उसका स्रोत और जाँच की तारीख़ दी गई है; अगर इनमें से कोई पुराना या ग़लत है, तो हमारे बारे में पेज पर दी गई सुधार की प्रक्रिया में दो कामकाजी दिनों में जवाब देने का लक्ष्य है, और सुधार चुपचाप नहीं किए जाते, बल्कि तारीख़ वाले नोट के साथ प्रकाशित किए जाते हैं।