أحداث Business Central مقابل المشغّلات في AL: دليل المطوّر حول التوقيت

By Mirko Peters · 2026-08-22

أتقن تطوير Business Central باستخدام AL من خلال فهم متى تستخدم المشغّلات ومتى تستخدم مشتركي الأحداث لمنطق الأعمال المخصص والتحقق من الصحة وفحوصات الترحيل.

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

إن فهم الفرق بين المشغّلات والأحداث في تطوير AL لـ Microsoft Dynamics 365 Business Central أمر حيوي لكتابة امتدادات نظيفة وقابلة للصيانة. فاختيار آلية التنفيذ الصحيحة يضمن تشغيل قواعد التحقق في اللحظة المناسبة تمامًا، مما يمنع إدخال بيانات خاطئة ويحافظ على سلاسة التحديثات السحابية دون تكرار شيفرة التطبيق الأساسي.

النقاط الرئيسية

• المشغّلات مضمّنة مباشرةً داخل كائنات AL معيّنة لتنفيذ الشيفرة فورًا عند وقوع حدث الكائن أو تعديل البيانات.
• تتيح مشتركات الأحداث لامتدادك الاستماع إلى الإشعارات على مستوى النظام دون تعديل شيفرة التطبيق الأساسي أو نسخ العمليات الأصلية الضخمة.
• يحدد الاختيار بين أحداث "on before" و"on after" ما إذا كانت شيفرتك المخصصة قادرة على منع المعاملة أو تقتصر على الاستجابة لإجراء مكتمل.
• يضمن التوقيت الصحيح التقاط قواعد التحقق للأخطاء مبكرًا مع تجنب اختناقات الأداء أثناء العمليات الثقيلة مثل ترحيل أوامر البيع.

بنية المنطق المخصص في Business Central

عند توسيع Dynamics 365 Business Central باستخدام لغة التطبيقات (AL) من Microsoft، تكون كتابة الشيفرة نصف المعركة فقط. فالتحدي الحقيقي يكمن في تحديد أين ومتى ينبغي أن تُنفَّذ تلك الشيفرة. سواء كنت تضيف حقل مستوى مكافأة بسيطًا إلى سجل عميل، أو تفرض فحص امتثال معقدًا قبل إنشاء فاتورة، فإن ديمومة امتدادك واستقراره يعتمدان على الطريقة التي تربط بها نفسك بالنظام.

شجّعت نماذج التطوير القديمة كثيرًا من المطورين على إعادة كتابة شيفرة التطبيق الأصلية مباشرةً. فإذا أردت تشغيل فحص قبل ترحيل مستند ما، كنت تحقن منطقك مباشرةً في روتين الترحيل الأساسي. ورغم أن ذلك كان يعمل مؤقتًا، فإن كل تحديث رئيسي من Microsoft كان يتحول إلى مشروع مؤلم للمطابقة وإعادة الضبط. يعتمد تطوير امتدادات Business Central الحديث على نموذج معياري قائم على التطبيقات. وبدلًا من إعادة كتابة الروتينات القياسية، يستخدم المطورون نقاط الربط المدمجة، وتحديدًا المشغّلات والأحداث، لدمج المنطق المخصص بأمان جنبًا إلى جنب مع شيفرة التطبيق القياسية.

فك غموض مشغّلات AL

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

لنأخذ سيناريو عمليًا: أضافت مؤسستك حقل معرّف مكافأة مخصصًا (Reward ID) إلى سجل العميل. عندما يختار المستخدم مستوى مكافأة من القائمة المنسدلة، تحتاج إلى أن يتحقق النظام فورًا مما إذا كان حساب العميل محظورًا أو ما إذا كانت السمات الثانوية تتطلب تحديثًا. باستخدام المشغّل OnValidate على ذلك الحقل تحديدًا، تُنفَّذ شيفرتك في اللحظة نفسها التي يُجري فيها المستخدم التغيير.

متى تستخدم المشغّلات

يكون استخدام المشغّلات (Triggers) الأمثل عندما ينحصر منطق عملك في كائن واحد وسياقه المباشر. على سبيل المثال:

• التحقق من أن حقل تاريخ مخصص يقع ضمن ربع السنة المالي المقبول في العمل.
• تنفيذ منطق التهيئة عند فتح صفحة بطاقة لإدخال سجل جديد.
• مسح قيم الحقول التابعة عند إلغاء تحديد الخيار الرئيسي.

ولأن المشغّلات محصورة بإحكام في الكائنات المضيفة لها، فإنها تجعل الشيفرة المحلية سهلة العثور عليها وقراءتها وصيانتها مع مرور الوقت.

الاستفادة من أحداث Business Central والاشتراك فيها

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

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

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

قوة التوقيت: OnBefore مقابل OnAfter

عند بناء مشتركي الأحداث في AL، تكشف أسماء الاصطلاحات عن توقيت التنفيذ. وفهم هذا التوقيت بالغ الأهمية لموثوقية النظام:

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

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

الخاتمة

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

للتعمّق أكثر في مبادئ تصميم التطبيقات الحديثة والاستماع إلى تحليلات معمارية من الخبراء، استمع إلى الحلقة كاملة من بودكاست M365 FM. تابع لتكتشف كيف يُحسّن مهندسو السحابة والمطورون منظومة Microsoft لتحقيق نجاح أعمال حقيقي!

الأسئلة المتداولة

ما الفرق الجوهري بين المشغّل ومشترك الأحداث في AL؟

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

هل يمكن لمشترك حدث أن يمنع ترحيل أمر بيع؟

نعم، إذا استخدمت مشترك حدث 'on before' مرتبطاً بعملية الترحيل، فيمكن لشيفرتك المخصصة تقييم شروط العمل، وإطلاق رسالة خطأ، وإيقاف المعاملة قبل أن يُنهي إجراء الترحيل القيود.

متى ينبغي استخدام مشغّل التحقق من حقل الجدول بدلاً من مشترك الأحداث؟

ينبغي استخدام مشغّل التحقق من حقل الجدول عندما تكون قاعدة عملك مرتبطة حصراً بتغيّر قيمة ذلك الحقل تحديداً، مثل التحقق من وجود معرّف مكافأة مخصص (Reward ID)، أو ضمان تحديث حقل حالة مرتبط فوراً عند إدخال المستخدم.

لماذا يُعد توقيت التنفيذ بالغ الأهمية عند كتابة مشتركي أحداث AL؟

يحدد توقيت التنفيذ ما إذا كان الكود سيعمل قبل اكتمال عملية أساسية أو بعدها. فإذا عمل القاعدة مبكرًا جدًا، قد لا تكون البيانات الضرورية قد تمت تعبئتها بعد؛ وإذا عملت متأخرًا جدًا، فستفقد القدرة على منع المعاملات غير الصالحة.