الأنظمة المحيطة بـ 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)

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

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

الوحدة 3 من 6 في فصل فهم بيانات المؤسسة، الفصل 4 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: أنواع بيانات المؤسسة · التالي: ارسم خريطة الأنظمة

السؤال الذي تجيب عنه هذه الوحدة: ما الذي يحيط بـ Salesforce، وما الدور الذي يؤديه كل نظام؟

صنّفت الوحدة السابقة البيانات. والآن أريد أن أضعها في مكان ما، وهنا يقع معماريو Salesforce في المتاعب. نحن نعرف Salesforce، لذا بيانات العملاء تعني الحساب (Account)، وبيانات الطلبات تعني Order، والمستندات تعني Files، والتحليلات تعني Reports. لكن المؤسسة لم تشترِ Salesforce لتستبدل به كل ما تملكه. قد يكون هناك ERP يدير المالية وتنفيذ الطلبات، ومستودع بيانات فيه سنوات من التاريخ، ومنصة تكامل، ومزوّد هوية، وأنظمة شركاء، ومنصة أحداث، ومنصة MDM، وData 360 يربط بين عدد منها. المهمة ليست حفظ التقنيات. إنها فهم المهمة التي يؤديها كل نظام.

لا تبدأ باسم المنتج

«لدينا SAP» لا يخبرني بما يكفي. ولا Snowflake، ولا MuleSoft، ولا Tableau، ولا Data 360. أريد أن أعرف ما يفعله ذلك النظام في هذه المعمارية: ما البيانات التي يملكها، وما الذي يقرؤه، وما الذي يغيّره، ومن يستخدمه، وما الذي يعتمد عليه، وماذا يحدث عندما يتوقف. يمكن لشركتين أن تملكا المنتجات نفسها تمامًا وتكون لديهما معماريتان مختلفتان كليًا.

لذا أسمّي الأنظمة حسب الدور. أربعة أدوار تغطي معظم الحالات:

• نظام السجل (system of record): حيث تُحفظ النسخة المرجعية المعتمدة من شيء ما.
• نظام التفاعل (system of engagement): حيث يؤدي الناس العمل.
• النظام المرجعي (system of reference): حيث يذهب نظام ما للحصول على معلومات يحتاج إليها لكنه لا يملكها.
• نظام الرؤى (system of insight): حيث تجتمع البيانات للقياس والتحليل والتنبؤ.

يمكن لمنصة واحدة أن تؤدي عدة أدوار، والأدوار تختلف حسب البيانات. قد يكون Salesforce نظام السجل للحالات، ونظام التفاعل لموظفي الخدمة، ومستهلكًا لبيانات المنتجات التي يملكها ERP. لذا عندما يقول أحدهم «Salesforce هو نظام السجل لدينا»، أكمل الجملة: نظام السجل لماذا؟

ERP: للمكتب الخلفي جاذبية

ERP هو النظام الذي ستجده بجوار Salesforce أكثر من غيره، يدير المالية والمخزون والمشتريات وتنفيذ الطلبات والفوترة. نمط الوحدة 1 (العملاء والمنتجات إلى الداخل، والطلبات إلى الخارج) يعني أن ERP يملك المنتجات، لكن مندوبي المبيعات لا يزالون يحتاجون إليها في Salesforce. حسنًا: أدخِلها. لكن نسخ البيانات لا ينقل الملكية. النسخة ليست مرجعية.

موقفي: البيانات التي يملكها ERP تُقرأ محليًا وتُكتب تحت السيطرة. يحصل مستخدمو Salesforce على البيانات حيث يعملون، لكن لا يحق لـ Salesforce تغيير ما يملكه ERP. وأجعل ذلك مرئيًا في المخطط: حقول ERP تحمل البادئة erp_، مثل erp_Product_Number__c، حتى يعرف كل من يقرأ الكائن من يملك كل حقل وأن عليه الحذر عند تغييره. البادئة لا تفرض شيئًا؛ فالأذونات، والتحقق، ونمط التكامل هي التي تفعل ذلك. إنها توصل النية، وهي خريطة المرجعية (authority map) وقد صارت مرئية.

مستودع البيانات، والبحيرة، والـ Lakehouse

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

ستلتقي بثلاثة أنواع من المخازن التحليلية. مستودع البيانات (data warehouse) يحتفظ ببيانات مهيكلة مُعدّة للتحليل. وبحيرة البيانات (data lake) تحتفظ ببيانات أكثر بكثير وبأشكال أكثر، وغالبًا خام. والـ Lakehouse يجمع بين الاثنين: تخزين على طريقة البحيرة مع تحليل على طريقة المستودع. اعرفها، لأنها تظهر على خرائط الأنظمة. لكن تجربتي أن الـ Lakehouses وData Mesh لا تزال محدودة الانتشار في مشاريع Salesforce. خريطة الأنظمة المعتادة هي CRM، وERP، ومستودع بيانات، وطبقة تكامل، مع منصات أخرى حيث تحتاج إليها الأعمال فعلًا. تعلّم المعمارية؛ ولا تطارد المصطلحات.

التحليلات تعيش حيث تعيش البيانات

هذا من أرسخ مواقفي: مكان التحليلات يتبع مكان البيانات. إذا كان التقرير يحتاج فقط إلى الحسابات والفرص ومندوبي المبيعات، فكل شيء على النواة: التقارير ولوحات المعلومات القياسية. ثم تطلب الأعمال إضافة فواتير ERP. ثم تكلفة المنتج. ثم خمس سنوات من الطلبات من مستودع البيانات. ثم نشاط الموقع الإلكتروني. عند نقطة ما، يتوقف سحب كل ذلك إلى CRM التشغيلي لمجرد إعداد تقارير عنه عن أن يكون منطقيًا. بمجرد أن تدخل مخازن بيانات أخرى، تصبح منصة التحليلات ضرورية: Tableau (بما في ذلك Tableau Next، المبني على Data 360)، أو CRM Analytics حيث يكون مستخدمًا بالفعل. وهي ضرورية حتمًا عندما تُدمج بيانات Salesforce مع مستودع بيانات. المتطلب لم يصبح أكثر تعقيدًا فحسب؛ بل إن خريطة الأنظمة غيّرت المكان الذي ينبغي أن يُجاب فيه عن السؤال. لذا لا أبدأ أبدًا بسؤال «أي أداة تحليلات؟» بل أبدأ بسؤال أين البيانات؟

أسأل المرشحين لشهادة CTA الشيء نفسه: «أي من مخططاتي يحل هذا بشكل جميل؟ خريطة الأنظمة.» إذا كان كل شيء لديك على النواة، فاستخدم التقارير. وإذا كانت لديك بيانات في مستودعات أخرى، فأريد أن أرى منصة تحليلات. خريطة الأنظمة تجيب عن سؤال التقارير قبل أن يفتح أحد أداة بناء التقارير. (أسماء المنتجات تتغير؛ وفصل Data 360 يغطي موقع تحليلات Salesforce اليوم.)

MDM: من هو هذا العميل حقًا؟

والآن لنفترض أن معلومات العملاء تعيش في Salesforce، وERP، والتجارة الإلكترونية، ومنصة الولاء، ونظام شريك، وكل واحد منها يظن أنه يعرف من هو العميل. هنا يأتي دور إدارة البيانات الرئيسية (MDM): تأسيس الهوية المرجعية المعتمدة للبيانات الأساسية عبر الأنظمة وحوكمتها. لكن MDM ليست «قاعدة بيانات رئيسية للعملاء». الأسئلة الصعبة هي: أي نظام يجوز له إنشاء العميل، وأي السمات يملكها كل نظام، وكيف تُكتشف التكرارات، وأي معرّف يبقى، وماذا يحدث عندما تختلف الأنظمة. الفصل 6 يدور كله حول ذلك. أما هنا، فتعرّف على الدور: إذا كانت هناك منصة MDM، فقد تكون مرجعية حاسمة بين Salesforce وبقية المؤسسة.

طبقة التكامل والأحداث

اربط كل نظام مباشرةً بكل نظام آخر، وستتحول خريطة الأنظمة إلى طبق سباغيتي بسرعة. لهذا تملك المؤسسات طبقة تكامل: ESB (ناقل خدمات المؤسسة) أو iPaaS (منصة التكامل كخدمة). وMuleSoft هي التي ستلتقي بها أكثر من غيرها في خرائط أنظمة Salesforce. إنها تتوسط، فلا يحتاج كل تطبيق إلى فهم كل تطبيق آخر.

لكن صندوق MuleSoft في الوسط لا يجعل التكامل جيدًا. لا أزال أريد أن أعرف ما الذي يمر عبره وما الذي لا يمر، ومن يحوّل البيانات، ومن يملك العقد، وماذا يحدث عندما تكون الوجهة متوقفة، وهل هو متزامن أم غير متزامن، وكيف نعرف أن رسالة نجحت. تتعمق دورة Integration Architect في ذلك؛ أما هنا، فتعرّف عليها كدور قائم بذاته.

وليس كل تكامل هو النظام A يستدعي النظام B. أحيانًا يحدث شيء (يُنشأ طلب، أو تتغير حالة توصيلة، أو تعبر شاحنة إلى منطقة)، فيُنشر حدث، ويستجيب كل من يهتم به. والأحداث المتحركة لها بنيتها التحتية أيضًا: قدرات الأحداث الخاصة بـ Salesforce، وناقل أحداث المؤسسة، وأنظمة مراسلة أخرى. ارسم الآليات التي تحمل البيانات، لا قواعد البيانات فقط.

النظام الذي ينساه المطورون: الهوية

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

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

وهناك تعقيد عملي أيضًا: إعداد الهوية قابل للنشر، لكن ليس بالكامل. إعداد تسجيل الدخول الموحّد عبر SAML ومزوّدو المصادقة أنواع في Metadata API، لذا فهي تنتقل عبر مسار النشر (SamlSsoConfig (opens in a new tab)). لكن الأسرار الخاصة بمستهلكي مزوّدي المصادقة لم تعد تُعاد في استجابات Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab))، والشهادات عادةً تختلف من بيئة إلى أخرى. خطّط للأجزاء التي تنتقل والأجزاء التي لا تنتقل.

Click to enlarge

اقرأ خريطة الأنظمة كأدوار، لا كشعارات: ما يملكه كل نظام، أو يقرؤه، أو يقرّره.

أين يقع Data 360؟

يطرح Data 360 سؤالًا لطيفًا في الرسم. أضعه على اليمين، تحت ESB أو MuleSoft. والسبب اتصالاته: المستخدمون لا يتصلون به مباشرةً أبدًا، بينما يتصل هو مباشرةً بكثير من الأنظمة الخلفية. لذا مكانه مع البنية التحتية للبيانات، حيث تبقى تلك الخطوط قصيرة، لا هناك مع المستخدمين. ارسمه كشاشة أخرى يسجّل الناس الدخول إليها، وستكون تروي القصة الخطأ.

مسؤولو الأنظمة وفرق البيانات يفتحون شاشات Data 360 فعلًا، لكن تلك الشاشات في مؤسسة Salesforce (org)، على النواة. أما المستأجر الذي يؤدي العمل، ببياناته ومعالجته، فيعمل خارج النواة. لهذا أسميه قريبًا من النواة (near-core): يُدار على النواة، ويُستضاف خارجها (تشرح الوحدة 1 المصطلحات). والرسم يتبع المستأجر: يقع مع البنية التحتية، مع خط واحد يعود إلى الـ org الذي يديره.

ومما يفعله، بكلمات Salesforce، zero copy: تقنية لاتحاد البيانات تتيح للمؤسسة الوصول إلى البيانات والاستعلام عنها دون نسخها (Zero Copy (opens in a new tab)). القدرات والموصّلات تتغير بسرعة، لذا يغطيها فصل Data 360 كما ينبغي بدلًا من تحويل هذه الوحدة إلى جولة في المنتج.

اقرأ خريطة الأنظمة كمسؤوليات

عندما تنظر إلى خريطة أنظمة، لا تقرأ الشعارات؛ اقرأ المسؤوليات. ERP: ما الذي يملكه؟ مستودع البيانات: ما الأسئلة التي يجيب عنها؟ منصة التكامل: ما الذي تنقله؟ مزوّد الهوية: من يصادق عليه؟ MDM: أي هوية تحكمها؟ Data 360: ما الذي يربطه، ولأي غرض؟ Salesforce: ما الذي هو مسؤول عنه فعلًا؟ بمجرد أن تستطيع الإجابة عن هذه الأسئلة، تصبح للصناديق معنى، وتصبح الأسهم بينها أكثر إثارة بكثير. بعد ذلك، نرسمها عن قصد.

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

• ما الدور الذي يؤديه كل نظام، أبعد من اسم منتجه.
• أي نظام هو المرجع المعتمد لكل مجموعة بيانات مهمة، وأين لا يحتفظ Salesforce إلا بنسخة محلية.
• هل البيانات التي يملكها ERP متاحة في Salesforce مع ضبط الكتابة عليها، وكيف تظهر تلك الملكية في المخطط.
• أين تنتمي التحليلات، بناءً على مكان البيانات.
• أين تقع الهوية، والتكامل، والأحداث، ومرجعية البيانات الرئيسية على خريطة الأنظمة.

خريطة أنظمة فيها عشرة مستطيلات ليست معمارية؛ إنها جرد. تبدأ المعمارية عندما تستطيع أن تشير إلى كل مستطيل وتقول لماذا هو هناك، وما الذي يملكه، ومن يستخدمه، وما الذي يحتاج إليه Salesforce منه، وما الذي ينكسر إذا أسأت فهم دوره.

للاستزادة

• Salesforce Developers، Metadata API Developer Guide، SamlSsoConfig (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).
• Salesforce Help، Winter ‘23 Release Notes، Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).
• Salesforce، Zero Copy (opens in a new tab) (صفحة المنتج) (بالإنجليزية، تم التحقق في 2026-10-14).
• Zhamak Dehghani، How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab)، martinfowler.com، 2019 (بالإنجليزية).