SMS डिलीवरी स्थिति कॉलबैक का परीक्षण कैसे करें
एसएमएस डिलीवरी स्थिति कॉलबैक का परीक्षण करने के लिए सेटअप चरणों, डिलीवरी राज्यों और विश्वसनीय स्थिति ट्रैकिंग के लिए वेबहुक हैंडलिंग टिप्स के साथ सीखें।
SMS डिलीवरी स्थिति कॉलबैक क्या हैं
SMS डिलीवरी स्थिति कॉलबैक सर्वर-से-सर्वर सूचनाएँ हैं जो आपको बताती हैं कि SMS आपके सिस्टम से निकलने के बाद क्या हुआ। एक भेजने की पुष्टि केवल यह कहती है कि संदेश को प्रदाता द्वारा स्वीकार किया गया था। एक कॉलबैक आगे बढ़ता है और कतारबद्ध, भेजा गया, वितरित, विफल, या अवितरित जैसी स्थितियों की रिपोर्ट करता है।
यह अंतर महत्वपूर्ण है। एक संदेश “भेजा गया” हो सकता है और फिर भी कभी भी एक हैंडसेट तक नहीं पहुँच सकता। एक कॉलबैक कुछ सेकंड बाद आ सकता है, या यह कई मिनटों की carrier देरी के बाद आ सकता है, जो मार्ग और प्रदाता की पुनः प्रयास नीति पर निर्भर करता है।
कॉलबैक को रसीद के निशान के रूप में सोचें, न कि रसीद के रूप में। भेजने के अनुरोध से API प्रतिक्रिया आमतौर पर साबित करती है कि प्रदाता ने काम लिया। कॉलबैक यह साबित करता है कि उसके बाद क्या हुआ, और यही वह हिस्सा है जिसे आपको परीक्षण करना है यदि आपका ऐप अलर्ट, रसीदें, या ग्राहक सहायता कार्यप्रवाह के लिए स्थिति अपडेट पर निर्भर करता है।
एक व्यावहारिक विवरण: कॉलबैक आमतौर पर स्थिति परिवर्तन द्वारा सक्रिय किया जाता है, न कि मूल भेजने के अनुरोध द्वारा। यदि प्रदाता एक carrier प्रतिक्रिया, एक हैंडसेट डिलीवरी रिपोर्ट, या नेटवर्क से एक विफलता देखता है, तो यह आपके एंडपॉइंट पर एक HTTP अनुरोध पोस्ट करता है। यदि संदेश प्रदाता की कतार से आगे नहीं बढ़ता है, तो आप केवल प्रारंभिक स्थितियाँ देख सकते हैं।
कॉलबैक का परीक्षण करने के लिए पूर्वापेक्षाएँ
आपको SMS डिलीवरी स्थिति कॉलबैक का परीक्षण करने से पहले चार चीज़ों की आवश्यकता है: एक SMS प्रदाता खाता, एक कॉलबैक URL, सर्वर लॉग्स तक पहुँच, और एक परीक्षण नंबर। एक फोन जिसे आप नियंत्रित करते हैं, सबसे अच्छा है। यह परीक्षण को दोहराने योग्य रखता है और carrier व्यवहार के बारे में अनुमान लगाने से बचाता है।
एक सार्वजनिक HTTPS एंडपॉइंट तैयार रखें, भले ही यह अभी केवल अनुरोधों को लॉग करता हो। कई प्रदाता कॉलबैक डिलीवरी के लिए साधारण HTTP को अस्वीकार करते हैं, और कुछ परीक्षण वातावरण निजी पते को ब्लॉक करते हैं। आपको अपने सर्वर से अनुरोध हेडर, सामग्री, और प्रतिक्रिया कोड की जांच करने का एक तरीका भी चाहिए।
प्रदाता डैशबोर्ड को खुला रखें। आप वहां संदेश आईडी, टाइमस्टैम्प, और स्थिति घटनाओं की तुलना करेंगे। यदि आपका प्रदाता वेबहुक पुनःप्रयोजन या घटना इतिहास प्रदान करता है, तो शुरू करने से पहले उसे चालू कर दें। यह बाद में समय बचाता है जब एक कॉलबैक दो बार या बिल्कुल नहीं आती है।
यदि आपका SMS प्रवाह एक बड़े संदेश प्रणाली का हिस्सा है, तो संबंधित घटना हैंडलिंग की समीक्षा करना सहायक होता है, जैसे कि लेनदेनात्मक ईमेल के लिए ईमेल वेबहुक घटनाएँ। एक महत्वपूर्ण तरीके से तंत्र समान हैं: आपके सर्वर को जल्दी से घटना पेलोड को स्वीकार और सत्यापित करना चाहिए, फिर उन्हें पुनः प्रयास हिट होने से पहले संग्रहीत करना चाहिए।
चरण 1: एक परीक्षण कॉलबैक एंडपॉइंट कॉन्फ़िगर करें
कॉलबैक के लिए एक समर्पित एंडपॉइंट बनाएं, जैसे कि /sms-status, बजाय इसे सामान्य API मार्ग में भेजने के। एक छोटा, उद्देश्य-निर्मित एंडपॉइंट परीक्षण को आसान बनाता है क्योंकि हर अनुरोध एक काम से संबंधित होता है। आप कच्चे शरीर, हेडर, प्रतिक्रिया समय, और किसी भी पार्सिंग त्रुटियों को एक ही स्थान पर लॉग कर सकते हैं।
एंडपॉइंट को सार्वजनिक और HTTPS बनाएं। एक प्रमाणपत्र का उपयोग करें जिसे आपका प्रदाता विश्वसनीय मानता है। यदि प्रदाता URL तक नहीं पहुँच सकता है, तो कॉलबैक आपके कोड के चलने से पहले ही विफल हो जाएगा। यह स्पष्ट लगता है, लेकिन यह वह पहला स्थान है जहाँ कई परीक्षण टूटते हैं।
पेलोड सहेजने के बाद एक तेज 200 प्रतिक्रिया लौटाएं। डेटाबेस रिपोर्ट या डाउनस्ट्रीम सेवा कॉल पर न रुकें। एक कॉलबैक एंडपॉइंट को पहले प्राप्ति की पुष्टि करनी चाहिए, फिर कोई अतिरिक्त कार्य करना चाहिए। एक धीमी प्रतिक्रिया पुनः प्रयास को ट्रिगर कर सकती है, और पुनः प्रयास परीक्षण परिणामों को गंदा बना सकते हैं।
एक त्वरित सेटअप के लिए, आप कच्चे अनुरोध को एक लॉग फ़ाइल में लिख सकते हैं और शरीर को कंसोल में प्रिंट कर सकते हैं। यह पहले परीक्षण के लिए पर्याप्त है। बाद में, आप प्रदाता, message_id, स्थिति, received_at, और signature_header जैसे फ़ील्ड के साथ एक तालिका में पंक्तियाँ संग्रहीत कर सकते हैं।
चरण 2: कॉलबैक ट्रैकिंग सक्षम के साथ एक परीक्षण SMS भेजें
प्रदाता API या डैशबोर्ड का उपयोग करके एक परीक्षण संदेश भेजें और संदेश अनुरोध या खाता सेटिंग्स में कॉलबैक URL सेट करें। कुछ प्रदाता इसे स्थिति कॉलबैक, डिलीवरी रिसीप्ट URL, या वेबहुक एंडपॉइंट कहते हैं। लेबल बदलता है; कार्यक्षमता नहीं।
सुनिश्चित करें कि विशिष्ट संदेश के लिए कॉलबैक ट्रैकिंग सक्षम है। एक भेजने का अनुरोध बिना घटना डिलीवरी सक्रिय होने के सफल हो सकता है। यदि आपका प्रदाता प्रति-संदेश ध्वज का समर्थन करता है, तो उन्हें स्पष्ट रूप से सेट करें ताकि आप किसी डिफ़ॉल्ट पर निर्भर न हों जो खाता या वातावरण के अनुसार भिन्न हो सकता है।
अपना स्वयं का परीक्षण नंबर उपयोग करें। पहले एक छोटा संदेश भेजें, जैसे कि छह शब्दों का अलर्ट। छोटे पाठ फोन पर पहचानने में आसान होते हैं और प्रदाता लॉग के खिलाफ तुलना करना आसान होता है। यदि आप संयोजन या एन्कोडिंग का परीक्षण कर रहे हैं, तो एक अतिरिक्त वर्ण महत्वपूर्ण हो सकता है, इसलिए पहले परीक्षण को साधारण रखें।
यदि आपका स्टैक पहले से अन्य वेबहुक घटनाओं को संभालता है, तो वही अनुशासन लागू होता है। टीमें जो पहले से ही ईमेल डिलीवरबिलिटी परीक्षण उपकरण · YourTrend का पालन करती हैं, अक्सर SMS परीक्षण को सरल पाती हैं, क्योंकि वही आदत मदद करती है: सटीक अनुरोध को रिकॉर्ड करें, फिर इसे विक्रेता पक्ष के साथ तुलना करें बजाय इसके कि याद पर भरोसा करें।
चरण 3: सामान्य डिलीवरी राज्यों को ट्रिगर करें
एक से अधिक राज्य का परीक्षण करें। एकल डिलीवर किया गया संदेश बहुत कम साबित करता है। आप कतारबद्ध, भेजा गया, डिलीवर किया गया, विफल, और न डिलीवर किए गए देखना चाहते हैं ताकि आप जान सकें कि कॉलबैक पथ सामान्य और असंतोषजनक परिस्थितियों के तहत काम करता है।
ट्रिगर करने के लिए सबसे आसान राज्य आमतौर पर कतारबद्ध होता है। एक परीक्षण SMS भेजें और प्रारंभिक स्थिति के लिए कॉलबैक पर नज़र रखें। प्रदाता पहले संदेश को स्वीकार किया हुआ चिह्नित कर सकता है, फिर इसे कतार से बाहर निकलने पर अपडेट कर सकता है। यदि आप केवल पहले घटना को कैप्चर करते हैं, तो आपकी लॉजिक बाद के संक्रमण को चूक सकती है।
विफल या न डिलीवर करने के लिए, एक ऐसा नंबर उपयोग करें जो अमान्य, निष्क्रिय, या कैरियर नेटवर्क पर पहुंच योग्य न हो, आपके प्रदाता के परीक्षण नियमों के आधार पर। कुछ प्रदाता विशेष राज्यों को मजबूर करने के लिए सैंडबॉक्स नंबर या सिमुलेशन कोड भी प्रदान करते हैं। ये उपयोगी होते हैं क्योंकि वे अनिश्चितता को कम करते हैं।
डिलीवर किया गया वह राज्य है जो लोगों को सबसे अधिक महत्वपूर्ण लगता है, लेकिन यह भी वही है जिसे आपको मान लेना नहीं चाहिए। फोन को पहुंच योग्य होना चाहिए, नेटवर्क को एक डिलीवरी रिसीप्ट लौटानी चाहिए, और प्रदाता को उस रिसीप्ट को एक कॉलबैक में मैप करना चाहिए। तीन चलती हुई भाग। एक छूटी हुई कड़ी पर्याप्त है।
भेजा गया डिलीवर किए गए के समान नहीं है। एक भेजा गया स्थिति अक्सर इसका मतलब होता है कि प्रदाता ने संदेश को कैरियर को सौंपा या कम से कम डिलीवरी का प्रयास किया। यदि आपका व्यवसाय प्रक्रिया “भेजा गया” से एक काउंटडाउन शुरू करता है, तो आप उपयोगकर्ताओं को कुछ ऐसा वादा कर सकते हैं जो अभी तक नहीं हुआ है।
चरण 4: कॉलबैक पेलोड को मान्य करें
अनुरोध शरीर को खोलें और हर क्षेत्र की जांच करें जो प्रदाता वादा करता है। संदेश आईडी को मूल भेजने की प्रतिक्रिया से मेल खाना चाहिए। टाइमस्टैम्प आपके खाते के समय क्षेत्र या UTC में समझ में आने चाहिए, इस पर निर्भर करते हुए कि प्रदाता उन्हें कैसे प्रारूपित करता है। स्थिति मान प्रदाता द्वारा दस्तावेजीकृत सेट के भीतर रहना चाहिए।
प्रेषक और प्राप्तकर्ता डेटा पर ध्यान दें। एक नंबर से भेजा गया परीक्षण संदेश कॉलबैक में उसी गंतव्य नंबर के साथ वापस आना चाहिए, जब तक कि प्रदाता इसे छुपाता या सामान्य नहीं करता। यदि पेलोड में कैरियर कोड, त्रुटि कारण, या संदेश दिशा शामिल हैं, तो उन्हें भी संग्रहीत करें। ये बाद में उपयोगी हो जाते हैं जब ग्राहक कहता है, “मुझे यह कभी नहीं मिला।”
हस्ताक्षर हेडर को वास्तविक ध्यान देने की आवश्यकता है। कई प्रदाता कॉलबैक पर हस्ताक्षर करते हैं ताकि आपका सर्वर पुष्टि कर सके कि अनुरोध वास्तव में उनसे आया है। सटीक हेडर नाम, हस्ताक्षर एल्गोरिदम, और साझा रहस्य या सार्वजनिक कुंजी प्रवाह की जांच करें। यदि आप परीक्षण के दौरान सत्यापन छोड़ देते हैं, तो आप उस पथ का परीक्षण नहीं कर रहे हैं जिसका आप उत्पादन में उपयोग करेंगे।
संरचना के लिए एक मान्यता पास और प्रामाणिकता के लिए एक का उपयोग करें। पहले पुष्टि करें कि JSON या फॉर्म बॉडी सही ढंग से पार्स होती है। फिर पुष्टि करें कि हस्ताक्षर या टोकन आपके प्रदाता की अपेक्षाओं से मेल खाता है। यह दो-चरणीय जांच दोनों गलत पेलोड और धोखाधड़ी अनुरोधों को पकड़ती है।
| क्षेत्र | क्या जांचें | यह क्यों महत्वपूर्ण है |
|---|---|---|
| संदेश_आईडी | प्रेषण प्रतिक्रिया से मेल खाता है | आपको एक SMS के लिए कॉलबैक कनेक्ट करने की अनुमति देता है |
| स्थिति | क्यूड, भेजा गया, वितरित, विफल, या अप्राप्त | वर्तमान स्थिति दिखाता है |
| टाइमस्टैम्प | उचित प्रारूप और समय क्षेत्र | इवेंट्स को सही क्रम में मदद करता है |
| से / को | प्रेषक और प्राप्तकर्ता मान | सही संदेश की पुष्टि करता है |
| हस्ताक्षर हेडर | प्रस्तुत और मान्य | अनुरोध स्रोत की पुष्टि करता है |
चरण 5: प्रदाता लॉग की तुलना अपने वेबहुक लॉग से करें
अब प्रदाता के इवेंट इतिहास को उन अनुरोधों से मिलाएं जो आपके सर्वर ने प्राप्त किए। पहले संदेश आईडी का उपयोग करें। फिर स्थिति, टाइमस्टैम्प, और पुनः प्रयास की संख्या की तुलना करें। यदि एक पक्ष तीन इवेंट दिखाता है और दूसरा पक्ष दो, तो आपके पास एक ऐसा अंतर है जिसे ठीक करने की आवश्यकता है इससे पहले कि कोई इसे उत्पादन समस्या कहे।
प्रदाता डैशबोर्ड कभी-कभी इवेंट्स को संदेश द्वारा और कभी-कभी अनुरोध द्वारा समूहित करते हैं। आपके अपने लॉग अधिक सटीक होने चाहिए। HTTP विधि, आपके सर्वर द्वारा लौटाया गया स्थिति कोड, अनुरोध शरीर, और आगमन समय को सेकंड में रिकॉर्ड करें यदि संभव हो। यह आपको एक साफ लाइन-दर-लाइन तुलना देता है।
यदि आपका प्रदाता निर्यातित लॉग प्रदान करता है, तो उन्हें उसी परीक्षण विंडो के दौरान खींचें। भेजने के बीच दस मिनट की देरी लॉग तुलना को आसान बना सकती है। बिंदु केवल यह नहीं है कि एक कॉलबैक आया, बल्कि यह साबित करना है कि आपका सर्वर और प्रदाता इस बात पर सहमत हैं कि कौन सा इवेंट हुआ और कब।
उन टीमों के लिए जो पहले से ही मेल इवेंट की तुलना करती हैं, यह परिचित लगता है। वही आदत जो ईमेल बाउंस हैंडलिंग सर्वोत्तम प्रथाओं के लिए उपयोग की जाती है, यहाँ लागू होती है: केवल खुश रास्ते पर भरोसा न करें। विक्रेता रिकॉर्ड, आपके इनटेक रिकॉर्ड, और अंतिम स्थिति की तुलना करें जो आपके ऐप ने संग्रहीत की।
चरण 6: गायब या गलत कॉलबैक का समाधान करें
यदि कॉलबैक कभी नहीं आता है, तो एंडपॉइंट URL से शुरू करें। वर्तनी, प्रोटोकॉल, पोर्ट, और पथ की जांच करें। एक बेतरतीब अक्षर अनुरोध को कहीं भी भेज सकता है। फिर पुष्टि करें कि एंडपॉइंट सार्वजनिक इंटरनेट से पहुंच योग्य है, केवल आपके कार्यालय नेटवर्क से नहीं।
टाइमआउट अगला है। यदि आपका सर्वर प्रतिक्रिया देने में बहुत समय लेता है, तो प्रदाता पुनः प्रयास कर सकता है या कॉलबैक को विफल के रूप में चिह्नित कर सकता है। हैंडलर को छोटा रखें। पहले पेलोड को सहेजें, 200 लौटाएं, और बाकी को बाद में संसाधित करें।
फायरवॉल नियम आपके कोड के देखने से पहले अनुरोध को ब्लॉक कर सकते हैं। आईपी अलाउलिस्ट, WAF नियम, या बुनियादी प्रमाणीकरण भी ऐसा कर सकते हैं जिसे प्रदाता पूरा नहीं कर सकता। यदि आपके एंडपॉइंट को प्रमाणीकरण की आवश्यकता है, तो सुनिश्चित करें कि प्रदाता ने जिस विधि का आपने चयन किया है, उसका समर्थन करता है। कुछ सिस्टम क्वेरी स्ट्रिंग में एक गुप्त कोड का समर्थन करते हैं, अन्य एक प्रमाणीकरण हेडर भेजते हैं, और कुछ दोनों करते हैं।
गलत JSON का अर्थ आमतौर पर यह होता है कि प्रदाता ने उस सामग्री प्रकार का उपयोग किया जो आपने अपेक्षित किया था, या आपका पार्सर एक फ़ील्ड आकार को अस्वीकार कर दिया जिसे आपने परीक्षण नहीं किया था। कच्चे शरीर का निरीक्षण करें। केवल सुंदर संस्करण पर भरोसा न करें। आपके अपने कोड में एक गायब अल्पविराम भी इसे ऐसा दिखा सकता है जैसे प्रदाता ने कुछ तोड़ा हो।
डुप्लिकेट घटनाएँ टीमों की अपेक्षा से अधिक बार होती हैं। एक प्रदाता टाइमआउट के बाद पुनः प्रयास कर सकता है भले ही पहला कॉलबैक अंततः पूरा हो गया हो। आपका हैंडलर एक ही संदेश आईडी और स्थिति को एक से अधिक बार स्वीकार करना चाहिए बिना डुप्लिकेट पंक्तियाँ या डुप्लिकेट अलर्ट बनाए। आइडेम्पोटेंसी नियमों को परीक्षण नोट्स में संग्रहीत करें।
यदि हस्ताक्षर विफल होते हैं, तो भेजे गए सटीक बाइट्स की तुलना करें जो आपके सत्यापनकर्ता ने उपयोग की। वर्ण एन्कोडिंग, लाइन ब्रेक, और शरीर पार्सिंग परिणाम को बदल सकते हैं। यही एक कारण है कि SMS डिलीवरी स्थिति कॉलबैक का परीक्षण करने के लिए कच्चे अनुरोध चरण की आवश्यकता होती है, न कि केवल पार्स किए गए ऑब्जेक्ट चरण की।
चरण 7: उत्पादन तत्परता की पुष्टि करें
स्टेजिंग या प्रोडक्शन-जैसे सेटअप में असली HTTPS, वही कोड पथ, और वही लॉग गंतव्य के साथ पूरा परीक्षण दोहराएँ। यदि आपका परीक्षण खाता अलग व्यवहार करता है, तो एक लाइव प्रदाता खाता का उपयोग करें। एक नकली वातावरण प्रमाणपत्र समस्याओं, DNS मुद्दों, या दर सीमाओं को छिपा सकता है जो केवल तैनाती के बाद प्रकट होते हैं।
एक ही स्थान पर अपेक्षित कॉलबैक व्यवहार का दस्तावेज़ीकरण करें। नोट करें कि आप कौन से स्थिति की अपेक्षा करते हैं, कौन सी उपयोगकर्ता सूचनाओं को ट्रिगर करती है, और कौन सी केवल आंतरिक लॉग को अपडेट करनी चाहिए। यदि प्रदाता 30 सेकंड के बाद पुनः प्रयास करता है, तो उसे भी लिखें। भविष्य की डिबगिंग तेज होती है जब टीम को अपेक्षित देरी का पता होता है।
गुमशुदा कॉलबैक के लिए एक निगरानी नियम सेट करें। एक सरल जांच यह है कि उन संदेशों को चिह्नित करें जो आपके सामान्य विंडो से अधिक समय तक भेजे गए स्थिति में रहते हैं। एक और यह है कि जब कॉलबैक एंडपॉइंट 3 अनुरोधों में से अधिक के लिए 200 के अलावा कुछ भी लौटाता है, तो अलर्ट करें।
यदि SMS स्थिति ट्रैकिंग एक व्यापक संदेश प्रणाली का हिस्सा है, तो चैनलों के बीच समान गुणवत्ता मान बनाए रखें। टीमें अक्सर SMS परीक्षणों को ईमेल के लिए ट्रांजैक्शनल के लिए DKIM SPF DMARC सेटअप के साथ जोड़ती हैं, क्योंकि दोनों प्रणालियाँ पहचान जांच, घटना वितरण, और स्पष्ट विफलता हैंडलिंग पर निर्भर करती हैं। एक पक्ष चुपचाप विफल होता है। दूसरा जोर से विफल होता है। दोनों को परीक्षण की आवश्यकता है।
अंत में, अपने आंतरिक दस्तावेज़ों में एक ज्ञात-अच्छा कॉलबैक उदाहरण सहेजें। अनुरोध शरीर, हस्ताक्षर हेडर, प्रतिक्रिया कोड, और प्रदाता घटना पृष्ठ शामिल करें। वह एकल नमूना आपके संदर्भ बन जाता है जब भविष्य का रिलीज़ पेलोड आकार को बदलता है या एक वाहक अलग तरीके से व्यवहार करना शुरू करता है।
इस पृष्ठ पर
← सभी लेखएक क्लिक। यह हमें बताता है कि अगला क्या लिखना है।
अभी तक कोई रेटिंग नहीं — आपकी पहली होगी।
टिप्पणियाँ
टिप्पणियाँ दिखाई देने से पहले पढ़ी जाती हैं।