यह दो रिलीज रहा है क्योंकि मुझे एस 2 एस एकीकरण करना पड़ा है, लेकिन मैं एक अप्रत्याशित समस्या में भाग गया जो उम्मीद है कि कोई अधिक प्रभावी ढंग से हल कर सकता है।सेल्सफोर्स-टू-सेल्सफोर्स राउंड ट्रिप फ़ील्ड अपडेट इश्यू
मेरे पास दो संगठन हैं, एस 2 एस पर संपर्क साझा करते हैं।
प्रत्येक संगठन में संपर्क समान स्कीमा है, यह मानक फ़ील्ड प्लस कस्टम फ़ील्ड है। मैं सिर्फ दो कस्टम क्षेत्रों के साथ एक आधार मामले reproduced किया है: चेकबॉक्स क्षेत्र ए, और संख्या (18,0) क्षेत्र बी
संगठन 1 क्षेत्र एक प्रकाशित करता है, और बी
संगठन 2 सदस्याएं क्षेत्ररक्षण का सदस्य बनता फील्ड ए के लिए, और फ़ील्ड बी प्रकाशित करता है।
संगठन 1 एस 2 एस पर ऑर्गे 2 में संपर्क साझा करके सभी एस 2 एस वर्कफ़्लो शुरू करता है। संगठन 2 पर स्वतः स्वीकार किया गया है।
संगठन 2 में ट्रिगर डालने से पहले एक संपर्क है जो फ़ील्ड बी के लिए मान की गणना करने के लिए केवल फील्ड ए का उपयोग करता है। उदा। यदि फ़ील्ड ए की जांच की जाती है, तो फ़ील्ड बी को 2 के साथ पॉप्युलेट करें, अगर अनचेक किया गया है, 0. (यह निश्चित रूप से मुझे जो करने की ज़रूरत है, उसका एक बहुत अधिक सरलीकरण है, लेकिन यह मूल प्रतिलिपि बनाने वाला मामला है।)
यह सब काम करता है संगठन 2 में ठीक है - संपर्क फ़ील्ड ए के साथ ठीक से आते हैं, और मुझे लगता है कि फ़ील्ड के परिणाम फ़ील्ड बी में गणना की जाती हैं।
समस्या यह है कि परिणाम - फ़ील्ड बी - ऑर्ग 1 तक ऑटो-साझा नहीं किया जाता है अगला संपर्क अपडेट। यह उतना ही आसान हो सकता है जितना कि उसी विवरण पर एक गैर-साझा फ़ील्ड को संपादित करना, जैसे कि "विवरण", ऑर्गे 2 में, और फिर मैं तुरंत फील्ड बी के पहले गणना किए गए मान को ऑर्ग पर वापस धकेलता हूं।
मुझे लगता है कि ऐसा इसलिए है क्योंकि, चूंकि फील्ड बी की गणना पहले सम्मिलित करने के भीतर होती है, एस 2 एस कनेक्शन मानता है कि वर्तमान अद्यतन लेनदेन केवल स्वयं ही किया जाता है (मैं देख सकता हूं कि यह तर्क अनंत एस 2 एस अपडेट को रोकने के लिए कैसे समझ जाएगा छोरों)।
मैंने पहली बार वर्कफ़्लो फ़ील्ड अपडेट बनाने का प्रयास किया जिसने फ़ील्ड बी बदलते समय जबरन अद्यतन (नया, डमी) साझा फ़ील्ड अपडेट किया, लेकिन फिर भी अपडेट को वापस प्रवाह नहीं हुआ, संभवतः क्योंकि यह उसी निष्पादन संदर्भ में है जो सेल्सफोर्स पुनः साझा करने से मुक्त माना जाता है। एक वर्कफ़्लो नियम भी आज़माया जिसने फ़ील्ड को बदलते समय लीड को कनेक्शन कतार में अग्रेषित किया, और यह भी काम नहीं किया।
मैंने फिर एक आफ्टर अपडेट ट्रिगर में पुनः अद्यतन विवरण का प्रयास किया - यदि साझा फ़ील्ड अपडेट किया गया है, तो साझा ऑब्जेक्ट को पुनः लोड और पुनः अपडेट करें। वह भी काम नहीं किया।
मुझे एक समाधान मिला, जो कि फॉरवर्ड विधि है जिसे आफ्टरअपडेट ट्रिगर द्वारा बुलाया जाता है जो किसी भी रिकॉर्ड को फिर से लोड करता है और स्पर्श करता है जिसने अपने साझा क्षेत्र को पहले अद्यतन ट्रिगर द्वारा बदल दिया था। इससे क्षेत्र के परिणाम मूल संगठन में निकट-वास्तविक समय में दिखाई देते हैं।
यह समाधान अब मेरे लिए काम करता है, लेकिन मुझे लगता है कि मुझे कुछ याद आना चाहिए। यह आवश्यक होने की तुलना में अधिक भविष्य कॉल और डीएमएल निष्पादित करने का तरीका बनता है।
क्या किसी के पास इसके लिए एक और अधिक शानदार समाधान है?
प्रकाशित होंगे, मैं 'भविष्य 'के साथ रहूंगा। अगर मैं इस सुविधा के लिए डेवलपर के जूते में खुद को डाल रहा था, तो शायद वे अनंत लूप बनाने के बारे में चिंताओं के लिए प्रकाशित फ़ील्ड में संगठन 2 में किए गए अपडेट की जांच नहीं करते हैं। अगर वे उस मामले को संभाल नहीं पाते हैं, कोई लूप संभावना, आसान देव, और अगली सुविधा पर नहीं। मुझे 'भविष्य' पसंद है क्योंकि यह साइड इफेक्ट्स का लाभ उठाए बिना वही करता है (जिसमें बिना किसी सूचना के भविष्य की रिलीज में गायब होने की बुरी आदत है) –