تحديد متى يتم تكوين التعليمات البرمجية أو متى يتم تهيئتها

مكتمل

بصفتك مطوّراً، عليك التعامل مع التطبيقات على Microsoft Power Platform مِن منظور أنه يجب أن يتم اعتبار كتابة التعليمات البرمجية لتحقيق الوظيفة المطلوبة لتطبيق الأعمال استثناءً لأسلوبَي عدم استخدام تعليمات برمجية أو استخدام تعليمات برمجية منخفضة. ومع ذلك، يجب أيضاً مراعاة الجوانب المرتبطة بالجودة، مثل إمكانية الصيانة والترقية والاستقرار والأداء عند تحديد أفضل أسلوب لسيناريو محدد.

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

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

قواعد العمل مقابل البرنامج النصي للعميل

تتمثل ميزة قواعد العمل فِي سهولة فهمها وتنفيذها لغير المطورين ويمكن تضمينها كجزء مِن حل Dataverse الذي سيتم توزيعه فِي الإنتاج. في المؤسسات التي لا تتوفر فيها مهارات المطورين بسهولة ولا يتم تنفيذ إدارة دورة حياة التطبيق، ستكون قواعد العمل هي الطريقة المفضلة لتنفيذ المنطق حتى إذا كانت بعض الحلول مطلوبة، على سبيل المثال، الحقول المحسوبة الوسيطة التي تضم القيم المطلوب التحقّق منها فِي إحدى القواعد.

مع ذلك، فِي مرحلة ما، يتعذر على قواعد العمل تلبية متطلبات العمل أو قد يؤدي التعقيد الذي تفرضه القواعد إلى جعل المطورين يفضلون كتابة المنطق فِي البرنامج النصي للعميل. أحد السيناريوهات هو إذا كان لديك منطق "if/then/else" معقد ومتداخل، فمن الأفضل أن يتحقق باستخدام عبارة switch أو تسلسل بسيط مِن كتل if. والسيناريو الآخر هو عند التعامل مع القيم الديناميكية التي لا يمكن الوصول إليها بسهولة بواسطة قاعدة العمل. على سبيل المثال، لا تتوفر إخطارات النماذج وتصفية قيم الاختيار مِن خلال قواعد العمل.

مهام سير العمل/تدفقات Power Automate مقارنة بالمكونات الإضافية

يقدم Dataverse أساليب مختلفة لتنفيذ المنطق للاستجابة للأحداث فِي النظام، ولا سيما لتغييرات البيانات، مثل إنشاء صفوف البيانات وتحديثها وحذفها. يمكن تلبية متطلبات العمل مِن خلال حلول بدون تعليمات برمجية باستخدام سير العمل وPower Automate ومن خلال توسيع Dataverse باستخدام التعليمات البرمجية على جانب الخادم (المكونات الإضافية) أو على جانب العميل (البرنامج النصي).

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

القدرة	تدفق Power Automate	سير العمل	المكون الإضافي
متزامنة أو غير متزامنة	غير متزامنة	أي واحد (يوصى بمهام تدفق Power Automate بدلاً مِن مهام سير العمل غير المتزامنة)	أي واحد
الوصول إلى البيانات الخارجية	نعم، باستخدام الموصلات	لا	نعم، باستخدام واجهات API، وبعض القيود الأمنية
الصيانة	المنشئون	مستخدمو وحدة الأعمال	المطورون
إمكانية التشغيل كـ	مستخدِم حالي أو مالك سير العمل	مستخدم حالي أو مالك سير العمل	أي مستخدم أو نظام مرخص أو مستخدم حالي
إمكانية التشغيل حسب الطلب	نعم	نعم	لا
إمكانية تداخل العمليات الفرعية	نعم	نعم	نعم
مرحلة التنفيذ	بعد	قبل/بعد	قبل/بعد
المشغّلات	إنشاء، تغيير العمود، حذف، حسب الطلب، مجدول	إنشاء، تغيير العمود، حذف، حسب الطلب	إنشاء، تغيير العمود، حذف، رسائل أخرى بما فِي ذلك رسائل مخصصة

يتطور Microsoft Power Platform باستمرار وكمطور يجب أن تكون على علم بالميزات الجديدة والقادمة. على سبيل المثال، إذا كان الحل الذي تستخدمه يتطلب إعدادات مخصصة أو قيم تكوين، ففي السابق كان يجب عليك استخدام جداول مخصصة لتخزين هذه القيم ثم استخدام تعليمات برمجية مخصصة أو أدوات النظام الأساسي لتوزيع البيانات. أدت إضافة متغيرات البيئة الجديدة إلى تبسيط هذه المهمة واختصارها إلى الإعلان عن المتغيرات الخاصة بك، وتضمينها كجزء مِن الحلول، وتعيين القيم، كل ذلك بدون أي تعليمات برمجية.

Power Apps Component Framework (‏PCF)

لسنوات عديدة، كانت موارد HTML للويب مستخدمة كآلية مفضلة للتوسعة بالنسبة إلى جانب العميل فِي التطبيقات التي تستند إلى نموذج. وكان أحد نقاط الضعف فِي هذا الأسلوب هو انخفاض نسبة إعادة استخدام هذه العناصر المكونة مِن وحدة واحدة وغير القابلة للتوسعة. الآن تم استبدال موارد HTML للويب بعناصر تحكم PCF.

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

الأنظمة الخارجية

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

ومع ذلك، مع اعتماد Power Automate مع مئات الموصلات التابعة له، يمكن الآن تنفيذ التفاعلات مع الأنظمة الخارجية بواسطة منشئي التطبيقات بدون استخدام أي كود.

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

المداخل مقابل المواقع المخصصة

توفّر Power Pages العديد مِن الوظائف الجاهزة للاستخدام وتمكن منشئيها مِن إنشاء مواقع ويب قوية وتوسيعها حسب الحاجة. كثيراً ما يقدّم المطورون المساعدة فِي مهام المداخل الأكثر صعوبة مثل تنسيقات الصفحات المعقدة (باستخدام لغة القوالب Liquid) أو توسيع وظائف الموقع الأمامية باستخدام JavaScript.

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

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

من الضروري تحديث كل مطوّر لفهمه ومعرفته بقدرات النظام الأساسي حتى يتمكن مِن اتخاذ قرارات منطقية ورشيدة حول حالات استخدام التعليمات البرمجية مقارنة بحالات تعديل النظام، بحيث يمكن تخصيصه وتكوينه مِن قبَل المنشئين ومستخدمي الأعمال.