توقّف عن نسخ بياناتك: لماذا تتفوّق الجداول الافتراضية في Dynamics 365 على المزامنة التقليدية

By Mirko Peters · 2026-08-27

مرحباً بعودتك إلى المدونة! في مجال عملنا نتحدث كثيراً عن توحيد الأنظمة، وكسر الصوامع المعزولة، وضمان حصول المستخدمين على المعلومات التي يحتاجونها في متناول أيديهم. لكن هناك فخّ صامت تقع فيه كثير من المؤسسات عند دمج أنظمتها المؤسسية: الرغبة في نسخ كل شيء. اليوم سنتعمق في الأسباب التي تجعل المزامنة التقليدية للبيانات تسبّب صداعاً كبيراً، وكيف يمكن لميزة مدمجة في Microsoft Dataverse أن تغيّر تماماً ط

Automatically translated with AI from the original post. Read the English original

Cover: Dynamics 365 Virtual Entities - Simply Explained

إذا كنت ترغب في الاستماع إلى شرح صوتي مفصّل لهذا الموضوع مع أمثلة واقعية، فتأكد من الاطلاع على حلقة البودكاست المرتبطة به: Dynamics 365 Virtual Entities - Simply Explained.

مخاطر تكرار البيانات ووظائف المزامنة القديمة

تخيّل هذا السيناريو: يقضي فريق المبيعات يومه بارتياح داخل Dynamics 365. غير أن مستويات المخزون لديكم موجودة في نظام مستودعات منفصل، والفواتير تُدار في تطبيق مالي، وكتالوجات معلومات المنتجات تُحفظ في نظام ERP مختلف تماماً. النهج الكلاسيكي الافتراضي لكثير من فرق تكنولوجيا المعلومات هو بناء خط أنابيب للتكامل. تكتب وظائف مجدولة تنسخ كل تلك المعلومات إلى Dataverse بشكل دوري. يبدو الأمر بسيطاً، أليس كذلك؟

للأسف، يؤدي هذا إلى بنية مليئة بالسجلات المكررة، وتأخيرات في المزامنة، وإخفاقات في الدفعات، والأسوأ من ذلك كله، معلومات قديمة. تخيّل أن نظام المستودعات سجّل عشر وحدات متاحة في المخزون أثناء تشغيل المزامنة الليلية. في صباح اليوم التالي، تعرض لوحة معلومات Dynamics 365 هذه الوحدات العشر المتاحة بكل فخر. لكن في وقت الغداء، يشتري عميل عابر ويستلم الوحدات العشر المتبقية كلها. يعلم نظام المستودعات فوراً أن المخزون وصل رسمياً إلى الصفر. ومع ذلك، سيستمر Dynamics 365 في عرض عشر وحدات متوفرة حتى تعمل المزامنة المجدولة في الليلة التالية. وبذلك يتخذ مندوب المبيعات غير المدرك قرارات حاسمة بشأن البيع الإضافي استناداً إلى معلومات قديمة تماماً. المشكلة ليست بالضرورة في فشل نص المزامنة البرمجي؛ الخلل الجوهري هو أن المعلومات المنسوخة تصبح قديمة حتماً بين دورات المزامنة.

علاوة على ذلك، يطرح النسخ سؤالاً معمارياً شائكاً: أي نظام يملك الحقيقة فعلاً؟ إذا وُجد منتج في نظام ERP، لكن نسخة مكررة منه موجودة في Dataverse، وقام أحدهم بتعديل الوصف أو السعر أو حالة التوفر في موضع واحد، فلا بد من أن يحدد شخص ما أو شيء ما أي نسخة هي الأصح. تخلق المزامنة التقليدية كوابيس حقيقية في اتساق البيانات. أما الجداول الافتراضية فتقدّم نهجاً مختلفاً تماماً، إذ تتيح لنظام الأعمال الأصلي أن يحتفظ بالملكية الكاملة للسجل، مع السماح لمستخدمي Dynamics 365 بالاستعلام عن تلك المعلومات بأمان كلما دعت الحاجة.

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

فهم الجداول الافتراضية في Dynamics 365

كثيراً ما تعلن المؤسسات أنها تريد "نظاماً واحداً" يجمع كل شيء. لكن إذا تحدثت مع الموظفين في عملهم اليومي، فستجد أن ما يحتاجونه فعلاً هو مكان واحد يعملون فيه. لا ينبغي لمندوب المبيعات أن يُبقي Dynamics 365 مفتوحاً، ثم ينتقل بتبديل النوافذ إلى نظام ERP ليتحقق من المخزون، ثم يفتح تطبيقاً قديماً ثالثاً ليتأكد من حالة فاتورة، ثم يعود أخيراً إلى سجل العميل. يريد الموظفون مساحة عمل موحدة. تُدخل الجداول الافتراضية المعلومات الخارجية المختارة مباشرةً إلى تجربة Dynamics 365 الأصلية، مع السماح للأنظمة المتخصصة بمواصلة إدارة عملياتها التجارية الخاصة.

إذا كنت تعمل مع منظومة تطبيقات الأعمال من Microsoft منذ فترة، فقد تصادف المصطلح القديم "Virtual Entities" في الوثائق القديمة، أو في المنتديات التقنية، أو في أحاديث مع المطورين المخضرمين. المصطلح المحدَّث والمعتمد حاليًا من Microsoft هو Virtual Tables. وبغض النظر عن التسمية، يظل المفهوم الأساسي واحدًا: إذ يمكن لـ Dynamics 365 وDataverse عرض معلومات خارجية وكأن المستخدمين يتعاملون مع جدول أصلي في Dataverse، بينما تبقى السجلات الفعلية محفوظة بأمان خارج Dataverse.

لفهم الفرق، قارن بين جدول Dataverse العادي وVirtual Table. في جدول Dataverse القياسي، تُخزَّن السجلات مباشرةً داخل قاعدة بيانات Dataverse، والحسابات وجهات الاتصال والفرص والجداول المخصصة أمثلة واضحة على ذلك. أما في Virtual Table، فيحدد Dataverse كيفية ظهور المعلومات الخارجية وكيفية استرجاعها، لكن السجلات نفسها موجودة في مكان آخر تمامًا. فكّر في فهرس المكتبة: فهو يحتوي على معلومات تصف كتابًا، إذ يخبرك بعنوانه ومؤلفه وموضعه على الرف، لكن الفهرس ليس الكتاب نفسه. وVirtual Table يعمل بالطريقة ذاتها تمامًا؛ فـ Dataverse يفهم البنية ويعرف كيف يطلب السجل، إلا أن النظام الخارجي هو الذي يحتوي على البيانات الفعلية.

كيف تتيح Virtual Tables نافذة حية على البيانات الخارجية

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

لنفترض أن مدير حسابات يناقش صفقة كبيرة محتملة مع عميل رئيسي. يرغب العميل في طلب 500 وحدة الشهر المقبل. وبينما يبقى مدير الحسابات داخل واجهة Dynamics 365 المألوفة، يفتح معلومات توفر المنتج ذات الصلة. يمكنه الاطلاع على رقم الصنف، وموقع المستودع، والكمية المتوفرة، وتاريخ إعادة التوريد المتوقع. تُبث هذه المعلومات مباشرةً من المستودع الخارجي أو نظام ERP في الوقت الفعلي، بدلًا من الاعتماد على جدول مخزون مستورد من يوم أمس. تعمل Dynamics 365 كمساحة عمل موحدة، بينما يظل نظام المستودع المرجع الوحيد والمطلق للمخزون.

تُلغي بنية التشغيل هذه مخاطر تكرار البيانات. فعندما ينفذ المستخدم استعلامًا، يتبع التطبيق تسلسلًا مبسطًا من الخطوات. يفتح مندوب المبيعات قائمة المنتجات ويطبق فلترًا للأصناف المتوفرة. يتعرف Dataverse على أن الهدف هو Virtual Table. يستقبل موفر البيانات الأساسي الطلب، ويستخدم تفاصيل الاتصال من مصدر البيانات للتواصل مع الخدمة الخارجية، ويحوّل الفلتر الذي أدخله المستخدم إلى صيغة يفهمها النظام الخارجي، ثم يسترجع السجلات المطابقة، ويحوّل النتائج إلى صفوف قياسية في Dataverse، ويعرضها فورًا في واجهة المستخدم. يحصل المستخدم على تجربة سلسة، بينما تبقى البيانات في موطنها الأصلي الموثوق ولا تغادره أبدًا.

الكتل الأساسية الثلاث: موفرو البيانات ومصادر البيانات والجداول

لتحقيق هذا السحر خلف الكواليس، تعتمد كل Virtual Table على ثلاث كتل معمارية أساسية: موفر البيانات (Data Provider)، ومصدر البيانات (Data Source)، وتعريف Virtual Table نفسه. وفهم هذه المكونات الثلاثة ضروري لكل من يسعى إلى تصميم استراتيجية تكامل متينة.

ما هو موفر البيانات؟

يعمل موفر البيانات بوصفه المترجم الرئيسي في هذه البنية. فـ Dynamics 365 وDataverse يرسلان الطلبات باستخدام مفاهيمهما الداخلية، أي الجداول والأعمدة والفلاتر ومعرّفات السجلات. أما النظام الخارجي فمن المرجح أنه يستخدم واجهة برمجية أو بروتوكولًا أو صيغة بيانات مختلفة تمامًا. ويتولى الموفر الترجمة بين الطرفين. ولا يحتاج المستخدمون إلى فهم هذا الحوار المعقد، إذ يتفاعلون ببساطة مع السجلات الناتجة من خلال واجهة تطبيق Dynamics 365 القياسية.

توفر Microsoft دعماً جاهزاً لمزوّد OData الإصدار 4. يوفّر OData طريقةً موحّدةً ومعتمدةً في الصناعة لعرض البيانات والاستعلام عنها عبر الويب. إذا كانت خدمتك الخارجية تعرض منتجات تتضمن حقولاً مثل أرقام المنتجات والأوصاف وأسعار الوحدات والكميات المتاحة عبر OData، فيمكن للمزوّد المدمج طلب تلك السجلات وإرجاعها ببنيةٍ يفهمها Dataverse بشكلٍ أصلي. وبالنسبة إلى تطبيقات السحابة الحديثة، يجعل هذا التكامل بسيطاً بدرجةٍ لافتة.

بالطبع، ليست كل تطبيقات الأعمال القديمة أو المخصصة تدعم OData. وعندما تفرض بنيتك طريقة تكامل أخرى، يمكن للمؤسسات تنفيذ Custom Data Providers. يستطيع مطوّر ماهر كتابة مزوّد مخصص يربط Dataverse بواجهة REST API خاصة، أو بقاعدة بيانات SQL، أو بخدمة ويب مؤسسية داخلية. وبصرف النظر عن التقنية الأساسية، يؤدي المزوّد المخصص المهام الجوهرية نفسها: استقبال طلب Dataverse، والتواصل مع النظام الخارجي، وترجمة الاستجابة، وإعادة السجلات بسلاسة.

ما هو Data Source؟

إذا كان Data Provider يعرف كيف يتحدث اللغة، فإن Data Source يحتوي على العنوان وبيانات الاعتماد المحددة اللازمة للوصول إلى الوجهة. ويحتفظ Data Source بجميع معلومات الاتصال بالخدمة الخارجية، بما في ذلك عنوان نقطة نهاية الخدمة، ومعاملات المصادقة، ومفاتيح API، وإعدادات تحديد معدل الطلبات المرتبطة بالاتصال. فكّر في المزوّد بوصفه خبير اللغة، وفي المصدر بوصفه دفتر العناوين.

ربط الأعمدة الخارجية ومعرّفات السجلات الفريدة

بمجرد إنشاء الاتصال، يجب عليك ربط الأعمدة الخارجية بمخطط Virtual Table الخاص بك. على سبيل المثال، قد يسمّي تطبيق المستودعات حقلاً باسم "الكمية المتاحة"، بينما يفضّل مستخدمو Dynamics 365 رؤية "المخزون الحالي". يخبر ربط الحقول Dataverse بأن هذين الاسمين المختلفين يمثلان المعلومة نفسها تماماً. وهذا يتيح للمؤسسات توفير مصطلحات سهلة الفهم داخل Dynamics 365 دون إجبار النظام الخارجي على إجراء عمليات إعادة تسمية مكلفة للمخطط.

إضافةً إلى ذلك، يتطلب Dataverse معرّفاً فريداً موثوقاً لكل سجل للتمييز بين كل إدخال وآخر. ويجب أن تحتوي سجلات Virtual Table على مفاتيح فريدة موثوقة يستطيع Dataverse التعرف عليها. فمن دون معرّف قوي، لن يتمكن Dataverse من تحديد المنتج أو الفاتورة أو العميل الدقيق الذي اختاره المستخدم بثقة. لذلك تُعد هوية السجل شرطاً تقنياً أساسياً عند تقييم مدى إمكانية عمل مصدر بيانات خارجي معين بفعالية عبر Virtual Tables.

متى تستخدم Virtual Tables في بنيتك

تمثل Virtual Tables تحولاً معمارياً قوياً في النموذج. وتعمل بأفضل صورة في السيناريوهات التي يتولى فيها نظام خارجي متخصص بوضوح إدارة البيانات الرئيسية، بينما يحتاج مستخدمو Dynamics 365 إلى وصول سياقي إلى هذه المعلومات خلال سير عملهم اليومي. ومن الأمثلة البارزة: تتبّع المخزون الحي، وكتالوجات المنتجات المعقدة، وحالات أوامر الشراء، وحالات الفواتير الفورية، وملخصات دفتر الأستاذ المالي، ودلائل الموردين، والرؤى التسويقية المستهدفة.

عندما يتولى التطبيق الخارجي إدارة دورة حياة سجل العمل، ويمنح مستخدمي Dynamics 365 رؤيةً سياقية، فإنك تتخلص من مخاطر تكرار البيانات، وتقلّل من تضخم التخزين في Dataverse، وتضمن أن فرقك تتخذ قراراتها دائماً استناداً إلى معلومات حية ودقيقة. لقد حان الوقت للتوقف عن نسخ بياناتك والبدء في الاستفادة من قوة الافتراضية الحديثة.

وختاماً، إن الانتقال من المزامنة التقليدية للبيانات إلى اعتماد Virtual Tables يمكن أن يُبسّط بنية Microsoft 365 لديك بشكلٍ ملحوظ. فأنت تحافظ على مصدر الحقيقة الواحد سليماً، وتتخلص من فترات البيانات القديمة، وتمنح مستخدميك مساحة العمل الموحدة التي طالما طلبوها. وللاطلاع على تفاصيل أعمق حول هذا الموضوع، لا تفوّت الاستماع إلى الحلقة الكاملة عبر Dynamics 365 Virtual Entities - Simply Explained.