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