इस पेज पर
“ऑर्डर अपने आप चलते हैं” पूरा वर्कफ़्लो विवरण लगता है. उदाहरण के ट्रेस में हर ऑर्डर दोनों सिस्टम में दिखता है. फिर उनके बीच स्प्रेडशीट का एक कॉलम मिलता है. ऑपरेटर अपलोड से पहले कॉलम बदलता है, क्योंकि स्टोर का स्टेटस ईमेल टीम की अपेक्षा वाला अर्थ नहीं रखता.
डिब्बों के स्तर पर चित्र सही था. उसने काम छोड़ दिया.
रिकॉर्ड सिस्टम से वर्कफ़्लो सीखने पर चर्चा सिस्टम में आने वाली चीज़ और सुधारी गई चीज़ देखकर चलने वाली प्रक्रिया बनाने की बात करती है. अच्छी शुरुआत है. इसका अर्थ नहीं कि लॉग व्यक्ति की मंशा बता सकता है या देखने के लिए टीम को ग्राहक रिकॉर्ड की व्यापक पहुंच मिलनी चाहिए.
प्रक्रिया के नाम नहीं, ट्रेस से शुरू करें
“ऑर्डर सिंक” एक कार्य लगता है. एक ऑर्डर के पीछे जाएं तो क्रम बनता है. कब बना? पहले कौन सा स्टेटस लिखा? भुगतान या कैंसल होने से बदला? कौन सा फ़ील्ड डेस्टिनेशन पहुंचा? डेस्टिनेशन ने क्या किया? बाद में व्यक्ति ने क्या सुधारा?
इवेंट समय क्रम में लिखें. हर चरण के पास स्रोत रिकॉर्ड पहचानकर्ता रखें. मान दो बार बदले तो दोनों लिखें. डेस्टिनेशन केवल अंतिम मान रखे तो बीच में क्या हुआ, जानें. लक्ष्य सुंदर प्रक्रिया नक्शा नहीं. ऐसा ट्रेस है जिसे दूसरा व्यक्ति चुनौती दे सके.
पहला ट्रेस सामान्य हो. दूसरा अपवाद: कैंसल, मिले हुए ग्राहक, लौटाया ऑर्डर, देर भुगतान या ऑपरेटरों के अनुसार महत्वपूर्ण दूसरा मामला. दो ट्रेस आवृत्ति साबित नहीं करते. विवरण के लिए ज़रूरी सवाल खोलते हैं.
- स्टोर रिकॉर्डस्टेटस आता हैदेखा गया
- ऑपरेटर सुधारअर्थ जांचापुष्टि हुई
- ईमेल डेस्टिनेशनस्वीकृत स्थिति
| टीम क्या कहती है | ट्रेस क्या दिखा सकता है | क्या पूछें |
|---|---|---|
| “ऑर्डर अपने आप सिंक होते हैं” | मैनुअल फ़ाइल बाद में अपलोड होती है | फ़ाइल कौन सा बदलाव करती है? |
| “ग्राहक स्टेटस वर्तमान है” | बाद का इवेंट पुराने मान को बदल देता है | अंतिम स्थिति किस सिस्टम की है? |
| “त्रुटि सहायता टीम को जाती है” | टिकट बिना स्रोत में सुधार होता है | डेस्टिनेशन को कैसे पता चलेगा? |
ये उदाहरण की संभावनाएं हैं, देखी ग्राहक घटनाएं नहीं. वास्तविक रास्ता समझने के बाद इंटीग्रेशन गाइड कनेक्शन तरीका चुनने में मदद करती है.
रिकॉर्ड व्यवहार दिखाते हैं; ऑपरेटर अर्थ बताते हैं
रिकॉर्ड दिखा सकता है कि मान pending से complete हुआ. वह नहीं बता सकता कि इसका मतलब भुगतान पूरा हुआ, ऑर्डर की पूर्ति समाप्त हुई या किसी ने टाइपो सुधारा. फ़ील्ड का नाम बिज़नेस नियम नहीं.
इसलिए अवलोकन और इंटरव्यू साथ चलें. ट्रेस में अजीब लगे मामले पर ऑपरेटर से पूरा रास्ता बताने को कहें. अपवाद समझाए और इस्तेमाल की अनुमत स्क्रीन दिखाए. फिर दूसरे नमूने पर नियम चलाएं. एक प्रभावी उदाहरण से बना विवरण किसी व्यक्ति के अस्थायी उपाय को कंपनी नीति बना सकता है.
पहुंच मायने रखती है. सवाल के लिए न्यूनतम डेटा इस्तेमाल करें. स्वीकृत पहुंच लें और जहां संभव निजी फ़ील्ड छिपाएं. सिंक डिज़ाइन अभ्यास के बहाने ग्राहक डेटाबेस शोध नोटबुक में एक्सपोर्ट न करें. ऑडिट इवेंट या सैंडबॉक्स हों तो वहां से शुरू करें. नहीं तो स्वामी से उचित रिकॉर्ड द्वारा रास्ता दिखवाएं.
यह अंतर सामान्य ऑटोमेशन गलती रोकता है: असुविधाजनक मैनुअल चरण का निर्णय समझे बिना उसे बदल देना. स्प्रेडशीट कॉलम बेकार दोहराव हो सकता है. वही एकमात्र जगह भी हो सकती है जहां इंसान विवादित ऑर्डर को कैम्पेन से बाहर रखता है. पता किए बिना हटाएं तो नया सिंक गलत काम और तेज़ करेगा.
ट्रेस को अनुबंध बनाएं
रास्ता दिखने पर स्थिति और स्वामी के आधार पर कनेक्शन लिखें. हर फ़ील्ड का आधिकारिक सिस्टम, बदलने वाला इवेंट, देर या दोहराए इवेंट का निपटारा और परिणाम अनिश्चित हो तो क्या होगा, तय करें. हर बेमेल स्थिति कौन सुधार सकता है, नाम दें.
अनुबंध रिकॉर्ड हुए तथ्य और बिज़नेस व्याख्या अलग रखे. “स्टोर ने 14:03 पर fulfilled भेजा” रिकॉर्ड हुआ इवेंट है. “इस ग्राहक को समीक्षा अनुरोध मिलना चाहिए” निर्णय है जो रिटर्न, सहमति और स्थानीय नीति पर भी निर्भर हो सकता है. अलग रखने से बाद के बदलाव सुरक्षित होते हैं.
फ़ील्ड मैपिंग अनुबंध का एक हिस्सा दिखाती है. Tajo के इस चित्र में हर पंक्ति स्रोत फ़ील्ड, डेस्टिनेशन फ़ील्ड और बदलने का नियम बताती है. यह अधूरा हिस्सा भी सामने रखती है. ख़रीदारी इवेंट को रिव्यू अनुरोध या कैंपेन निर्णय बनाने से पहले अलग नीति चाहिए.
सिंक चलने से पहले उसकी समीक्षा करें
ग्राहक अपडेट मेरे ईमेल प्लेटफ़ॉर्म पर सिंक करें.
ग्राहक सिंक
| स्रोत फ़ील्ड | डेस्टिनेशन फ़ील्ड | नियम |
|---|---|---|
email | EMAIL | सीधा |
first_name | FIRSTNAME | सीधा |
last_name | LASTNAME | सीधा |
कृत्रिम डेटा वाला प्रीव्यू सफल
3 फ़ील्ड मैप हुए · डेस्टिनेशन पर कोई राइट नहीं
यह उदाहरणात्मक लेआउट Tajo के मैपिंग टूल पर आधारित है. कृत्रिम प्रीव्यू और सेव किया गया ड्राफ़्ट सिंक चालू नहीं करते.
व्यावहारिक स्वीकृति टेस्ट ट्रेस खुद उपयोग करता है. टेस्ट वातावरण में सामान्य ऑर्डर और अपवाद फिर चलाएं. केवल API कॉल सफल नहीं, डेस्टिनेशन की अंतिम स्थिति जांचें. फिर सुधार रास्ता परखें. डेस्टिनेशन कार्य कर चुका हो और स्रोत रिकॉर्ड बाद में बदले तो सिस्टम उसे मिला सकता है?
आपत्ति उचित है: “बनाने से पहले हर कठिन मामला नहीं देख सकते.” सही. लक्ष्य पूर्ण गिनती नहीं. पहली प्रति चलेगी या नहीं तय करने वाले कुछ छिपे चरण खोजने हैं. उच्च असर वाले रास्तों से शुरू करें, अज्ञात दर्ज करें और कनेक्शन में ऐसा निरीक्षण रखें कि नए अपवाद दिखें.
वर्कफ़्लो चित्र तब उपयोगी है जब काम चलाने वाले उसमें गायब डिब्बा दिखा सकें.
अक्सर पूछे जाने वाले प्रश्न
वर्कफ़्लो विवरण के लिए इंटरव्यू पर्याप्त क्यों नहीं?
लोग इच्छित प्रक्रिया सही बता सकते हैं, लेकिन दुर्लभ अपवाद या नियमित अस्थायी उपाय छोड़ सकते हैं. उनके बयान को अनुमत रिकॉर्ड से मिलाएं और अंतर समझने को कहें.
क्या सिस्टम लॉग पूरा वर्कफ़्लो दिखाते हैं?
नहीं. लॉग रिकॉर्ड हुए कार्य दिखाते हैं, अक्सर कारण, ऑफ़लाइन काम या सिस्टम के बाहर निर्णय नहीं. उनसे ऑपरेटर के लिए सवाल बनाएं, अकेले मंशा न निकालें.
पहले सिंक ट्रेस में क्या होना चाहिए?
एक सामान्य और एक अपवाद आइटम को स्रोत रिकॉर्ड, बदलाव, हैंडऑफ़ और डेस्टिनेशन स्थिति तक देखें. बेमेल स्थिति कौन सुधार सकता है और कौन सा प्रमाण अंतिम परिणाम पुष्टि करता है, लिखें.