صمّم النموذج المادي في Salesforce

🌐 متاح أيضًا بـ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)

صورة مولّدة بالذكاء الاصطناعي

ترجمة بالذكاء الاصطناعي. لم يراجعها المجتمع بعد. اقرأ بالإنجليزية

الوحدة 10 من 10 في فصل معمارية بيانات Salesforce، الفصل 3 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: الحفاظ على اتساق البيانات · التالي: دليل دراسة الفصل، ثم الفصل التالي، فهم بيانات المؤسسة

السؤال الذي تجيب عنه هذه الوحدة: كيف نحوّل نموذجنا المنطقي إلى معمارية في Salesforce؟

كان هذا الفصل كله حجة واحدة طويلة على أن للمنصة شكلًا: الكائنات القياسية والمخصصة، والأماكن التي يمكن أن تعيش فيها البيانات، وأنواع الحقول، والعلاقات، والملكية، والتراخيص، وقواعد الاتساق، والتخزين والحجم. كل واحد منها يمكن أن يغيّر طريقة بناء النموذج المنطقي من الفصل 2. والآن لنجمع كل ذلك على شريحة واحدة من Steve Trucking.

شريحة واحدة، لا الشركة كلها. من الأخطاء التي أراها عند المعماريين محاولة حل المؤسسة بأكملها في رسم واحد. أريد شيئًا نستطيع أن نفكر فيه: شريك التجزئة (Retail Partner) يرسل بيان شحنة (manifest)، وتوصل Steve Trucking ما فيه، ونحتفظ بما نحتاج إليه عن كل توصيلة (Delivery). ثم نتخذ القرارات المادية واحدًا تلو الآخر. أما التصميم الكامل فهو نقطة التحقق في الجزء 1.

ابدأ بما نعرفه بالفعل

أنجز الفصل 2 العمل المفاهيمي: شريك التجزئة، والمستلم (Recipient)، وبيان الشحنة، والتوصيلة، وبند التوصيلة (Delivery Item)، ونوع المحطة، والطاقم (Crew)، والشاحنة (Truck)، ومركز التوزيع (Distribution Center)، والصور. سمّينا العلاقات وسألنا عمّا تعنيه. لن أكرر ذلك. السؤال الآن هو كيف تعيش هذه المفاهيم على Salesforce. حقيقة واحدة من الموجز تهمّنا فورًا: Steve Trucking تشغّل بالفعل Field Service للمواعيد والطواقم وتطبيق الهاتف المحمول.

شريك التجزئة: لا تخترع حسابًا

شريك التجزئة شركة تعمل Steve Trucking لصالحها. ولدى Salesforce بالفعل كائن مصمَّم للشركات: الحساب (Account). توافق نظيف. فلا Retail_Partner__c لمجرد أن الأعمال تقول «شريك». إنه حساب، بنوع سجل Retail Partner يميّزه عن المؤسسات الأخرى، ومعه تأتي العقود، والحالات، وجهات الاتصال (Contacts) لمديري مراكز التوزيع، ووصول هذه الجهات إلى البوابة. قرار سهل. وليست كل القرارات كذلك.

رقم طلب الشريك ليس معرّفنا

كل شريك تجزئة يرسل مراجعه الخاصة. طلب أحد الشركاء يبدو مثل 8843119، وطلب شريك آخر مثل A-984732. هذه الأرقام مهمة، لكن لمن هي؟ للشريك. لدى Salesforce معرّف السجل الخاص بها، ولدى الشريك المرجع الذي يستخدمه عندما يتحدث إلينا. يمكن أن يوجد الاثنان معًا؛ هذا ما سمّيناه في الفصل 2 «شيء واحد، ومعرّفات عدة».

لذا يصبح مرجع الشريك External ID يستخدمه التكامل لمطابقة التحديثات. ولأن شريكين قد يستخدمان الرقم نفسه، فالمعرّف الفريد هو الشريك مع المرجع، لا المرجع وحده. لا تجعل رقم أحد الشركاء المعرّفَ الشامل للتوصيلة لمجرد أنه وصل أولًا، ولا تجعل التكامل يبحث في حقل نصي كلما احتاج إلى العثور على سجل.

التوصيلة: انظر إلى السفينة الأم

هنا يغري إنشاء Delivery__c. قالت الأعمال «توصيلة»، إذن نحتاج إلى كائن Delivery. وهذا بالضبط ما لا أريدك أن تفعله أولًا. انظر إلى السفينة الأم، كما فعلنا في الوحدة 2. ما الذي تملكه Salesforce بالفعل لعمل يُنفَّذ في موقع ما، له دورة حياة وبنود وجدولة وطاقم في الميدان؟ أمر العمل (Work Order) في Field Service: تصفه Salesforce بأنه عمل خدمة ميدانية يُنفَّذ لعميل (WorkOrder (opens in a new tab)). والزيارة المجدولة ونافذتها الزمنية هي موعد الخدمة (Service Appointment)، وهذا ما يجدوله المرسِلون وما يعرضه تطبيق الطاقم.

لذا التوصيلة ← أمر العمل. ليس لأن الكلمات متطابقة؛ فهي ليست كذلك. بل لأن السلوك يطابق قدرة المنصة التي ندفع ثمنها بالفعل وننوي استخدامها. الكائن القياسي لا يلزمه أن يشارك الأعمال مفرداتها. يلزمه أن يمثّل المفهوم تمثيلًا صحيحًا.

Click to enlarge

الخطوة 1 من 4: السفينة الأم. كل بطاقة هي مفهوم الأعمال، وتحته كائن Salesforce الخاص به.

لكن الكائنات القياسية تأتي بأمتعتها

والنصف الآخر: أمر العمل ليس مجانيًا. فهو يجلب تراخيص Field Service، وعلاقاته الخاصة، وسلوك الأمان، والحقول الإلزامية، والأتمتة ودورة الحياة، وأجزاء أخرى من المنصة تتوقع أن يتصرف بطريقة معينة. نحن نختاره لأن التوافق نظيف ولأننا نستخدم ما بُني حوله. لو لم تكن Steve Trucking تريد شيئًا من Field Service، وكان النموذج يصارع العملية عند كل منعطف، لأعدت النظر. المعمارية هي التوافق، لا التسمية.

بنود التوصيلة: اتبع النموذج

بمجرد أن تصبح التوصيلة أمر عمل، انظر إلى بقية ذلك النموذج قبل أن تخترع أي شيء. بند أمر العمل (Work Order Line Item) مهمة فرعية في أمر العمل (WorkOrderLineItem (opens in a new tab)): الثلاجة، والتركيب، ونقل القديم. لذا بند التوصيلة ← بند أمر العمل. لاحظ أن القرار الأول شكّل الثاني. نحن لا نختار كائنًا لكل كيان على حدة. تبنَّ نموذجًا، وافهم بقيته قبل أن تبني هياكل مخصصة حوله.

ما نوع هذه المحطة؟

في Steve Trucking تكون المحطة توصيلًا فقط، أو توصيلًا مع تركيب، أو توصيلًا مع نقل القديم، ولكل نوع مدته ومهارات طاقمه وقائمة تحقق التركيب الخاصة به. في الفصل 2 قررنا أن هذا كيان، لا تسمية. ولدى Field Service واحد بالفعل: نوع العمل (Work Type)، وهو قالب لنوع من العمل يمكن تطبيقه على أوامر العمل وبنودها (WorkType (opens in a new tab)). لذا نوع المحطة ← نوع العمل. ومرة أخرى، ليس لأن شيئًا اسمه Work Type موجود، بل لأن المفهوم والسلوك يتطابقان.

Click to enlarge

الخطوة 2 من 4: اتبع النموذج. البنود ونوع العمل تأتي مع أمر العمل.

بيان الشحنة: الآن أريد كائنًا مخصصًا

هل هناك كائن قياسي لـ«قائمة الشريك ليوم الثلاثاء في مركز توزيع Phoenix»؟ ليس حقًا، ولن أحشره في كائن لا علاقة له به لمجرد أن أقول إننا بقينا على القياسي. بيان الشحنة ← Manifest__c. إنه وحدة الاستلام: من أين جاء (ملف، أو دفعة API)، ومتى، وحالته وإجمالياته، وعندما يعيد الشريك إرساله في اليوم نفسه، ما الذي تجري مقارنته. كل سطر في بيان الشحنة يصبح أمر عمل مرتبطًا به.

المخصص ليس فشلًا. إنه ما تعطينا إياه المنصة عندما لا يكون للمفهوم موطن قياسي نظيف. الخطأ ليس إنشاء كائن مخصص؛ بل إنشاؤه دون التحقق مما إذا كانت المنصة تملك المفهوم بالفعل.

Click to enlarge

الخطوة 3 من 4: الكائن المخصص الوحيد، حيث لا يناسب أي كائن قياسي.

الصور: كون Salesforce قادرة على تخزينها لا يعني أنها يجب أن تفعل

«نحتاج إلى صور التوصيل في Salesforce.» ماذا تعني «في Salesforce»؟ المستخدمون يحتاجون إلى رؤيتها من Salesforce، نعم. هل يعني ذلك أن ملفات الصور يجب أن تعيش في تخزين النواة؟ ليس بالضرورة. عُدّ الأصفار: نحو أربع صور لكل توصيلة، وأكثر مع التركيب، بمعدل مليون توصيلة في السنة، أي أربعة إلى خمسة ملايين صورة في السنة، والتوصيلات تنمو 30% سنويًا.

لذا موقفي الأولي: لا تحوّل مؤسسة Salesforce (org) الأساسية إلى مستودع صور عملاق لأن المستخدمين يحتاجون إلى الوصول إلى الصور. الملفات مكانها تخزين مبني لهذا الحجم، خارج النواة، وتحتفظ Salesforce بما تحتاج إليه للعثور عليها وعرضها: مرجع، أو عدد، أو سجل فهرسة صغير لكل صورة، وعلامة تفيد بأن صور التركيب المطلوبة مكتملة. الوصول إلى البيانات والمكان الذي تعيش فيه البيانات فعليًا سؤالان مختلفان. هذه الوحدة 4 تعود من جديد.

الحقول: اجعل المعنى مرئيًا

يحتاج أمر العمل إلى حقول: مرجع الشريك، ونافذة التوصيل، ووقت التوصيل الفعلي، والحالة، وملاحظات مثل «رمز البوابة» أو «كلب في الفناء». لن أحوّل هذا إلى كتالوج حقول؛ فقد فعلت الوحدة 6 ذلك. اطرح الأسئلة على كل حقل: ماذا يعني، ومن يملكه، وهل يتغير، وهل هو معرّف، أو مفردات مضبوطة، ومخزَّن أم مشتق، وحساس أم لا. مرجع الشريك هو External ID، لذا فتفرّده جزء من عقد التكامل، لا مجرد خانة اختيار. وقت التوصيل الفعلي لحظة، لذا فهو Date/Time. الحالة تقود السلوك، لذا فهي قائمة مضبوطة، ولا تكون نصًا حرًا أبدًا. وملاحظات التوصيل عن منزل شخص بيانات شخصية، لذا تُصنَّف. كل حقل يعود إلى المعنى.

العلاقات: لا تكتفِ بوصل الصناديق

الحساب بأمر العمل، وأمر العمل ببنوده، وبيان الشحنة بأمر العمل، ونوع العمل يصف المحطة. ثم أسئلة الوحدة 7 لكل خط: هل يمكن للابن أن يوجد وحده، ومن يملكه، وهل يُورَث الوصول، وهل يمكن أن ينتقل، وماذا يحدث عند الحذف، وكم ابنًا يمكن أن يتراكم؟ كل أوامر العمل تحت حفنة من حسابات شركاء التجزئة تعني مئات الآلاف من الأبناء لكل أب: سؤال انحراف سنجيب عنه في الجزء 2. وبالنسبة إلى علاقات Field Service القياسية، تحقّق من الطريقة التي بنتها بها Salesforce بالفعل بدلًا من افتراض أنها تطابق ما كنا سنصممه. عندما تتبنى نموذجًا قياسيًا، فأنت تتبنى القرارات التي اتخذتها Salesforce داخله. افهمها قبل أن تبني فوقها.

الملكية والمستلم: لا تدع الإعداد الافتراضي يقرر

قراران سيتخذهما الإعداد الافتراضي عنا بكل سرور.

من يملك التوصيلة؟ أجبنا عن هذا في الوحدة 8، وهو ينتقل مباشرة إلى أمر العمل: الملكية لا تقود وصول أي أحد هنا، لذا مستخدم التكامل يملك أوامر العمل التي يُنشئها. يرى المرسِلون أوامر مركز توزيعهم، وترى الطواقم أوامر مساراتها، ويرى كل شريك تجزئة أوامره عبر البوابة، وكل ذلك عبر المشاركة، لا الملكية. مستخدم التكامل ليس له دور، ويبقى خارج المجموعات العامة التي تستخدمها قواعد المشاركة لدينا، لأنه بمعدل 3,300 في اليوم يتجاوز 10,000 سجل في ثلاثة أيام. ونكتب ما الذي يحدث إذا استُبدل هذا المستخدم يومًا.

ما المستلم؟ جهة اتصال؟ حساب شخصي؟ شيء يُحفظ على التوصيلة فقط؟ يعتمد ذلك على ما إذا كانت لدى Steve Trucking علاقة بهؤلاء الأشخاص أصلًا (فهم عملاء شركاء التجزئة)، وما إذا كان يجوز لشريك أن يرى عملاء شريك آخر يومًا، وكم من الوقت يجوز الاحتفاظ ببياناتهم الشخصية، وعلى الحجم: نحو مليون مستلم جديد في السنة. ليس لدينا كل ذلك بعد، ولا بأس. أحيانًا تكون الإجابة الصحيحة لا نعرف ما يكفي بعد. اكتب السؤال واذهب لجمع المعلومات؛ ولا تدفن عدم اليقين في كائن مخصص. نجيب عنه في نقطة التحقق في الجزء 1، بعد أن تعطينا الفصول 4 إلى 6 صورة المؤسسة والبيانات الرئيسية.

الاتساق: احمِ النموذج في الطبقة الصحيحة

سُلّم الوحدة 9 ينطبق هنا: مرجع الشريك External ID فريد، فيُجري بيانُ الشحنة المعاد إرساله upsert بدلًا من التكرار؛ والحالة قائمة مقيّدة؛ ووقت التوصيل الفعلي إلزامي فقط عندما تقول الحالة Delivered؛ ومحطة التركيب لا يمكن إغلاقها دون قائمة التحقق والصور. لا تدفق عملاق واحد. كل قاعدة على درجتها الخاصة.

أين تعيش كل قطعة

مرور أخير على الشريحة، بسؤال الوحدة 4: أين تعيش كل قطعة من البيانات؟ في عرض الشرائح الذي أستخدمه في الصف، هي شريحة واحدة، المنطقي مقابل المادي: الكيانات المنطقية من الفصل 2، وأين يستقر كل منها ماديًا: على النواة، كـ sObject (__c إن كان مخصصًا) أو big object (__b)، أو خارج النواة، ككائن خارجي (__x) أو بيانات لا تدخل Salesforce أبدًا.

• على النواة، يُعمل عليها كل يوم: الحساب، وأوامر العمل وبنودها، ومواعيد الخدمة، وأنواع العمل، وManifest__c.
• على النواة، مؤرشفة: التوصيلات الأقدم من ثلاث سنوات تنتقل إلى Delivery History، وهو big object، ما زالت هناك لأجل المطالبات، في السقيفة خلف المبنى.
• مُشار إليها: تفاصيل الطلب الخاصة بشريك التجزئة تبقى في نظام الشريك؛ نحتفظ بمرجع الشريك كـ External ID، ونصل إلى الباقي عبر كائن خارجي أو عبر التكامل عندما يحتاج إليه أحد.
• خارج النواة: الصور، في تخزين مبني لملايين الصور، مع رابط من أمر العمل.

هذا هو النموذج المادي: ليس أي كائن فحسب، بل أي موطن.

والآن انظر إلى الشريحة كاملة

• شريك التجزئة ← الحساب، بنوع سجل Retail Partner؛ ومديرو مراكز التوزيع كجهات اتصال.
• التوصيلة ← أمر العمل في Field Service، مجدول عبر موعد خدمة.
• بند التوصيلة ← بند أمر العمل.
• نوع المحطة ← نوع العمل.
• بيان الشحنة ← الكائن المخصص Manifest__c.
• مرجع الشريك ← External ID على أمر العمل، فريد لكل شريك.
• الصور ← مخزّنة خارج النواة؛ وتحتفظ Salesforce بالمرجع وعلامة الاكتمال.
• سجل التوصيلات التاريخي ← يُؤرشف إلى big object بعد ثلاث سنوات.
• الملكية ← مستخدم التكامل، مع الوصول عبر المشاركة (الوحدة 8).
• المستلم ← مفتوح، لنقطة التحقق في الجزء 1.

Click to enlarge

الخطوة 4 من 4: الشريحة كاملة، على النواة ومؤرشفة وخارج النواة. كل خط علاقة بحث: بنت Salesforce خدمة Field Service على علاقات البحث، ونحن نتبنى قراراتها معها.

الرسم ليس المعمارية

أستطيع أن أسلّمك ذلك الرسم، وهو لا يكفي. المعمارية هي المنطق الذي يقف خلفه. لماذا الحساب؟ شركة بتوافق نظيف. لماذا أمر العمل وليس Delivery__c؟ التوصيلة تتصرف كعمل ميداني، وField Service موجودة بالفعل. لماذا بيان شحنة مخصص؟ لا موطن قياسي نظيف. لماذا لا تكون الصور مجرد Files؟ الحجم واقتصاديات التخزين. لماذا External ID؟ نظام آخر يحتاج إلى معرّف ثابت عبر الحدود. لماذا يملك مستخدم التكامل أوامر العمل؟ الملكية لا تقود الوصول هنا، وهذا يبقي سجل التدقيق صادقًا. لماذا لا يزال المستلم مفتوحًا؟ لم نجب عن أسئلة كافية بعد. الخطوط هي المُخرَج؛ والقرارات هي التي أنتجتها.

لذا هذه هي العادة التي أريدك أن تخرج بها من الفصل 3. أشر إلى أي شيء في نموذج مادي واسأل لماذا؟ لماذا هذا الكائن، وهذا النوع، وهذه العلاقة، وهذا المالك، وهذا المكان، وهذه القاعدة؟ يجب أن تستطيع تتبّع الإجابة إلى الوراء: من الإعداد، إلى النموذج المادي، إلى النموذج المنطقي، إلى متطلب الأعمال. إن لم تستطع، فقد صمّم أحدهم من Setup.

ولا بد أنك لاحظت الأرقام التي لم نعمل عليها بالكامل: التوصيلات لكل شريك، والبنود، والصور، والاحتفاظ، والأرشفة. جيد. اسأل عن عدد الأصفار قبل أن تثبّت تصميمًا: النموذج الذي يعمل بشكل رائع عند خمسين ألف سجل قد يتصرف بشكل مختلف تمامًا عند خمسمئة مليون. هذا هو الجزء 2.

ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. أعطِ ذكاءً اصطناعيًا موجز Steve Trucking وسينتج مخططًا في ثوانٍ: Account، وWork Order، وكائنات مخصصة، وحقولًا، وحتى البيانات الوصفية للنشر. هذا مسرّع رائع، لكنه ليس المراجعة. تنتقل مهمة المعماري إلى فحص التعيينات وعواقبها: التوافق، والتراخيص، والملكية، ودورة الحياة، والحجم، والمعرّفات، والأمان، وما يبقى خارج المنصة. الذكاء الاصطناعي معزّز الصاروخ؛ لكنه لا يخبرك ما إذا كنت متجهًا في الاتجاه الصحيح.

ما الذي يقرره المعماري هنا

• كيف يُعيَّن كل مفهوم من مفاهيم الأعمال إلى Salesforce: كائن قياسي، أو كائن مخصص، أو شيء خارج النواة.
• أي المعرّفات والحقول والعلاقات تنفّذ معنى الأعمال دون أن تغيّره خلسةً.
• ما سلوك المنصة والتراخيص التي تأتي مع نموذج قياسي تتبنّاه.
• أي قرارات الملكية ودورة الحياة والاتساق والتخزين والحجم يجب اتخاذها قبل أن يكتمل التصميم.
• أي الأسئلة تبقى مفتوحة صراحةً، بدلًا من أن تختبئ خلف خيار تنفيذ اعتباطي.

في بداية هذا الفصل سألنا كيف ينبغي أن يعيش النموذج على Salesforce. هذه هي معمارية بيانات Salesforce: ليست إنشاء كائنات، ولا حفظ Setup عن ظهر قلب، ولا رسم صناديق أجمل، بل مواءمة نموذج الأعمال عن قصد مع شكل المنصة. كل هيكل التزام. اتخذ الالتزامات التي تستطيع شرحها.

للاستزادة

• Salesforce Developers، مرجع الكائنات (Object Reference): WorkOrder (opens in a new tab) وWorkOrderLineItem (opens in a new tab) وWorkType (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-02).
• موجز Steve Trucking.