🌖 🏢 🛍️ SendGrid हमारे लिए एक दोस्त है, लेकिन सच्चाई अधिक महंगी है 🔬 🤴🏽 👩‍🎓

जैसा कि मैंने पहले ही लिखा था , बहुत पहले नहीं हमने एक लोकप्रिय फ्रीमियम सेवा की एक टीम के साथ काम करना शुरू किया, जो एक परियोजना प्रबंधन प्रणाली है। यह सेवा काफी बड़ी संख्या में पत्र बनाती है, जिसकी गणना प्रति दिन हजारों में की जाती है, ये मुख्य रूप से उपयोगकर्ताओं को होने वाले परिवर्तनों और किसी भी कार्य के दृष्टिकोण / समाप्ति के दैनिक अनुस्मारक के बारे में विभिन्न सूचनाएं हैं। उपयोगकर्ता ईमेल का जवाब भी दे सकते हैं और इस प्रकार डेटा को अपडेट कर सकते हैं। जैसे-जैसे उपयोगकर्ताओं की संख्या बढ़ रही है, हमने देखा कि हमारे SendGrid खाते भी बढ़ रहे हैं, जो एक फ्रीमियम सेवा के रूप में, हम कम से कम करना चाहते हैं। हम यह भी समझना चाहते थे कि हम कितनी कुशलता से मेल का उपयोग करते हैं और क्या हम मेल का हिस्सा सिर्फ कहीं भेजते हैं, SendGrid डिलीवरी के लिए भुगतान करते हैं।

तेजी से, सवाल उठने लगे कि किसी को किसी तरह की अधिसूचना नहीं मिली थी या सेवा से एक पत्र के लिए उसकी प्रतिक्रिया प्राप्त नहीं हुई थी और उसके द्वारा प्रकाशित नहीं की गई थी। इस प्रकार, दूसरी समस्या मेल डिलीवरी से संबंधित उपयोगकर्ता की समस्याओं से प्रभावी ढंग से निपटने में असमर्थता थी, क्योंकि मुझे लगातार अपने स्वयं के डेटाबेस और सेंडग्रिड इंटरफ़ेस को ब्राउज़ करना पड़ता था। इस तथ्य के बावजूद कि इसमें बहुत समय लगा, यह अक्सर कोई परिणाम नहीं देता था। Smtp के माध्यम से पत्र भेजने के बाद, हमारे डेटाबेस में रिकॉर्ड और SendGrid के परिणाम के बीच कोई संबंध नहीं था।

आने वाले मेल के साथ भी स्थिति ऐसी ही थी। उन लोगों के लिए, जिन्होंने अभी तक सामना नहीं किया है, मैं यह बताऊंगा कि यह SendGrid में कैसे काम करता है: SendGrid द्वारा पत्र प्राप्त होते हैं, उन्हें पार्स किया जाता है और फिर प्राप्त डेटा को POST द्वारा निर्दिष्ट पते पर भेजा जाता है, अर्थात आप को। इसलिए, जब ऐसी स्थिति पैदा होती है कि हमारी सेवा में किसी का पत्र प्रकाशित नहीं हुआ, तो यह स्पष्ट नहीं है कि किसे दोषी ठहराया जाए - SendGrid इसे पार्स नहीं कर सकता था या हमारी स्क्रिप्ट काम नहीं करती थी। यदि आप स्वयं को ऐसी स्थिति में पाते हैं तो आप हमें समझेंगे कि सच्चाई का जवाब - "ठीक है, मैं नहीं जानता, इसे धिक्कार है, क्यों पत्र नहीं आया", उपयोगकर्ता को लिखा जा सकता है, और यह केवल जल्द ही आपके प्रश्न से निपटने का वादा करना संभव है। ताकि हमारे वादे झूठ न बनें, मैंने काम करना तय किया।

इसलिए - हमें पत्रों की डिलीवरी और प्राप्ति की प्रक्रिया पर पूर्ण नियंत्रण की आवश्यकता है। मामलों की वर्तमान स्थिति भेज (smtp के माध्यम से) और SendGrid के माध्यम से मेल प्राप्त कर रही थी, हमारे और SendGrid डेटा के बीच संचार की पूर्ण कमी, प्रति दिन हजारों पत्र और उनकी घातीय वृद्धि, जिसके परिणामस्वरूप बढ़ती हुई मात्रा और उपयोगकर्ता समस्याओं को हल करने के लिए एक प्रभावी तंत्र की अनुपस्थिति थी। कार्य हमारे डेटा को SendGrid डेटा के साथ लिंक करना है ताकि लागत कम करने और ग्राहक सहायता की गुणवत्ता और गति में वृद्धि हो सके।

सबसे पहले, हमने अपने सवालों के जवाब के लिए उनके प्रलेखन की ओर रुख किया। यह पता चला कि SendGrid में 2 हुक हैं, जो हमें अक्षरों के राज्य पर हमें नियंत्रण देना चाहिए। पहला हुक ईवेंट है - SendGrid निर्दिष्ट URL में उनके सिस्टम में उत्पन्न घटनाओं के बारे में सूचनाएं भेजता है। एक विशिष्ट पत्र की पहचान करने के लिए, वे अद्वितीय तर्कों और श्रेणियों के एक तंत्र का उपयोग करने का सुझाव देते हैं, जिसे SMTP पर संदेश भेजते समय एक विशेष शीर्ष लेख के रूप में प्रेषित किया जा सकता है। और आगे की घटनाओं की सूचनाओं में ये तर्क और श्रेणियां शामिल हैं, जो आपको यह निर्धारित करने की अनुमति देती हैं कि यह घटना किस पत्र की है। यह क्या देता है? सबसे पहले, "अगर कुक हमारे लिए झूठ नहीं बोल रहा है," हम हमेशा यह सुनिश्चित करने के लिए जानते हैं कि क्या पत्र उपयोगकर्ता को दिया गया है। दूसरे, उन पत्रों को फिर से भेजने की प्रक्रिया को पूरी तरह या आंशिक रूप से स्वचालित करना संभव है जिन्हें "डिफर्ड" का दर्जा मिला है या बाउंस सूची में हैं। इसके अलावा, अब हम बाउंस सूची में एक नया ईमेल दर्ज करने के बारे में जल्दी से पता लगाते हैं और जल्दी से कार्रवाई कर सकते हैं। अक्षरों की श्रेणियों के उपयोग के साथ जुड़े अतिरिक्त बोनस हैं।

जैसा कि ऊपर कहा गया था, श्रेणियों को भेजे गए पत्र को सौंपा जा सकता है और प्रलेखन के अनुसार 10 तक हो सकता है। इन श्रेणियों का उपयोग तब SendGrid इंटरफ़ेस में रिपोर्ट तैयार करते समय किया जाता है, उनकी तुलना एक-दूसरे के साथ अच्छे-अच्छे रेखांकन पर की जा सकती है। सच है, दुर्भाग्य से, किसी कारण से उनके पास केवल एकल-स्तरीय प्रणाली है, और हमारे लिए दो-स्तरीय दृष्टिकोण का उपयोग करना अधिक सुविधाजनक होगा। दो-स्तरीय क्योंकि हम में पहला स्तर उस एप्लिकेशन द्वारा निर्धारित किया जाता है जिसने पत्र भेजा था, और दूसरा स्तर वह कार्रवाई है जिसके कारण इसे भेजा गया था। उदाहरण के लिए, टोडो एप्लिकेशन एक रिकॉर्डिंग की समाप्ति तिथि बनाते, संपादित और बदलते समय पत्र भेजता है। दूसरी श्रेणी का उपयोग करने से हमें एक पूरी तस्वीर मिलती है कि कौन पत्र बनाता है और एक आवेदन के अंदर कितने। हालाँकि, अन्य अनुप्रयोगों में समान कार्य होते हैं, इसलिए ऐड श्रेणी स्वयं आँकड़ों के लिए उतनी दिलचस्प नहीं है जितना कि एक विशिष्ट अनुप्रयोग के लिए इसका बंधन। हालांकि, यह संभव है कि किसी और इस तरह के आंकड़ों का एक टुकड़ा उपयोगी होगा।

कार्यान्वयन के बारे में कुछ शब्द: इस परियोजना को CodeIgniter का उपयोग करके लिखा गया है और पत्र मानक ईमेल लाइब्रेरी द्वारा भेजे गए हैं। हालाँकि, यह आपको SMTP के माध्यम से संदेश भेजते समय अपने हेडर बनाने की अनुमति नहीं देता है, इसलिए, आपको इसे अपनी कक्षा के साथ विस्तारित करने की आवश्यकता है। उदाहरण के रूप में github.com/leonbarrett/CodeIgniter-Sendgrid-API/blob/master/system/lbooks/Email.php लाइब्रेरी को लेते हुए, हमने अपनी खुद की लाइब्रेरी बनाई, जो कि अनावश्यक थी और बाकी सभी को एक विधि से सरल बना दिया :)। वास्तव में, 2 तरीके सामने आए, क्योंकि CI_Email वर्ग में _set_header () विधि को निजी घोषित किया गया है, जो इसे व्युत्पन्न वर्गों में उपयोग करने की अनुमति नहीं देता है।

यहाँ पूरा पुस्तकालय कोड है:

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed'); /** * CodeIgniter * * An open source application development framework for PHP 5.1.6 or newer * * @package CodeIgniter * @author Deep Shift Labs Dev Team * @copyright Copyright (c) 2013, Deep Shift Labs * @license http://codeigniter.com/user_guide/license.html * @link http://codeigniter.com * @since Version 1.0 * @filesource */ // ------------------------------------------------------------------------ /** * CodeIgniter Email Class * * Permits email to be sent using Mail, Sendmail, or SMTP. * * @package CodeIgniter * @subpackage Libraries * @category Libraries * @author Deep Shift Labs Dev Team * @link http://deepshiftlabs.com */ class MY_Email extends CI_Email { /** * Add a Header Item * * @access private * @param string * @param string * @return void */ private function _set_header($header, $value) { $this->_headers[$header] = $value; } /** * Add a Sendgrid header * * @access public * @param array * @return void */ public function addSendGridHeader($data) { $xsmtpapi = json_encode($data); // Add spaces so that the field can be foldd $xsmtpapi = preg_replace('/(["\]}])([,:])(["\[{])/', '$1$2 $3', $xsmtpapi); $this->_set_header('X-SMTPAPI', $xsmtpapi); } }

इस प्रकार, पत्र के लिए अद्वितीय तर्कों और श्रेणियों का जोड़ एडसेंडग्रिडहाइडर () विधि के लिए एकल कॉल के साथ होता है, उदाहरण के लिए, इस तरह:

 $this->email->addSendGridHeader(array('unique_args'=>array('email_id'=>1), 'category'=>array('help', 'question')));

लेकिन वापस हुक करने के लिए, दूसरा हुक, इनबाउंड पार्स , आपको उपयोगकर्ताओं से प्रतिक्रिया प्राप्त करने की अनुमति देता है। तदनुसार डोमेन या उपडोमेन के एमएक्स रिकॉर्ड स्थापित करने के बाद, Sendgrid निर्दिष्ट पते पर एक संसाधित प्रतिक्रिया पत्र भेजना शुरू कर देता है। हमारे आश्चर्य के लिए, यह पता चला कि आने वाले पत्रों के लिए कोई घटना नहीं है, अर्थात्। प्रसंस्करण के किस चरण के बारे में जानकारी प्राप्त करना अब असंभव है। कोई केवल यह आशा कर सकता है कि यह प्रक्रिया उनमें डिबग हो जाए और विफल न हो, अर्थात्। जो कुछ भी उन्हें प्राप्त हुआ वह हमारे पास स्थानांतरित कर दिया गया है, यह सत्यापित करना अभी भी असंभव है। इसके आधार पर, हम केवल अपने पक्ष में होने वाले प्रसंस्करण पत्रों के चरणों को ठीक कर सकते हैं। हमें आने वाले पत्रों की निम्न स्थितियाँ मिलीं: 'प्राप्त', 'हैश_चेक', 'डुप्लिकेट', 'संसाधित'। निश्चित रूप से आप 'हैश_चेक' की दूसरी स्थिति में रुचि रखते हैं, वैसे भी मुझे उम्मीद है कि ऐसा होता है, क्योंकि अब मैं इसके बारे में बात करूंगा। इस तथ्य के अलावा कि हमें SendGrid से आने वाले पत्रों के बारे में कोई घटना नहीं मिलती है, हमें भी कुछ भी प्राप्त नहीं होता है, जो शुरुआती पत्र की पहचान करने में मदद करेगा। कोई अनोखी दलील नहीं, कोई श्रेणी नहीं, कुछ भी नहीं। यानी यह समझने के लिए कि हमें किस पत्र का उत्तर मिला है, बस असंभव है। लेकिन यह बहुत अच्छा होगा अगर सेंडग्रिड ने भेजे गए और प्राप्त पत्रों को खुद से जोड़ने का काम किया - हम भेजे गए पत्र के साथ अद्वितीय हेडर प्रसारित करते हैं और वे प्रतिक्रिया के साथ हमारे पास वापस आ जाते हैं। यह उसी अनपेक्षित क्षेत्र का हिस्सा है, जिसके बारे में मैंने पिछले पोस्ट में लिखा था । लेकिन चूंकि यह नहीं है, आपको अपने दम पर बाहर निकलना होगा।

हम रिप्लाई-टू हेडर के लिए एड्रेस में एक विशेष हैश का उपयोग करके गए, ऐसा दिखता है:

 "db051171af45b683c50eb3d66017ecf2+@incoming.servicedomain.com"

यह हैश इस तरह से उत्पन्न होता है कि हम वास्तव में जानते हैं कि यह किस सिस्टम से मेल खाता है। यह एक टोडो पोस्ट, चर्चा, या कुछ और हो सकता है। पत्र प्राप्त होने पर, हम उस रिकॉर्ड को निर्धारित करते हैं, जिसके पास पत्र होता है, और यदि यह निर्धारित करना संभव था, तो पत्र को 'हैश_चेक' की स्थिति सौंपी जाती है। अगला, हम जांचते हैं कि क्या पत्र एक डुप्लिकेट है, इसलिए कई समान टिप्पणियां बनाने के लिए नहीं। फिर, एक नई टिप्पणी वास्तव में बनाई गई है और संदेश को 'संसाधित' की स्थिति सौंपी गई है।

जिन कार्यों को हम हल करना चाहते थे, उनमें से एक पत्र उन पत्रों को फिर से भेजने की क्षमता थी जो उपयोगकर्ताओं को वितरित नहीं किए गए थे। ऐसा करने के लिए, सभी आवश्यक डेटा डेटाबेस में संग्रहीत किया जाता है। चूँकि यह प्रोजेक्ट CodeIgniter में लिखा गया है, ऐसे डेटा को भेजने से पहले पत्र का मुख्य भाग और गठित हेडर होते हैं, जिसमें विषय, प्राप्तकर्ता, हमारे अद्वितीय पैरामीटर और बहुत कुछ शामिल होते हैं। मानक ईमेल लाइब्रेरी के भेजने () विधि को ओवरराइड करने पर कोड की कुछ पंक्तियों में अक्षरों को सहेजना शाब्दिक रूप से महसूस किया गया था। तो, पत्र सहेजे जाते हैं, लेकिन सुरक्षित रूप से वितरित किए गए पत्रों के मूल डेटा को संग्रहीत करने में बहुत कम समझ है, है ना? किसी भी स्थिति में, यह हमारे लिए नहीं है, और इसलिए हमने SendGrida से ईवेंट प्राप्त करने वाली स्क्रिप्ट में छोटे बदलाव किए - यदि 'डिलीवर' ईवेंट के बारे में कोई सूचना प्राप्त होती है, तो हम टेबल से इस पत्र के अनुरूप सभी प्रविष्टियों को हटा देते हैं। यहां उपयोग किया जाने वाला गुणक आकस्मिक नहीं है, डेटाबेस में अक्षरों को संग्रहीत करने की प्रक्रिया को तेज करने के लिए, हम यह जांच नहीं करते हैं कि यह भेजने का पहला प्रयास है या नहीं, अर्थात्। एक ही पत्र भेजने के कई प्रयासों के मामले में, इसकी कई प्रतियां डेटाबेस में सहेजी जाएंगी। तार्किक निष्कर्ष डेटाबेस से पत्रों को फिर से भेजने के लिए एक कार्रवाई के अलावा था, इसके साथ कोई कठिनाई नहीं थी, हालांकि पत्रों के साथ काम करने के लिए उपर्युक्त पुस्तकालय में मामूली बदलाव की आवश्यकता थी। यदि यह दिलचस्प है, तो टिप्पणियों में लिखें और मैं आपको बताऊंगा कि कौन से हैं।

यहाँ सामान्य शब्दों में, और हम अपने भेजे गए और प्राप्त मेल को कैसे नियंत्रित करते हैं, इसके बारे में सब कुछ। इस नए सबसिस्टम को लॉन्च करने और डेटा को जमा करने से, हम उन मामलों को अनुकूलित और स्वचालित करना शुरू कर देंगे, जहां समाधान हमारे द्वारा समझा और प्रोग्राम किया गया है। यदि आपने पहले ही इस तरह की समस्या का समाधान कर लिया है और टिप्पणियों में अपना अनुभव साझा किया है, तो मैं इसकी सराहना करूंगा।

पुनश्च जब हमने ऊपर वर्णित स्वचालन प्रणाली जारी की, तो हमें एक अप्रिय स्थिति का सामना करना पड़ा। सिस्टम के हमारे उत्पादन और पूर्व-उत्पादन संस्करण SendGrid में विभिन्न खातों का उपयोग करते हैं ताकि परीक्षण ईमेल वास्तविक प्रणाली के आंकड़ों को प्रभावित न करें। 15 सितंबर को, हमने प्रोडक्शन सर्वर पर बदलाव शुरू करने की कोशिश की और यह पता चला कि किसी कारण से हमें भेजे गए ईवेंट नोटिफिकेशन से डेटा नहीं मिल सका। एक छोटी जांच के कारण का पता चला - 6 सितंबर को, SendGrid ने इवेंट वेबहूक का तीसरा संस्करण लॉन्च किया, जिसमें प्रेषित डेटा का प्रारूप मौलिक रूप से बदल दिया गया था। संस्करण 1 और 2 में, ये सामान्य POST चर थे, अब एक JSON संरचना अभिलेखों की एक सरणी के साथ भेजी जाती है। अजीब तरह से, SendGrid ने इस तरह के महत्वपूर्ण परिवर्तनों के अपने भुगतान किए गए ग्राहकों को चेतावनी नहीं दी। मतलबी कानून के अनुसार, प्री-प्रोडक्शन के लिए इवेंट नोटिफिकेशन एप्लिकेशन को 6 सितंबर तक सक्रिय किया गया था और, तदनुसार, हमने हुक के संस्करण 2 पर परीक्षण किया। 15 वीं की रिलीज़ से पहले, हमने लाइव सिस्टम द्वारा उपयोग किए जाने वाले खाते में सूचनाओं को सक्रिय किया, और हम चुपचाप हुक के संस्करण 3 से पहले से ही जुड़े थे। इस प्रकार, हमें अधिसूचना पार्सर को बदलने और परीक्षण करने के लिए रिलीज को स्थगित करने के लिए मजबूर किया गया था।

SendGrid हमारे लिए एक दोस्त है, लेकिन सच्चाई अधिक महंगी है

More articles: