Steve Trucking, मैं इसे कैसे आर्किटेक्ट करता

🌐 28 अन्य भाषाओं में भी उपलब्ध

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI से बनाई गई इमेज

AI द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 6 (कुल 6 में से) — अध्याय मास्टर डेटा और पहचान, Data Architect कोर्स का अध्याय 6, और भाग 1 का अंत। पिछला: जब अधिकार साझा हो · अगला: भाग 2 स्केल के लिए डिज़ाइन (coming soon) से शुरू होता है

यह चेकपॉइंट किस सवाल का जवाब देता है: क्या आप भाग 1 को एक असली परिदृश्य पर एक साथ रख सकते हैं?

पहले चुनौती आज़माएँ। यह चेकपॉइंट 1 की चुनौती का मेरा हल है। अगर आपने अभी तक अपना डिज़ाइन नहीं बनाया, तो आगे पढ़ने से पहले वह कर लें। असली फ़ायदा अपनी सोच की तुलना मेरी सोच से करने में है, जवाब पढ़ लेने में नहीं।

यह “मैं इसे कैसे आर्किटेक्ट करता” है: एक संभव और व्यावहारिक हल, एकमात्र जवाब नहीं, जिसमें ट्रेड-ऑफ़ के नाम लिए गए हैं और मैंने अपनी राय रखी है। हमने अभी तक बड़े डेटा वॉल्यूम, क्वेरी डिज़ाइन, इंटीग्रेशन पैटर्न, माइग्रेशन या ट्रांज़ैक्शन नहीं पढ़े, और ऐसा जान-बूझकर है: जैसे-जैसे आप ज़्यादा सीखते हैं, आर्किटेक्चर विकसित होता है। लेकिन भाग 1 हमें हड्डियाँ जमाने के लिए काफ़ी देता है।

आँकड़ों से शुरू करें

Brief से: हर कामकाजी दिन लगभग 3,300 डिलीवरी, साल में एक मिलियन, हर साल 30% की बढ़त। हर डिलीवरी पर लगभग 1.6 लाइन आइटम (साल में 1.6 मिलियन); हर डिलीवरी पर लगभग आठ स्टेटस बदलाव (साल में 8 मिलियन); साल में चार से पाँच मिलियन फ़ोटो; दिन में लगभग 200,000 GPS रीडिंग; साल में लगभग 180,000 cases; तीन रिटेल पार्टनर जो तीन अलग तरीकों से मैनिफ़ेस्ट भेजते हैं; नौ डिस्ट्रिब्यूशन सेंटर; दो-व्यक्ति वाले क्रू के साथ 330 ट्रक। और Steve Trucking पहले से Service Cloud, Field Service और एक पार्टनर पोर्टल के साथ एक Salesforce org चलाता है। एक भी बॉक्स बनाने से पहले शून्य गिनें। नीचे कई चीज़ें वही तय करेंगे।

डिलीवरी का केंद्र: मदरशिप की ओर देखें

डिलीवरी इसका दिल है, और Field Service पहले से dispatch करता है। इसलिए मैं Field Service के स्टैंडर्ड मॉडल से शुरू करता हूँ, जैसा अध्याय 3 के हिस्से ने किया था:

बिज़नेस अवधारणा	Salesforce ऑब्जेक्ट	क्यों
रिटेल पार्टनर	Account (Retail Partner रिकॉर्ड टाइप)	एक बिज़नेस जिससे Steve Trucking कॉन्ट्रैक्ट करता है; कॉन्ट्रैक्ट, cases और पोर्टल access इसी पर
पार्टनर का स्टाफ़ (DC मैनेजर, स्टोर स्टाफ़)	Contact	पोर्टल यूज़र्स का Contact होना ज़रूरी है
एक डिलीवरी: एक प्राप्तकर्ता, एक पता, एक पार्टनर ऑर्डर, एक दिन	Work Order (कार्य आदेश)	Field Service की काम की इकाई; शेड्यूलिंग, मोबाइल ऐप और service reports इसी से जुड़े हैं
हर आइटम या सेवा: फ़्रिज, इंस्टॉल, पुराना सामान उठाना	Work Order Line Item	काम को बाँटता है, चेकलिस्ट और इनवॉइसिंग चलाता है
स्टॉप का प्रकार: सिर्फ़ डिलीवरी, इंस्टॉल के साथ, पुराना सामान उठाने के साथ	Work Type	अवधि, कौशल और इंस्टॉल चेकलिस्ट तय करता है
शेड्यूल की गई विज़िट और उसकी विंडो	Service Appointment	जिसे Field Service शेड्यूल करता है और क्रू का ऐप दिखाता है
क्रू और ट्रक; DC के dispatch क्षेत्र	Service Resource, Service Crew, Service Territory	Field Service एक क्रू को एक resource के रूप में शेड्यूल करता है
प्राप्तकर्ता की पूछताछ, पार्टनर के क्लेम	Case	सर्विस कंसोल, entitlements, email-to-case
Phoenix DC पर मंगलवार के लिए पार्टनर की सूची	Manifest__c (कस्टम)	पाने, मिलान करने और दोबारा चलाने (replay) की इकाई को कोई स्टैंडर्ड ऑब्जेक्ट नहीं दर्शाता

बाकी सब स्टैंडर्ड रहता है। और कस्टम ऑब्जेक्ट से बचना जान-बूझकर है: अध्याय 1 का सवाल था कि आर्किटेक्ट को एक और कस्टम ऑब्जेक्ट का विरोध कब करना चाहिए, और यहाँ जवाब है “लगभग हमेशा।” मिसाल के तौर पर, पार्टनर की ऑर्डर लाइन कोई नया ऑब्जेक्ट नहीं है। यह Work Order ही है, जिसे पार्टनर के रेफ़रेंस से पहचाना जाता है।

Click to enlarge

यह अध्याय 3 के अंतिम डायग्राम (Salesforce फ़िज़िकल मॉडल डिज़ाइन करें) से बढ़ता है: वही ऑब्जेक्ट उन्हीं जगहों पर, साथ में क्रू, dispatch क्षेत्र, case और वह सब जोड़ा गया है जिसे चेकपॉइंट 1 core से बाहर रखता है।

वह key जो पार्टनर के ऑर्डर को डिलीवरी से मिलाती है

हर मैनिफ़ेस्ट लाइन एक Work Order बनती है, जो अपने मैनिफ़ेस्ट से जुड़ी होती है। Key वह सवाल है जिसका जवाब मैं सबसे ज़्यादा चाहता हूँ: हमें कैसे पता कि पार्टनर की यह लाइन वही डिलीवरी है? मेरा जवाब: Work Order पर एक External ID, जो रिटेल पार्टनर और पार्टनर के अपने ऑर्डर और डिलीवरी रेफ़रेंस से बनी हो (कुछ ऐसी: KEYSTONE-PHX-8843119-1), और unique चिह्नित हो। हर स्रोत के लिए एक फ़ील्ड, एक-से-एक। यह पार्टनर का ID है, हमारा नहीं: अध्याय 2 का “एक चीज़ के कई ID,” और मॉड्यूल 1 का “पार्टनर अपने ऑर्डर रेफ़रेंस का मालिक है।”

यह क्यों मायने रखती है: मैनिफ़ेस्ट एक-दो दिन पहले आते हैं और उसी दिन बदल दिए जाते हैं। उस key के साथ, हर दोबारा भेजा गया या बदला गया मैनिफ़ेस्ट डुप्लिकेट बनाने के बजाय upsert होता है। बदलाव Work Order को अपडेट करता है, एक फ़ील्ड उसे दर्ज करता है, और पहले से रूट हो चुकी डिलीवरी में बदलाव कोऑर्डिनेटर को सचेत करता है: पार्टनर का बदलाव लागू होता है, लेकिन dispatch की पुष्टि तक उस पर निशान लगा रहता है। अध्याय 4 की तस्वीर से यही बदलता है। आज हर मैनिफ़ेस्ट RouteDesk में उतरता है, और कोऑर्डिनेटर रूट को Salesforce में और पूरे हुए स्टॉप को वापस दोबारा टाइप करते हैं। इस डिज़ाइन में मैनिफ़ेस्ट सीधे Salesforce में आते हैं, पार्टनर की key से upsert होकर; RouteDesk रिटायर हो जाता है, और दोबारा टाइप करना खत्म। इंटीग्रेशन वाला अध्याय तीनों अंदर आने वाले फ़ॉर्मेट डिज़ाइन करता है। डेटा का फ़ैसला key है।

प्राप्तकर्ता: Person Account, Contact, या दोनों में से कोई नहीं?

यह भाग 1 का सबसे दिलचस्प डेटा फ़ैसला है, इसलिए पहले विकल्प, फिर मेरी पसंद।

विकल्प A: person accounts। हर प्राप्तकर्ता एक person account बनता है, जो हर डिलीवरी से जुड़ा हो। पक्ष में: स्टैंडर्ड है, Service Cloud, मैसेजिंग और कंसोल के साथ स्वाभाविक रूप से चलता है, बार-बार आने वाले प्राप्तकर्ताओं को पहचानता है। विपक्ष में: साल में लगभग एक मिलियन नए प्राप्तकर्ता, हर एक person account जो business account से लगभग दोगुना स्टोरेज लेता है (Estimated Record Size by Object Type (opens in a new tab)), यानी दो साल के अंदर org के सबसे बड़े ऑब्जेक्ट में से एक। और प्राप्तकर्ता Steve Trucking के ग्राहक नहीं हैं। वे हर रिटेल पार्टनर के ग्राहक हैं, और Steve Trucking को कभी एक पार्टनर के ग्राहक को दूसरे के ग्राहक के साथ नहीं मिलाना चाहिए (S2)।

विकल्प B: रिटेल पार्टनर के account के नीचे Contacts। विपक्ष में: तीन-चार accounts के नीचे एक मिलियन Contacts बहुत बड़े पैमाने का parent-child skew है, Salesforce की लगभग 10,000 children प्रति parent की सलाह से बहुत आगे (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab))। यह विकल्प दिखाने के लिए है, और खारिज करने के लिए।

विकल्प C: प्राप्तकर्ता डिलीवरी पर रहता है। प्राप्तकर्ता का नाम, फ़ोन, ईमेल, पता और डिलीवरी नोट्स Work Order पर फ़ील्ड हैं (पते के फ़ील्ड वहाँ पहले से स्टैंडर्ड हैं), जो मैनिफ़ेस्ट से लिए जाते हैं। पक्ष में: कोई नया बड़ा ऑब्जेक्ट नहीं; डेटा ठीक उतने समय रहता है जितना डिलीवरी को चाहिए; डिलीट हर डिलीवरी के हिसाब से, पार्टनर के शेड्यूल पर होता है; और पार्टनर्स का अलगाव मुफ़्त में मिलता है, क्योंकि हर डिलीवरी एक ही पार्टनर की है। विपक्ष में: बार-बार आने वाले प्राप्तकर्ता को एक ही व्यक्ति के रूप में नहीं पहचाना जाता।

यही संतुलन साधना है। क्या कभी कई डिलीवरी को एक ही जगह पर एक ही व्यक्ति के रूप में पहचानने की ज़रूरत पड़ेगी? उस व्यक्ति को लॉगिन देने की? यही वह रेखा है जो उस प्राप्तकर्ता को, जिसे अपना एक रिकॉर्ड चाहिए, उन प्राप्तकर्ता विवरणों से अलग करती है जो बस डिलीवरी के बारे में डेटा हैं। और एक बीच का रास्ता भी है। रिटेल पार्टनर का अपना ग्राहक ID डिलीवरी पर एक फ़ील्ड के रूप में रखें, एक Retail Partner Customer ID। यह कोई प्राप्तकर्ता रिकॉर्ड नहीं बनाता, लेकिन उन डिलीवरी को जोड़ता है जो एक पार्टनर एक ही ग्राहक के लिए भेजता है, जो ज़्यादा एकीकृत ग्राहक अनुभव की शुरुआत है, और यह सीधे रिटेल पार्टनर के सिस्टम तक वापस ले जाता है, जहाँ वह ग्राहक असल में रहता है। यह उनका ID है, इसलिए इसका मतलब सिर्फ़ पार्टनर के साथ मिलकर है: एक पार्टनर के ग्राहक 4417 का दूसरे पार्टनर के ग्राहक 4417 से कोई लेना-देना नहीं।

मेरी पेशेवर राय में, विकल्प C सही चुनाव है। न पहचाने जाने वाला हिस्सा स्वीकार्य है, बल्कि वांछनीय भी: डिलीवरी के आगे Steve Trucking का इन लोगों से कोई संबंध नहीं है। यह फिर मॉड्यूल 1 है: प्राप्तकर्ता पार्टनर का ग्राहक है, और वे कौन हैं, इसका अधिकारी पार्टनर है। और यह अध्याय 5 है: जो निजी डेटा एक जगह आता है, एक डिलीवरी से बँधा, उसे सुरक्षित रखना, सहेजना और डिलीट करना कहीं आसान है। और यह अध्याय 2 के नॉर्मल फ़ॉर्म की कसौटी पर भी खरा उतरता है: प्राप्तकर्ता के विवरण डिलीवरी के साथ एक-से-एक हैं, इसलिए वे उसी पर होने चाहिए। एक अलग प्राप्तकर्ता child कुछ दोहराए गए मान बचाएगा, लेकिन एक और ऑब्जेक्ट, एक और संबंध और उसके बोझ की कीमत पर, और इससे ज़्यादा बचत का एकमात्र तरीका यह होगा कि एक ही व्यक्ति को सभी रिटेल पार्टनर्स में एक माना जाए, जो हम नहीं करेंगे। इसलिए डिलीवरी प्राप्तकर्ता को साथ रखती है, और Retail Partner Customer ID पार्टनर के अपने सिस्टम तक लौटने का रास्ता है।

Click to enlarge

क्या मैं पार्टनर्स के पार प्राप्तकर्ताओं को एकीकृत करूँगा?

John Smith, 123 Main Street, Redrock के मैनिफ़ेस्ट में भी आता है और Brightwave के में भी। शायद एक ही व्यक्ति। क्या Steve Trucking को उन्हें एकीकृत करना चाहिए? नहीं, जान-बूझकर नहीं। रिटेल पार्टनर्स के पार प्राप्तकर्ताओं को एकीकृत करना S2 को तोड़ेगा: किसी पार्टनर को कभी दूसरे पार्टनर के प्राप्तकर्ता नहीं दिखने चाहिए, और एक यूनिफ़ाइड पहचान ठीक वही पुल है जिससे जानकारी रिसती है। यह इस अध्याय की राय ही लागू हो रही है: जहाँ घुल-मिल जाना महँगा है, वहाँ कम मैच करें, और यहाँ घुल-मिल जाना बहुत महँगा है।

अगर बाद में कोई रिटेल पार्टनर अपनी ही डिलीवरी के अंदर बार-बार आने वाले प्राप्तकर्ताओं को पहचानना चाहे, तो यह आइडेंटिटी रेज़ोल्यूशन टूल का काम है, जैसे Data 360 का, उसी पार्टनर तक सीमित: रजिस्ट्री जैसा एक नक्शा, person account नहीं, और कभी पार्टनर्स के पार नहीं। कौन कौन है, इसका नक्शा स्वामित्व नहीं देता, और access भी नहीं देता।

Org में क्या रहता है, और क्या नहीं

अध्याय 3 ने पूछा था कि डेटा कहाँ रहना चाहिए। यहाँ शून्य इसका जवाब देते हैं:

• मौजूदा स्टेटस Service Appointment और Work Order पर रहता है। स्टेटस बदलावों का इतिहास, साल में लगभग 8 मिलियन और बढ़ता हुआ, core org में रहने की ज़रूरत नहीं। हर बदलाव एक event के रूप में प्रकाशित होता है और warehouse, Snowflake, में रखा जाता है। Org मौजूदा स्थिति रखता है; इतिहास सर्विस, ऑपरेशंस और एनालिटिक्स के लिए फिर भी मौजूद है, बस ऑपरेशनल डेटाबेस में नहीं।
• फ़ोटो (साल में चार से पाँच मिलियन, कुछ में लोग या घर का अंदरूनी हिस्सा दिखता है) core से बाहर उस वॉल्यूम के लिए बने स्टोरेज में रहते हैं, जो सीधे क्रू के ऐप से अपलोड होते हैं। Org सिर्फ़ वही रखता है जो उसे चाहिए: हर फ़ोटो का एक छोटा इंडेक्स रिकॉर्ड, या बस एक गिनती और एक “required install photos complete” flag। मेरी पसंद हल्का विकल्प है: org को हल्का रखें, और फ़ोटो स्टोर को अपने इंडेक्स और रिटेंशन का मालिक बनने दें।
• GPS रीडिंग (दिन में 200,000) FleetLink में रहती हैं और Snowflake में जाती हैं; org को ट्रैकिंग पेज और dispatcher के नक्शे के लिए सिर्फ़ ताज़ा पोज़िशन चाहिए।
• RouteDesk का आठ साल का इतिहास (लगभग 5 मिलियन डिलीवरी) warehouse या एक आर्काइव में जाता है, जहाँ क्लेम के लिए पहुँचा जा सके। Org में क्या आएगा, अगर कुछ आएगा, यह भाग 2 के लिए माइग्रेशन का फ़ैसला है।

Click to enlarge

चेकपॉइंट 1: मैं इसे कैसे आर्किटेक्ट करता। अध्याय 4 के लैंडस्केप (Steve Trucking का लैंडस्केप) वाली ही जगहें, बस दोबारा टाइप करना और spreadsheet ग़ायब।

कौन क्या देखता है, और किसे लाइसेंस चाहिए

• रिटेल पार्टनर सिर्फ़ अपनी डिलीवरी देखते हैं (S2)। हर Work Order अपने रिटेल पार्टनर को साथ रखता है; पोर्टल यूज़र अपने पार्टनर की डिलीवरी देखते हैं, और DC मैनेजर सिर्फ़ अपने DC की।
• पार्टनर यूज़र्स को ऐसा पोर्टल लाइसेंस चाहिए जो शेयरिंग रूल और रोल सपोर्ट करे: Customer Community Plus या Partner Community। अध्याय 3 के स्टेडियम की सीटें: सबसे सस्ती सीटों को वह शेयरिंग नहीं मिलती जो इस डिज़ाइन को चाहिए। दोनों लाइसेंसों को बाहरी यूज़र्स के लिए रोल चाहिए, और Salesforce चेतावनी देता है कि ज़्यादा रोल org को धीमा करते हैं (Experience Cloud User Licenses (opens in a new tab))। हर पार्टनर और हर DC के लिए एक रोल ठीक है; हर स्टोर के लिए एक रोल नहीं।

परीक्षा-ज्ञान। जानें कि किन बाहरी लाइसेंसों में स्टैंडर्ड शेयरिंग आती है: Customer Community Plus और Partner Community (बाहरी यूज़र्स के लिए रोल के साथ), Customer Community नहीं, जो sharing sets इस्तेमाल करता है।

• प्राप्तकर्ताओं को कोई लाइसेंस नहीं चाहिए। ट्रैकिंग पेज एक लिंक के ज़रिए एक डिलीवरी दिखाता है, जिसमें एक token होता है जिसकी मियाद खत्म हो जाती है (S3), लॉगिन नहीं।
• Skew पर नज़र रखें। साल में सैकड़ों हज़ार Work Orders का तीन-चार पार्टनर accounts की ओर इशारा करना account data skew है। एक विकल्प हर पार्टनर के नीचे हर DC के लिए एक child account है, जो children को नौ या ज़्यादा हिस्सों में बाँट देता है; क्लेम की अवधि के बाद पूरी हो चुकी डिलीवरी को आर्काइव करने से हर parent पर सक्रिय children कम रहते हैं। भाग 2 इससे निपटता है।

मैं क्या नहीं करूँगा

मैं हर प्राप्तकर्ता के लिए सिर्फ़ इसलिए person account नहीं बनाऊँगा क्योंकि प्राप्तकर्ता एक व्यक्ति है। मैं तीन accounts के नीचे एक मिलियन Contacts नहीं लटकाऊँगा। मैं Field Service के Work Order के बगल में एक कस्टम Delivery ऑब्जेक्ट नहीं बनाऊँगा। मैं पार्टनर्स के पार प्राप्तकर्ताओं को एकीकृत नहीं करूँगा। मैं मिलियन की संख्या में फ़ोटो या GPS रीडिंग core स्टोरेज में नहीं रखूँगा। और मैं किसी एकीकृत प्राप्तकर्ता को गोल्डन रिकॉर्ड नहीं कहूँगा, जब तक हमने सच में मास्टरिंग का फ़ैसला न लिया हो।

अभी क्या खुला है

भाग 1 ने हड्डियाँ जमाईं; भाग 2 उन्हें परखता है। तीसरे साल में LDV का पैमाना (Work Orders, Service Appointments और लाइन आइटम, सब दो-तीन साल में बड़े वॉल्यूम के इलाके में पहुँच जाते हैं), पार्टनर तक सीमित list views के लिए क्वेरी डिज़ाइन, तीन अंदर आने वाले इंटीग्रेशन और तीन स्टेटस feeds, RouteDesk का माइग्रेशन, उसी दिन के ट्रांज़ैक्शन, और पोर्टल के पीछे का सिक्योरिटी डिज़ाइन। Steve Trucking भी बदलेगा। यह डिज़ाइन सँभालकर रखें; आप इस पर लौटेंगे।

आर्किटेक्ट यहाँ क्या तय करता है

• कौन-से स्टैंडर्ड ऑब्जेक्ट केंद्र को संभालते हैं (यहाँ, Field Service के), और कौन-से कस्टम ऑब्जेक्ट सच में जायज़ हैं (यहाँ, एक)।
• वह key जो हर पार्टनर की ऑर्डर लाइन को एक डिलीवरी से मिलाती है, और वह पार्टनर की क्यों है।
• प्राप्तकर्ता क्या है, उस संबंध के आधार पर जो Steve Trucking का असल में उनसे है।
• पहचानों को एकीकृत करना है या नहीं, और कहाँ घुल-मिल जाने का जोखिम बहुत महँगा है।
• Org में क्या रहता है, core से बाहर क्या रहता है, और डिज़ाइन किन लाइसेंसों पर निर्भर है।

और जानें

• Steve Trucking brief और चुनौतियाँ (D1, D3, DC1)।
• Salesforce Help, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) और Experience Cloud User Licenses (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (अंग्रेज़ी में), जैसा अध्याय 3 में उद्धृत है।