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)
الوحدة 6 من 6 في فصل البيانات الرئيسية والهوية، الفصل 6 من دورة Data Architect، ونهاية الجزء 1. السابق: عندما تكون المرجعية مشتركة · التالي: يبدأ الجزء 2 بـ التصميم للنطاق الواسع (coming soon)
السؤال الذي تجيب عنه نقطة التحقق هذه: هل تستطيع أن تجمع الجزء 1 كله على سيناريو حقيقي؟
جرّب التحدي أولًا. هذا شرحي لـ تحدي نقطة التحقق 1. إن لم ترسم تصميمك الخاص بعد، فافعل ذلك قبل أن تتابع القراءة. القيمة في مقارنة تفكيرك بتفكيري، لا في قراءة الإجابة.
هذا «كيف كنت سأصمّمها» (What I Would Architect): حل ممكن وقابل للتطبيق، لا الحل الوحيد، مع تسمية المفاضلات واتخاذ مواقفي. لم نغطِّ بعد أحجام البيانات الكبيرة، ولا تصميم الاستعلامات، ولا أنماط التكامل، ولا الترحيل، ولا المعاملات، وهذا مقصود: المعمارية تنضج كلما تعلّمت أكثر. لكن الجزء 1 يعطينا ما يكفي لنضع الهيكل العظمي.
ابدأ بالأرقام
Section titled “ابدأ بالأرقام ”من الملخص: نحو 3,300 توصيلة في يوم العمل، أي مليون في السنة، بنمو 30% سنويًا. ونحو 1.6 بند لكل توصيلة (1.6 مليون في السنة)؛ ونحو ثماني تغييرات حالة لكل توصيلة (8 ملايين في السنة)؛ ومن أربعة إلى خمسة ملايين صورة في السنة؛ ونحو 200,000 قراءة GPS في اليوم؛ ونحو 180,000 حالة في السنة؛ وثلاثة شركاء تجزئة يرسلون بيانات الشحنة بثلاث طرق مختلفة؛ وتسعة مراكز توزيع؛ و330 شاحنة بطواقم من شخصين. وتشغّل Steve Trucking بالفعل مؤسسة Salesforce (org) واحدة فيها Service Cloud وField Service وبوابة للشركاء. عُدّ الأصفار قبل أن ترسم مربعًا واحدًا. فهي ستحسم عدة أمور أدناه.
نواة التوصيل: انظر إلى السفينة الأم
Section titled “نواة التوصيل: انظر إلى السفينة الأم ”التوصيلات هي القلب، وField Service يتولى الإرسال (dispatch) بالفعل. لذلك أبدأ بنموذج Field Service القياسي، كما فعلت الشريحة في الفصل 3:
| مفهوم العمل | كائن Salesforce | السبب |
|---|---|---|
| شريك التجزئة | حساب (Account) (نوع سجل Retail Partner) | جهة تتعاقد معها Steve Trucking؛ تحمل العقود والحالات والوصول إلى البوابة |
| موظفو الشريك (مديرو مراكز التوزيع، وموظفو المتاجر) | جهة اتصال (Contact) | مستخدمو البوابة يجب أن يكونوا جهات اتصال |
| توصيلة واحدة: مستلم واحد، وعنوان واحد، وطلب شريك واحد، ويوم واحد | أمر العمل (Work Order) | وحدة العمل في Field Service؛ تتفرع منها الجدولة والتطبيق المحمول وتقارير الخدمة |
| كل صنف أو خدمة: الثلاجة، والتركيب، وأخذ القديم | بند أمر العمل (Work Order Line Item) | يقسّم العمل، ويحرّك قوائم التحقق والفوترة |
| نوع المحطة: توصيل فقط، أو مع تركيب، أو مع أخذ القديم | نوع العمل (Work Type) | يحدد المدة والمهارات وقائمة التحقق من التركيب |
| الزيارة المجدولة ونافذتها | موعد الخدمة (Service Appointment) | ما يجدوله Field Service ويعرضه تطبيق الطاقم |
| الطواقم والشاحنات؛ ومناطق الإرسال لمراكز التوزيع | Service Resource وService Crew وService Territory (مورد الخدمة، وطاقم الخدمة، ومنطقة الخدمة) | يجدول Field Service الطاقم كمورد واحد |
| استفسارات المستلمين، ومطالبات الشركاء | حالة (Case) | وحدة تحكم الخدمة، والاستحقاقات، وemail-to-case |
| قائمة الشريك ليوم الثلاثاء في مركز توزيع فينيكس | Manifest__c (مخصص) | لا شيء قياسي يمثّل وحدة الاستلام والتسوية وإعادة المعالجة |
كل ما عدا ذلك يبقى قياسيًا. مقاومة المزيد من الكائنات المخصصة أمر مقصود: سؤال الفصل 1 كان متى ينبغي للمعماري أن يقاوم كائنًا آخر، وهنا الإجابة «في كل الأحوال تقريبًا». سطر طلب الشريك، مثلًا، ليس كائنًا جديدًا. إنه أمر العمل، معرَّفًا بمرجع الشريك.
إنه ينمو من المخطط الختامي في الفصل 3 (صمّم النموذج المادي في Salesforce): الكائنات نفسها في الأماكن نفسها، مع إضافة الطاقم، ومنطقة الإرسال، والحالة، وما تبقيه نقطة التحقق 1 خارج النواة.
المفتاح الذي يطابق طلب الشريك مع التوصيلة
Section titled “المفتاح الذي يطابق طلب الشريك مع التوصيلة ”كل سطر في بيان الشحنة يصبح أمر عمل واحدًا، مرتبطًا ببيان الشحنة الخاص به. والمفتاح هو السؤال الذي أريد إجابته أكثر من أي شيء: كيف نعرف أن هذا السطر من الشريك هو تلك التوصيلة؟ إجابتي: External ID على أمر العمل مبني من شريك التجزئة ومرجع الطلب والتوصيلة الخاص بالشريك (شيء مثل KEYSTONE-PHX-8843119-1)، ومعلَّم بأنه فريد. حقل واحد لكل مصدر، واحد لواحد. إنه معرّف الشريك، لا معرّفنا: «عدة معرّفات لشيء واحد» من الفصل 2، و«الشريك يملك مرجع طلبه» من الوحدة 1.
لماذا يهم: تصل بيانات الشحنة قبل يوم أو يومين وتُعدَّل في اليوم نفسه. بهذا المفتاح، كل بيان شحنة يُعاد إرساله أو يُعدَّل يُجري upsert بدلًا من إنشاء تكرارات. يحدّث التعديل أمر العمل، ويسجله حقل، والتغيير على توصيلة خُطِّط مسارها بالفعل ينبّه المنسّق: يُطبَّق تغيير الشريك، لكنه يبقى معلَّمًا حتى يؤكده الإرسال. وهذا أيضًا ما يتغير عن صورة الفصل 4. اليوم يصل كل بيان شحنة إلى RouteDesk، ويعيد المنسقون إدخال المسارات يدويًا في Salesforce والمحطات المكتملة في الاتجاه المعاكس. في هذا التصميم تأتي بيانات الشحنة مباشرة إلى Salesforce، عبر upsert بمفتاح الشريك؛ ويتقاعد RouteDesk، وتنتهي إعادة الإدخال. فصل التكامل يصمّم الصيغ الواردة الثلاث. أما قرار البيانات فهو المفتاح.
المستلم: حساب شخصي، أم جهة اتصال، أم لا هذا ولا ذاك؟
Section titled “المستلم: حساب شخصي، أم جهة اتصال، أم لا هذا ولا ذاك؟ ”هذا أكثر قرارات البيانات إثارة للاهتمام في الجزء 1، لذا إليك الخيارات، ثم اختياري.
الخيار A: الحسابات الشخصية. يصبح كل مستلم حسابًا شخصيًا (Person Account)، مرتبطًا بكل توصيلة. مع: قياسي، ويعمل بشكل طبيعي مع Service Cloud والمراسلات ووحدة التحكم، ويتعرف على المستلمين المتكررين. ضد: نحو مليون مستلم جديد في السنة، كلٌّ منهم حساب شخصي بنحو ضعف مساحة تخزين حساب الأعمال (Estimated Record Size by Object Type (opens in a new tab))، فيصبح خلال سنتين من أكبر الكائنات في الـ org. والمستلمون ليسوا عملاء Steve Trucking. إنهم عملاء كل شريك تجزئة، ويجب ألا تخلط Steve Trucking أبدًا عميل شريك بعميل شريك آخر (S2).
الخيار B: جهات اتصال تحت حساب شريك التجزئة. ضد: مليون جهة اتصال تحت ثلاثة أو أربعة حسابات هو انحراف أب-ابن (parent-child skew) على نطاق هائل، يتجاوز بكثير إرشاد Salesforce بنحو 10,000 سجل فرعي لكل أب (Considerations for Object Relationships (opens in a new tab)؛ Parent-Child Data Skew (opens in a new tab)). هذا الخيار يُعرض، ثم يُرفض.
الخيار C: المستلم يعيش على التوصيلة. اسم المستلم وهاتفه وبريده الإلكتروني وعنوانه وملاحظات التوصيل حقول على أمر العمل (حقول العنوان قياسية فيه أصلًا)، تُلتقط من بيان الشحنة. مع: لا كائن كبير جديد؛ والبيانات تعيش بالضبط ما دامت التوصيلة تحتاج إليها؛ والحذف يحدث لكل توصيلة، وفق جدول الشريك؛ وعزل الشركاء يأتي مجانًا، لأن كل توصيلة تنتمي إلى شريك واحد. ضد: المستلم المتكرر لا يُتعرَّف عليه بوصفه الشخص نفسه.
هذا هو التوازن المطلوب. هل ستكون هناك يومًا حاجة إلى التعرف على عدة توصيلات على أنها للشخص نفسه، في المكان نفسه؟ أو إلى إعطاء ذلك الشخص تسجيل دخول؟ هذا هو الخط الفاصل بين مستلم يحتاج إلى سجل خاص به، وتفاصيل مستلم هي ببساطة بيانات عن التوصيلة. وهناك طريق وسط. احمل معرّف العميل الخاص بشريك التجزئة كحقل على التوصيلة، Retail Partner Customer ID (معرّف عميل شريك التجزئة). إنه لا يُنشئ سجل مستلم، لكنه يربط التوصيلات التي يرسلها الشريك للعميل نفسه، وهذه بداية تجربة عملاء أكثر توحيدًا، ويقود مباشرة إلى نظام شريك التجزئة، حيث يعيش ذلك العميل فعلًا. إنه معرّفهم، فلا معنى له إلا مع الشريك: العميل 4417 لدى شريك لا علاقة له بالعميل 4417 لدى شريك آخر.
في رأيي المهني، الخيار C هو الاختيار الصحيح. أما جزء عدم التعرف فمقبول، بل مرغوب فيه: ليست لـ Steve Trucking علاقة بهؤلاء الأشخاص تتجاوز التوصيلة. إنها الوحدة 1 مرة أخرى: المستلم عميل الشريك، والشريك هو المرجع لهويته. وإنه الفصل 5: البيانات الشخصية التي تستقر في مكان واحد، مرتبطة بتوصيلة واحدة، أسهل بكثير في الحماية والاحتفاظ والحذف. وهو يصمد أمام الأشكال الطبيعية في الفصل 2: تفاصيل المستلم علاقتها بالتوصيلة واحد لواحد، فمكانها عليها. وسجل مستلم فرعي منفصل سيوفّر بضع قيم مكررة على حساب كائن آخر، وعلاقة أخرى وعبئها، والطريقة الوحيدة لأن يوفّر أكثر هي معاملة الشخص نفسه كشخص واحد عبر شركاء التجزئة، وهذا ما لن نفعله. لذلك تحمل التوصيلة المستلم، مع Retail Partner Customer ID كطريق العودة إلى نظام الشريك نفسه.
هل كنت سأوحّد المستلمين عبر الشركاء؟
Section titled “هل كنت سأوحّد المستلمين عبر الشركاء؟ ”John Smith، 123 Main Street، يظهر في بيان شحنة Redrock وفي بيان شحنة Brightwave. على الأرجح الشخص نفسه. هل ينبغي أن توحّدهما Steve Trucking؟ لا، وعن قصد. توحيد المستلمين عبر شركاء التجزئة سيخرق S2: يجب ألا يرى شريك أبدًا مستلمي شريك آخر، والهوية الموحّدة هي بالضبط الجسر الذي يتسرب منه ذلك. إنه موقف هذا الفصل مطبَّقًا: طابِق بأقل من اللازم حيث يكون الخلط مكلفًا، والخلط هنا مكلف جدًا.
إن أراد شريك تجزئة لاحقًا التعرف على المستلمين المتكررين داخل توصيلاته هو، فهذه مهمة لأداة حل هوية، كأداة Data 360، محصورة في ذلك الشريك: خريطة على طريقة السجل المركزي، لا حساب شخصي، ولا تكون أبدًا عبر الشركاء. خريطة من هو من لا تمنح ملكية، ولا تمنح وصولًا.
ما يبقى في الـ org، وما لا يبقى
Section titled “ما يبقى في الـ org، وما لا يبقى ”سأل الفصل 3 أين ينبغي أن تعيش البيانات. والأصفار تجيب هنا:
- الحالة الراهنة تعيش على موعد الخدمة وأمر العمل. أما تاريخ تغييرات الحالة، نحو 8 ملايين في السنة وفي ازدياد، فلا يحتاج إلى أن يعيش في الـ org الأساسي. كل تغيير يُنشر كحدث ويُحفظ في مستودع البيانات، Snowflake. يحتفظ الـ org بالحالة الراهنة؛ والتاريخ لا يزال موجودًا للخدمة والعمليات والتحليلات، لكن ليس في قاعدة البيانات التشغيلية.
- الصور (من أربعة إلى خمسة ملايين في السنة، بعضها يُظهر أشخاصًا أو داخل منزل) تعيش خارج النواة في تخزين مبني لهذا الحجم، وتُرفع مباشرة من تطبيق الطاقم. ويحتفظ الـ org بما يحتاج إليه فقط: سجل فهرس صغير لكل صورة، أو مجرد عدد وعلامة «اكتملت صور التركيب المطلوبة». وأنا أفضّل الخيار الأخف: أبقِ الـ org رشيقًا، ودع مخزن الصور يملك فهرسه واحتفاظه.
- قراءات GPS (200,000 في اليوم) تبقى في FleetLink وتذهب إلى Snowflake؛ ولا يحتاج الـ org إلا إلى آخر موقع لصفحة التتبع ولخريطة المُرسِل.
- ثماني سنوات من تاريخ RouteDesk (نحو 5 ملايين توصيلة) تذهب إلى مستودع البيانات أو إلى أرشيف، ويمكن الوصول إليها من أجل المطالبات. أما ما يدخل منها إلى الـ org، إن دخل شيء، فقرار ترحيل يخص الجزء 2.
نقطة التحقق 1: كيف كنت سأصمّمها. الأماكن نفسها كما في خريطة الأنظمة في الفصل 4 (خريطة أنظمة Steve Trucking)، وقد اختفت إعادة الإدخال وجدول البيانات.
من يرى ماذا، ومن يحتاج إلى ترخيص
Section titled “من يرى ماذا، ومن يحتاج إلى ترخيص ”- شركاء التجزئة لا يرون إلا توصيلاتهم (S2). كل أمر عمل يحمل شريك التجزئة الخاص به؛ ويرى مستخدمو البوابة توصيلات شريكهم، ومديرو مراكز التوزيع توصيلات مركزهم فقط.
- مستخدمو الشركاء يحتاجون إلى ترخيص بوابة يدعم قواعد المشاركة والأدوار: Customer Community Plus أو Partner Community. مقاعد الملعب في الفصل 3: أرخص المقاعد لا تحصل على المشاركة التي يحتاج إليها هذا التصميم. كلا الترخيصين يحتاج إلى أدوار للمستخدمين الخارجيين، وتحذّر Salesforce من أن كثرة الأدوار تبطئ الـ org (Experience Cloud User Licenses (opens in a new tab)). دور لكل شريك ولكل مركز توزيع لا بأس به؛ أما دور لكل متجر فلا.
معلومة للاختبار. اعرف أيّ التراخيص الخارجية تحمل المشاركة القياسية: Customer Community Plus وPartner Community (مع أدوار للمستخدمين الخارجيين)، لا Customer Community، الذي يستخدم مجموعات المشاركة (sharing sets).
- المستلمون لا يحتاجون إلى ترخيص. صفحة التتبع تعرض توصيلة واحدة عبر رابط برمز (token) تنتهي صلاحيته (S3)، لا عبر تسجيل دخول.
- انتبه للانحراف. مئات الآلاف من أوامر العمل في السنة تشير إلى ثلاثة أو أربعة حسابات شركاء، وهذا انحراف بيانات الحساب (account data skew). أحد الخيارات حساب فرعي لكل مركز توزيع تحت كل شريك، فيوزّع السجلات الفرعية على تسعة اتجاهات أو أكثر؛ وأرشفة التوصيلات المكتملة بعد نافذة المطالبات تُبقي عدد السجلات الفرعية النشطة لكل أب منخفضًا. والجزء 2 يتناول ذلك.
ما لن أفعله
Section titled “ما لن أفعله ”لن أُنشئ حسابًا شخصيًا لكل مستلم لمجرد أن المستلم فرد. ولن أعلّق مليون جهة اتصال على ثلاثة حسابات. ولن أبني كائن توصيلة مخصصًا بجانب أمر العمل في Field Service. ولن أوحّد المستلمين عبر الشركاء. ولن أضع ملايين الصور أو قراءات GPS في التخزين الأساسي. ولن أسمّي المستلم الموحّد سجلًا ذهبيًا ما لم نكن قد اتخذنا فعلًا قرارًا بإدارته كبيانات رئيسية.
ما لا يزال مفتوحًا
Section titled “ما لا يزال مفتوحًا ”الجزء 1 وضع الهيكل العظمي؛ والجزء 2 يختبره. مسطرة LDV في السنة الثالثة (أوامر العمل ومواعيد الخدمة والبنود كلها في نطاق الأحجام الكبيرة خلال سنتين إلى ثلاث)، وتصميم الاستعلامات لطرق العرض المحصورة في كل شريك، والتكاملات الواردة الثلاثة وتدفقات الحالة الثلاثة، وترحيل RouteDesk، والمعاملات في يوم التوصيل، والتصميم الأمني خلف البوابة. وستتغير Steve Trucking أيضًا. احتفظ بهذا التصميم؛ فستعود إليه.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”- أيّ الكائنات القياسية تحمل النواة (هنا، كائنات Field Service)، وأيّ الكائنات المخصصة مبرَّرة حقًا (هنا، كائن واحد).
- المفتاح الذي يطابق سطر طلب كل شريك مع توصيلة، ولماذا ينتمي إلى الشريك.
- ما هو المستلم، بناءً على العلاقة التي تربط Steve Trucking به فعلًا.
- هل نوحّد الهويات، وأين يكون الخلط أكثر كلفة من أن نخاطر به.
- ما يبقى في الـ org، وما يعيش خارج النواة، وأيّ التراخيص يعتمد عليها التصميم.
للاستزادة
Section titled “للاستزادة ”- ملخص Steve Trucking وتحدياتها (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 (بالإنجليزية).