इस पेज पर
हरा टेस्ट छूटा नियम छिपा सकता है. इस उदाहरण में एजेंट को स्टोर ईमेल प्लेटफ़ॉर्म से जोड़ने को कहा जाता है. टेस्ट सर्वर संपर्क अपडेट स्वीकार करके साफ़ 200 लौटाता है. एजेंट काम पूरा करता है और टेस्ट पास हो जाता है.
वास्तविक डेस्टिनेशन का एक अतिरिक्त नियम है: संपर्क अपडेट में कस्टम एट्रिब्यूट सेट करने से पहले उसे घोषित करना होगा. टेस्ट सर्वर ने यह नियम मॉडल नहीं किया. हरा परिणाम टेस्ट दुनिया में एजेंट के बारे में कुछ साबित करता है. वह लाइव दुनिया में छूटे नियम के बारे में कुछ नहीं साबित करता.
सिमुलेशन का मूल समझौता यही है. वह जोखिम भरे या महंगे कार्य दोहराने योग्य बनाता है. वह दूसरा सिस्टम भी बनाता है जिसका व्यवहार पहले से अलग हो सकता है.
प्रतिनिधि सिस्टम कार्य के परीक्षण संभव बनाता है
कार्य करने वाले एजेंट को जांचने के लिए उद्देश्य, वातावरण और दिखाई देने वाली अंतिम स्थिति दें. सिमुलेटेड एजेंट वातावरण पर स्रोत चर्चा ब्राउज़र और ज्ञान-कार्य के संदर्भ में यह संरचना समझाती है. वातावरण सत्यापक को एजेंट की छोड़ी स्थिति ज्ञात अच्छे परिणाम से मिलाने देता है.
इंटीग्रेशन में प्रतिनिधि सिस्टम डेस्टिनेशन के कुछ कार्य दे सकता है: फ़ील्ड सूची, संपर्क बनाना, संपर्क अपडेट और संपर्क फिर पढ़ना. उसमें घोषित FNAME फ़ील्ड और अनुपस्थित CUSTOM_TIER फ़ील्ड वाला टेस्ट डेटा हो सकता है. टेस्ट एजेंट से मैपिंग सुझाने को कहे, फिर CUSTOM_TIER की परिभाषा से पहले उसे लिखने का प्रयास अस्वीकार करे.
प्रतिनिधि सिस्टम उपयोगी है क्योंकि हर रन समान स्थिति से शुरू होता है. एक बार में एक शर्त बदलें: गायब फ़ील्ड, अनुमति अस्वीकार, पुराना स्कीमा संस्करण, अस्पष्ट पहचानकर्ता. मॉडल या प्रॉम्प्ट के बीच एजेंट के कॉल क्रम और बनी स्थिति की तुलना कर सकते हैं.
यह केवल पाठ वाले “एजेंट क्या करेगा?” सवाल से अधिक मज़बूत है. नियंत्रित दुनिया में एजेंट ने सचमुच क्या कॉल किया, यह जांचता है.
टेस्ट डेटा में हर कॉल से पहले और बाद की स्थिति दें, केवल तयशुदा जवाब नहीं. एजेंट संपर्क दो बार बनाए तो दूसरी कॉल वह डुप्लिकेट व्यवहार दिखाए जिसे जांचना चाहते हैं. लिखने के बाद फ़ील्ड पढ़े तो पढ़ाई संग्रहीत स्थिति लौटाए. नहीं तो एजेंट उचित दिखने वाला अनुरोध भेजकर पास हो सकता है, जबकि टेस्ट यह नहीं देख पाता कि क्रम से इच्छित रिकॉर्ड बना या नहीं.
वास्तविकता से मेल परीक्षण का हिस्सा है
उचित आपत्ति है: “विक्रेता का सैंडबॉक्स है, दूसरा क्यों बनाएं?” जिस मामले की ज़रूरत हो और डेटा सुरक्षित रहे, वहां विक्रेता सैंडबॉक्स इस्तेमाल करें. स्थानीय प्रतिनिधि तब उपयोगी है जब निर्धारक रीसेट, जानबूझकर डाली त्रुटियां या ऐसी कॉल जांचनी हों जिन्हें विक्रेता सैंडबॉक्स तैयार नहीं कर सकता. उसे संभालने की लागत भी है. मॉडल किया हर नियम गलत या पुराना हो सकता है.
आधिकारिक Brevo संपर्क API कहता है कि संपर्क एट्रिब्यूट अकाउंट में होने चाहिए और घोषित प्रकार से गलत मान अनदेखे किए जाते हैं. हर गलत मान अस्वीकार करने वाला प्रतिनिधि इस दस्तावेज़ वाले मामले से अलग व्यवहार करेगा. वह एजेंट को ऐसी त्रुटि की अपेक्षा सिखा सकता है जो आती ही नहीं.
प्रतिनिधि कौन से विक्रेता व्यवहार कवर करता है, लिखें. असली API या समर्थित टेस्ट वातावरण के खिलाफ़ कुछ छोटे अनुबंध परीक्षण रखें. अंतर मिले तो प्रतिनिधि अपडेट करें और अंतर दिखाने वाला मामला जोड़ें. सिमुलेशन विक्रेता का मॉडल है, उसका विकल्प नहीं.
यही अनुशासन समय पर लागू होता है. हर लिखाई तुरंत दिखाने वाला प्रतिनिधि बहुत जल्दी पढ़ने वाले वर्कफ़्लो की चूक नहीं पकड़ता. हर लिखाई देर से दिखाने वाला प्रतिनिधि विक्रेता में न होने वाली विफलता गढ़ सकता है. समय केवल वहीं मॉडल करें जहां वह जांचे जा रहे निर्णय को प्रभावित करे; बाकी को सिमुलेशन से बाहर बताएं. तब पास का सटीक अर्थ होगा: इन मॉडल किए नियमों के तहत एजेंट ने ये काम पूरे किए.
Tajo की Brevo कनेक्टर गाइड व्यापारी के नज़रिए से यही बात समझाती है: सफल अनुरोध के बाद भी फ़ील्ड गायब रह सकता है. टेस्ट तभी उपयोगी है जब वह केवल HTTP जवाब नहीं, फ़ील्ड जांचे.
सिमुलेटेड डेस्टिनेशन मॉडल किए नियमों के तहत एजेंट जांचता है. अनुबंध परीक्षण सीमित प्रीव्यू से पहले उन नियमों की लाइव डेस्टिनेशन से तुलना करते हैं.
सुरक्षित अभ्यास से सीमित प्रमाण की ओर बढ़ें
पास हुआ सिमुलेशन छोटे लाइव प्रीव्यू की ओर ले जाए. कुछ रिकॉर्ड चुनें जिनकी अपेक्षित डेस्टिनेशन स्थिति स्पष्ट हो. सामान्य रिकॉर्ड, वैकल्पिक फ़ील्ड के बिना रिकॉर्ड और ऐसा रिकॉर्ड रखें जिसकी सहमति स्थिति मार्केटिंग उपयोग रोकती हो. डेस्टिनेशन वास्तव में क्या संग्रहीत करता है, सत्यापित करें. केवल अनुरोध के डेटा से परिणाम अनुमान न लगाएं.
कृत्रिम प्रीव्यू और डेस्टिनेशन जाँच अलग सवालों का जवाब देते हैं. Tajo का मैपिंग प्रीव्यू डेस्टिनेशन पर लिखे बिना बदलाव का नियम जाँचता है. नीचे प्रस्तावित दृश्य अगली सीमा दिखाता है: लागू अपडेट के बाद भी डेस्टिनेशन की स्थिति जाँचना ज़रूरी है. उसे बाकी दिखाने से अभ्यास को सबूत नहीं समझा जाएगा.
पूरा हुआ राइट भी सबूत माँगता है
क्या ग्राहक सिंक पूरा हुआ?
राइट लागू हुआ. सत्यापन बाकी है.
डेस्टिनेशन की स्थिति अभी जाँची नहीं गई है.
सिंक गतिविधि
- अनुरोध स्वीकार हुआ
- अपडेट लागू हुआ
- डेस्टिनेशन की जाँच बाकी
उदाहरण रन · 14:32 UTC
हम क्या जानते हैं
- प्रदाता का जवाब
- स्वीकार हुआ
- राइट का परिणाम
- लागू हुआ
- डेस्टिनेशन से दोबारा पढ़ना
- बाकी
सफल कॉल अंतिम स्थिति साबित नहीं करती.
यह प्रस्तावित लेआउट Tajo की गतिविधि फ़ीड पर आधारित है. चित्र में सत्यापन की स्थिति जोड़ी गई है; यह दावा नहीं करता कि डेस्टिनेशन से दोबारा पढ़ना पहले से लागू है.
प्रीव्यू का दायरा छोटा और रुकने की शर्त स्पष्ट हो. विफलता व्यापक सक्रियण रोके और सटीक अंतर बताए: फ़ील्ड परिभाषा, पहचानकर्ता, प्रकार, अनुमति या समय. पास हुआ प्रीव्यू यह साबित नहीं करता कि भविष्य का हर रिकॉर्ड समान चलेगा, लेकिन बताता है कि चुने मामलों पर आज अनुबंध काम करता है.
इस क्रम में दो सवाल अलग हैं. सिमुलेशन पूछता है, “जब दुनिया हमारे नियंत्रण में हो तो एजेंट डिज़ाइन किया नियम मानता है?” लाइव प्रीव्यू पूछता है, “क्या डिज़ाइन किया नियम इस विक्रेता अकाउंट पर फिट बैठता है?” एक दूसरे की जगह नहीं ले सकता.
रिवर्स ETL गाइड समझाती है कि अंतिम काम कई रिकॉर्डों पर दोहरता है. दोहराव सिमुलेटेड और वास्तविक अनुबंध के बीच बचा अंतर बढ़ा देता है.
जिस दुनिया को रीसेट कर सकते हैं उसमें अभ्यास करें. फिर उस दुनिया को देखें जिसे नहीं कर सकते.
अक्सर पूछे जाने वाले प्रश्न
सिमुलेटेड डेस्टिनेशन क्या जांच सकता है?
एजेंट अपेक्षित कॉल चुनता है या नहीं, अनुमति का पालन करता है या नहीं, ज्ञात त्रुटियां संभालता है या नहीं, और सिमुलेशन में अपेक्षित स्थिति छोड़ता है या नहीं.
वह क्या साबित नहीं कर सकता?
वह यह नहीं बता सकता कि विक्रेता का उसका मॉडल पूरा है. बिना दस्तावेज़ वाले व्यवहार, समय और अकाउंट-विशिष्ट सेटिंग सिमुलेशन से अलग हो सकती हैं.
सिमुलेशन पास होने के बाद क्या होना चाहिए?
वास्तविक डेस्टिनेशन पर सीमित प्रीव्यू या कैनरी चलाएं, फिर व्यापक सक्रियण से पहले बनी हुई स्थिति देखें.