الاختلافات بين تطبيقات منطق المستأجر الفردي القياسية مقابل تطبيقات المنطق متعددة المستأجرين الاستهلاك
Azure Logic Apps عبارة عن نظام أساسي يستند إلى السحابة لإنشاء وتشغيل مهام سير عمل تطبيقات منطقية مؤتمتة والتي تدمج تطبيقاتك وبياناتك وخدماتك وأنظمتك. باستخدام هذا النظام الأساسي، يمكنك تطوير حلول تكامل قابلة للتطوير بشكل سريع لمؤسستك وسيناريوهات معاملات الشركات. عند إنشاء مورد تطبيق منطقي، يمكنك تحديد إما خيار Consumption أو Standard hosting. يمكن أن يحتوي تطبيق منطق الاستهلاك على سير عمل واحد فقط يعمل في Azure Logic Apps متعددة المستأجرين . يمكن أن يحتوي تطبيق المنطق القياسي على سير عمل واحد أو عدة مهام سير عمل تعمل في Azure Logic Apps أحادية المستأجر أو App Service Environment v3 (ASE v3).
قبل اختيار مورد تطبيق المنطق الذي يجب إنشاؤه، راجع الدليل التالي لمعرفة كيفية مقارنة أنواع سير عمل التطبيق المنطقي مع بعضها البعض. يمكنك بعد ذلك إجراء اختيار أفضل حول سير عمل التطبيق المنطقي والبيئة الأنسب للسيناريو ومتطلبات الحل والوجهة حيث تريد نشر مهام سير العمل وتشغيلها.
إذا كنت جديدا على Azure Logic Apps، فراجع ما هي Azure Logic Apps؟ وما هو سير عمل تطبيق المنطق؟.
أنواع سير عمل التطبيق المنطقي والبيئات
يلخص الجدول التالي الاختلافات بين سير عمل تطبيق منطق الاستهلاك وسير عمل تطبيق المنطق القياسي . يمكنك أيضا معرفة كيفية اختلاف بيئة المستأجر الفردي عن البيئة متعددة المستأجرين لنشر مهام سير العمل الخاصة بك واستضافتها وتشغيلها.
| خيار الاستضافة | المزايا | مشاركة الموارد واستخدامها | نموذج التسعير والفوترة | إدارة الحدود |
|---|---|---|---|---|
| استهلاك بيئة المضيف: تطبيقات Azure Logic Apps متعددة المستأجرين |
- أسهل للبدء - ادفع مقابل ما تستخدمه - مدار بالكامل |
يمكن أن يكون لمورد تطبيق منطقي واحد سير عمل واحد فقط. تشترك جميع تطبيقات المنطق عبر مستأجري Microsoft Entra في نفس المعالجة (الحساب) والتخزين والشبكة وما إلى ذلك. لأغراض التكرار، يتم نسخ البيانات نسخا متماثلا في المنطقة المقترنة. للحصول على قابلية وصول عالية، تم تمكين التخزين الاحتياطي جغرافياً (GRS). |
الاستهلاك (الدفع عند التنفيذ) | تدير Azure Logic Apps القيم الافتراضية لهذه الحدود، ولكن يمكنك تغيير بعض هذه القيم، إذا كان هذا الخيار موجودًا لحد معين. |
| قياسي (خطة خدمة سير العمل) بيئة المضيف: تطبيقات Azure Logic Apps أحادية المستأجر ملاحظة:إذا كان السيناريو الخاص بك يتطلب حاويات، قم بإنشاء تطبيقات منطقية مستندة إلى مستأجر واحد باستخدام Azure Arc enabled Logic Apps. لمزيد من المعلومات، راجع ما هي Azure Arc enabled Logic Apps؟ |
- المزيد من الموصلات المضمنة المستضافة في وقت تشغيل المستأجر الفردي للحصول على معدل نقل أعلى وتكاليف أقل على نطاق واسع - المزيد من التحكم وإمكانية الضبط حول وقت التشغيل وإعدادات الأداء - الدعم المتكامل للشبكات الظاهرية ونقاط النهاية الخاصة. - إنشاء الوصلات المدمجة الخاصة بك. |
يمكن أن يكون لمورد تطبيق منطقي واحد مهام سير عمل متعددة ذات حالة وبدون حالة. تشارك مهام سير العمل في logic app الواحد والمستأجر نفس المعالجة (الحوسبة) والتخزين والشبكة وما إلى ذلك. تظل البيانات في نفس المنطقة حيث تقوم بنشر تطبيق المنطق الخاص بك. |
قياسي، استناداً إلى خطة استضافة على مستوى تسعير محدد إذا قمت بتشغيل مهام سير العمل ذات الحالة، والتي تستخدم التخزين الخارجي،يقوم وقت تشغيلAzure Logic Apps بإجراء معاملات التخزين التي تتبع تسعير Azure Storage. |
يمكنك تغيير القيم الافتراضية للعديد من الحدود، استنادًا إلى احتياجات السيناريو الخاص بك. هام:تتمتع بعض الحدود بحدود قصوى صعبة. في تعليمة Visual Studio البرمجية، لن تظهر التغييرات التي تقوم بها على قيم الحد الافتراضي في ملفات تكوين مشروع logic app في تجربة المصمم. لمزيد من المعلومات، راجع تحرير إعدادات التطبيق والبيئة للتطبيقات المنطقية في Azure Logic Apps أحادية المستأجر. |
| قياسي (App Service Environment v3) بيئة المضيف: بيئة خدمة التطبيق الإصدار 3 (ASEv3) - خطط Windows فقط |
نفس قدرات المستأجر الفردي بالإضافة إلى المزايا التالية: - عزل logic apps الخاصة بك تماماً. - إنشاء وتشغيل logic apps أكثر مما كانت عليه في Azure Logic Apps المستأجر الواحد. - الدفع فقط مقابل خطة ASE App Service، بغض النظر عن عدد logic apps التي تقوم بإنشائها وتشغيلها. - يمكن تمكين autoscaling أو المقياس يدوياً باستخدام المزيد من مثيلات الجهاز الظاهري أكثر أو خطة خدمة التطبيقات المختلفة. - وراثة إعداد الشبكة من ASEv3 المحدد. على سبيل المثال، عند النشر إلى ASE داخلي، يمكن لسير العمل الوصول إلى الموارد في شبكة ظاهرية مقترنة ب ASE والحصول على نقاط وصول داخلية. ملاحظة: إذا تم الوصول إليها من خارج ASE الداخلي، يتم تشغيل سجلات سير العمل في ذلك حيث لا يمكن لـASE الوصول إلى مدخلات ومخرجات الإجراء. |
يمكن أن يتمتع logic app الواحد بعدة مهام سير عملذات الحالةوعديمة الحالة. تشارك مهام سير العمل في logic app الواحد والمستأجر نفس المعالجة (الحوسبة) والتخزين والشبكة وما إلى ذلك. تبقى البيانات في نفس المنطقة حيث يمكنك نشر logic apps الخاصة بك. |
خطة App Service | يمكنك تغيير القيم الافتراضية للعديد من الحدود، استنادًا إلى احتياجات السيناريو الخاص بك. هام:تتمتع بعض الحدود بحدود قصوى صعبة. في تعليمة Visual Studio البرمجية، لن تظهر التغييرات التي تقوم بها على قيم الحد الافتراضي في ملفات تكوين مشروع logic app في تجربة المصمم. لمزيد من المعلومات، راجع تحرير إعدادات التطبيق والبيئة للتطبيقات المنطقية في Azure Logic Apps أحادية المستأجر. |
تطبيق المنطق القياسي وسير العمل
يتم تشغيل تطبيق المنطق القياسي وسير العمل من خلال وقت تشغيل Azure Logic Apps أحادي المستأجر المعاد تصميمه. يستخدم وقت التشغيل هذا نموذج قابلية توسعة Azure Functions ويُستضاف كملحق في وقت تشغيل Azure Functions. يوفر هذا التصميم قابلية النقل والمرونة والمزيد من الأداء لسير عمل تطبيق المنطق بالإضافة إلى القدرات والمزايا الأخرى الموروثة من النظام الأساسي ل Azure Functions والنظام البنائي لخدمة تطبيقات Azure. على سبيل المثال، يمكنك إنشاء وتوزيع وتشغيل تطبيقات منطقية مستندة إلى مستأجر أحادي ومهام سير العمل الخاصة بها في بيئة خدمة التطبيق من Azure الإصدار 3 (خطط Windows فقط).
يقدم تطبيق المنطق القياسي بنية موارد يمكنها استضافة مهام سير عمل متعددة، على غرار كيفية استضافة تطبيق وظائف Azure لوظائف متعددة. مع تعيين 1 إلى متعدد، تشارك مهام سير العمل في نفس التطبيق المنطقي والمستأجر موارد الحوسبة والمعالجة، ما يوفر أداءً أفضل بسبب قربها. تختلف هذه البنية عن مورد تطبيق منطق الاستهلاك حيث يكون لديك تعيين 1 إلى 1 بين مورد تطبيق المنطق وسير العمل.
لمعرفة المزيد حول قابلية النقل والمرونة وتحسينات الأداء، تابع مراجعة الأقسام التالية. لمزيد من المعلومات حول وقت تشغيل Azure Logic Apps أحادي المستأجر وقابلية توسعة Azure Functions، راجع الوثائق التالية:
- Azure Logic Apps التي تعمل في أي مكان - التعمق في وقت التشغيل
- مقدمة إلى Azure Functions
- مشغلات وعمليات الربط في Azure Functions
قابلية النقل والمرونة
عند إنشاء تطبيق منطق قياسي وسير عمل، يمكنك نشر سير العمل وتشغيله في بيئات أخرى، مثل Azure App Service Environment v3 (خطط Windows فقط) . إذا كنت تستخدم Visual Studio Code مع ملحق Azure Logic Apps (Standard)، يمكنك تطوير سير العمل الخاص بك وبنته وتشغيله محليا في بيئة التطوير الخاصة بك دون الحاجة إلى النشر إلى Azure. إذا كان السيناريو الخاص بك يتطلب حاويات، يمكنك إنشاء تطبيقات منطق مستأجر واحد باستخدام Logic Apps الممكنة بواسطة Azure Arc. لمزيد من المعلومات، راجع ما هي Logic Apps الممكنة في Azure Arc؟
توفر هذه الإمكانات تحسينات كبيرة وفوائد كبيرة مقارنة بالنموذج متعدد المستأجرين، والذي يتطلب منك التطوير مقابل مورد قيد التشغيل موجود في Azure. يستند النموذج متعدد المستأجرين لأتمتة توزيع موارد تطبيق منطق الاستهلاك إلى قوالب Azure Resource Manager (قوالب ARM)، التي تجمع بين إدارة الموارد وتعالجها لكل من التطبيقات والبنية الأساسية.
باستخدام مورد تطبيق المنطق القياسي، يصبح النشر أسهل لأنه يمكنك فصل توزيع التطبيق عن نشر البنية الأساسية. يمكنك حزم وقت تشغيل Azure Logic Apps أحادي المستأجر ومهام سير العمل الخاصة بك معا كجزء من مورد التطبيق المنطقي أو المشروع. يمكنك استخدام خطوات أو مهام عامة تقوم بإنشاء موارد التطبيق المنطقي وتجميعها وضغطها في بيانات اصطناعية جاهزة للتوزيع. لتوزيع البنية الأساسية الخاصة بك، لا يزال بإمكانك استخدام قوالب ARM لتوفير هذه الموارد بشكل منفصل بجانب العمليات والمسارات الأخرى التي تستخدمها لتلك الأغراض.
لتوزيع تطبيقك، انسخ البيانات الاصطناعية إلى بيئة المضيف ثم ابدأ تشغيل تطبيقاتك لتشغيل مهام سير العمل. أو، ادمج البيانات الاصطناعية الخاصة بك في مسارات التوزيع باستخدام أدوات وعمليات تعرفها وتستخدمها بالفعل. وبهذه الطريقة، يمكنك التوزيع باستخدام الأدوات التي اخترتها، بغض النظر عن مكدس التكنولوجيا الذي تستخدمه للتطوير.
باستخدام خيارات الإنشاء والتوزيع القياسية، يمكنك التركيز على تطوير التطبيقات بشكل منفصل عن توزيع البنية الأساسية. ونتيجة لذلك، يمكنك الحصول على نموذج مشروع أكثر عمومية حيث يمكنك تطبيق العديد من خيارات التوزيع المماثلة أو الخيارات نفسها التي تستخدمها لتطبيق عام. كما يمكنك الاستفادة من تجربة أكثر اتساقا عند إنشاء مسارات توزيع لتطبيقاتك وعند تشغيل الاختبارات والتحقق من الصحة المطلوبة قبل النشر إلى الإنتاج.
الأداء
باستخدام تطبيق منطق قياسي، يمكنك إنشاء وتشغيل مهام سير عمل متعددة في نفس مورد التطبيق المنطقي الفردي والمستأجر. باستخدام التعيين من 1 إلى متعدد هذا، تشارك مهام سير العمل هذه الموارد، مثل الحوسبة والمعالجة والتخزين والشبكة، ما يوفر أداءً أفضل بسبب قربها.
يوفر مورد تطبيق المنطق القياسي ووقت تشغيل Azure Logic Apps أحادي المستأجر تحسنا كبيرا آخر من خلال إتاحة الموصلات المدارة الأكثر شيوعا كعمليات موصل مضمنة. على سبيل المثال، يمكنك استخدام عمليات الموصل المضمنة ناقل خدمة Azure وAzure Event Hubs وSQL Server وغيرها. وفي الوقت نفسه، لا تزال إصدارات الموصل المُدار متوفرة ومستمرة في العمل.
عند استخدام عمليات الموصل المضمنة الجديدة، يمكنك إنشاء اتصالات تسمى الاتصالات المضمنة أو اتصالات موفر الخدمة. تسمى نظيرات الاتصال المُدارة اتصالات واجهة برمجة التطبيقات، والتي يتم إنشاؤها وتشغيلها بشكل منفصل كموارد Azure التي يجب عليك أيضاً توزيعها بعد ذلك باستخدام قوالب ARM. تعمل العمليات المُضمّنة واتصالاتها محلياً في نفس العملية التي تقوم بتشغيل مهام سير العمل. كلاهما مُستضاف في وقت تشغيل Azure Logic Apps أحادي المستأجر. ونتيجة لذلك، توفر العمليات المُضمّنة واتصالاتها أداءً أفضل بسبب التقارب مع مهام سير العمل. يعمل هذا التصميم أيضاً بشكل جيد مع مسارات التوزيع لأن اتصالات موفّر الخدمة يتم تعبئتها في نفس البيانات الاصطناعية للبناء.
موقع البيانات
تتم استضافة موارد تطبيق المنطق القياسية في Azure Logic Apps أحادية المستأجر، والتي لا تخزن البيانات أو تعالجها أو تنسخها نسخا متماثلا خارج المنطقة حيث تقوم بنشر موارد تطبيق المنطق هذه، ما يعني أن البيانات في مهام سير العمل الخاصة بك تبقى في نفس المنطقة حيث تقوم بإنشاء الموارد الأصلية ونشرها.
الوصول المباشر إلى الموارد في شبكات Azure الظاهرية
يمكن لسير العمل التي تعمل في Azure Logic Apps أحادية المستأجر الوصول مباشرة إلى الموارد الآمنة مثل الأجهزة الظاهرية (VMs) والخدمات الأخرى والأنظمة الموجودة في شبكة Azure الظاهرية.
Azure Logic Apps أحادي المستأجر هو مثيل مخصص لخدمة Azure Logic Apps، ويستخدم موارد مخصصة، ويعمل بشكل منفصل عن Azure Logic Apps متعددة المستأجرين. يساعد تشغيل مهام سير العمل في مثيل مخصص على تقليل تأثير مستأجري Azure الآخرين على أداء التطبيق، والمعروف أيضا باسم تأثير "الجيران المزعجين".
توفر Azure Logic Apps أحادية المستأجر أيضا المزايا التالية:
عناوين IP الثابتة الخاصة بك، والتي تكون منفصلة عن عناوين IP الثابتة التي تشاركها تطبيقات المنطق في Azure Logic Apps متعددة المستأجرين. يمكنك أيضاً إعداد عنوان IP خارجي عام وثابت وقابل للتنبؤ للاتصال بأنظمة الوجهة. وبهذه الطريقة، لا يتعين عليك إعداد فتحات إضافية لجدار الحماية في أنظمة الوجهة هذه.
قيود متزايدة على مدة التشغيل، والاحتفاظ بالتخزين، والإنتاجية، ومهلة طلب HTTP والاستجابة، وأحجام الرسائل، وطلبات الموصل المخصص. لمزيدٍ من المعلومات، راجع الحدود والتكوين لـ Azure Logic Apps.
إنشاء الخيارات وبنائها وتوزيعها
لإنشاء مورد تطبيق منطقي استنادا إلى البيئة التي تريدها، لديك خيارات متعددة، على سبيل المثال:
بيئة المستأجر الأحادي
| خيار | الموارد والأدوات | مزيد من المعلومات |
|---|---|---|
| مدخل Azure | تطبيق المنطق القياسي | إنشاء مثال لسير عمل تطبيق المنطق القياسي في تطبيقات Azure Logic Apps أحادية المستأجر - مدخل Microsoft Azure |
| تعليمة Visual Studio برمجية | ملحق Azure Logic Apps (Standard) | إنشاء مثال لسير عمل تطبيق المنطق القياسي في تطبيقات Azure Logic Apps أحادية المستأجر - Visual Studio Code |
| Azure CLI | ملحق Logic Apps Azure CLI | az logicapp |
| Azure Resource Manager | - محلي - DevOps |
تطبيقات Azure Logic Apps أحادية المستأجر |
| تمكين Azure Arc لـ Logic Apps | نموذج Logic Apps الذي تم تمكينه من Azure Arc | - ما هي Logic Apps التي تمكنها Azure Arc؟ - إنشاء مهام سير عمل التطبيق المنطقي القائم على المستأجر الفردي ونشرها باستخدام Logic Apps الممكّنة في Azure Arc |
| Azure REST API | واجهة برمجة تطبيقات REST لخدمة تطبيقات Azure* ملاحظة: يتم تضمين تطبيق المنطق القياسي REST API مع Azure App Service REST API. |
ابدأ باستخدام مرجع واجهة برمجة تطبيقات REST في Azure |
بيئة متعددة المستأجرين
على الرغم من اختلاف تجارب التطوير بناءً على ما إذا كنت تنشئ موارد تطبيق منطقي Consumption أو Standard، يمكنك العثور على جميع تطبيقاتك المنطقية التي تم توزيعها والوصول إليها ضمن اشتراك Azure الخاص بك.
على سبيل المثال، في مدخل Microsoft Azure، تعرض صفحة Logic apps كلا من الاستهلاك وموارد تطبيق المنطق القياسي. في Visual Studio Code، تظهر تطبيقات المنطق المنشورة ضمن اشتراك Azure، ولكن تظهر تطبيقات منطق الاستهلاك في نافذة Azure ضمن ملحق Azure Logic Apps (Consumption)، بينما تظهر تطبيقات المنطق القياسي ضمن قسم الموارد .
مهام سير العمل ذات الحالة ومهام سير العمل عديمة الحالة
ضمن تطبيق منطق قياسي، يمكنك إنشاء أنواع سير العمل التالية:
ذو حالة
قم بإنشاء سير عمل ذي حالة عندما تحتاج إلى الاحتفاظ بالبيانات أو مراجعتها أو الرجوع إليها من الأحداث السابقة. تحتفظ مهام سير العمل هذه بجميع مدخلات العمليات ومخرجاتها وحالاتها في التخزين الخارجي. تجعل هذه المعلومات مراجعة تفاصيل تشغيل سير العمل والمحفوظات ممكنة بعد انتهاء كل عملية تشغيل. توفر مهام سير العمل ذات الحالة مرونة عالية في حال حدوث انقطاعات. بعد استعادة الخدمات والأنظمة، يمكنك إعادة إنشاء عمليات التشغيل التي تمت مقاطعتها من الحالة المحفوظة وإعادة تشغيل مهام سير العمل حتى الاكتمال. يمكن أن تستمر مهام سير العمل ذات الحالة في العمل لفترة أطول بكثير من مهام سير العمل عديمة الحالة.
بشكل افتراضي، تعمل مهام سير العمل ذات الحالة في كل من تطبيقات Azure Logic Apps متعددة المستأجرين والمستأجر الواحد بشكل غير متزامن. تتبع جميع الإجراءات المستندة إلى HTTP نمط العملية غير المتزامن القياسي. بعد أن يستدعي إجراء HTTP أو يرسل طلباً إلى نقطة نهاية أو خدمة أو نظام أو واجهة برمجة تطبيقات، يقوم مستلم الطلب فوراً بإرجاع استجابة "202 ACCEPTED". تؤكد هذه التعليمة البرمجية أن المتلقي قبل الطلب ولكنه لم ينته من المعالجة. يمكن أن تتضمن الاستجابة عنوان
locationالذي يحدد URI ومعرّف التحديث الذي يمكن للمتصل استخدامه للاستقصاء أو التحقق من حالة الطلب غير المتزامن حتى يتوقف المتلقي عن المعالجة ويرجع استجابة نجاح "200 OK" أو استجابة أخرى غير 202. ومع ذلك، لا يتعين على المتصل الانتظار حتى ينتهي الطلب من المعالجة ويمكنه المتابعة لتشغيل الإجراء التالي. لمزيد من المعلومات، راجع يفرض تكامل الخدمات المصغرة غير المتزامن استقلالية الخدمات المصغرة.عديم الحالة
قم بإنشاء سير عمل عديم الحالة عندما لا تحتاج إلى الاحتفاظ بالبيانات أو مراجعتها أو الرجوع إليها من الأحداث السابقة في التخزين الخارجي بعد انتهاء كل تشغيل للمراجعة لاحقاً. تحفظ مهام سير العمل هذه جميع المدخلات والمخرجات لكل إجراء وحالاتها في الذاكرة فقط، وليس في التخزين الخارجي. ونتيجة لذلك، فإن مهام سير العمل عديمة الحالة لها عمليات تشغيل أقصر تنتهي عادةً في غضون 5 دقائق أو أقل، وأداء أسرع مع أوقات استجابة أسرع ومعدل نقل أعلى وتكاليف تشغيل أقل لأن التخزين الخارجي لا يحفظ تفاصيل تشغيل سير العمل والمحفوظات. ومع ذلك، إذا حدث انقطاع، فلا تتم استعادة عمليات التشغيل التي تمت مقاطعتها تلقائياً، لذلك يحتاج المتصل إلى إعادة إرسال عمليات التشغيل التي تمت مقاطعتها يدوياً.
يوفر سير العمل عديم الحالة أفضل أداء عند معالجة البيانات أو المحتوى الذي لا يتجاوز 64 كيلوبايت بالحجم الإجمالي، مثل ملف. قد تؤدي أحجام المحتوى الأكبر، مثل المرفقات الكبيرة المتعددة، إلى إبطاء أداء سير العمل بشكل كبير أو حتى التسبب في تعطل سير العمل بسبب استثناءات نفاد الذاكرة. إذا كان سير العمل الخاص بك يجب أن يتعامل مع أحجام محتوى أكبر، فاستخدم سير عمل ذي حالة بدلاً من ذلك.
إشعار
في مهام سير العمل عديمة الحالة، يمكنك فقط استخدام مشغلات الدفع حيث لا تحدد جدولا للتشغيل لسير العمل الخاص بك. تنتظر هذه المشغلات المستندة إلى خطاف الويب حتى يحدث حدث أو تصبح البيانات متاحة. على سبيل المثال، يتوفر مشغل التكرار فقط لسير العمل ذي الحالة. لبدء سير العمل، حدد مشغل دفع مثل مشغل الطلب أو مراكز الأحداث أو ناقل خدمة Microsoft Azure. لمزيد من المعلومات حول المشغّلات والإجراءات والموصلات المحدودة أو غير المتوفرة أو غير المدعومة، راجع الإمكانات المتغيرة أو المحدودة أو غير المتوفرة أو غير المدعومة.
لا تعمل مهام سير العمل عديمة الحالة إلا بشكل متزامن لذلك لا تستخدم نمط العملية غير المتزامن القياسي الذي تستخدمه مهام سير العمل ذات الحالة. بدلاً من ذلك، تنتقل جميع الإجراءات المستندة إلى HTTP التي تعرض استجابة "202 ACCEPTED" إلى الخطوة التالية في تنفيذ سير العمل. إذا كانت الاستجابة تتضمن عنوان
location، فلن يقوم سير العمل عديم الحالة باستقصاء URI المُحدد للتحقق من الحالة. لاتباع نمط العملية غير المتزامن القياسي، استخدم سير عمل ذي حالة بدلاً من ذلك.لتسهيل تصحيح الأخطاء، يمكنك تمكين محفوظات التشغيل لسير عمل عديم الحالة، والذي له بعض التأثير على الأداء، ثم تعطيل محفوظات التشغيل عند الانتهاء. لمزيد من المعلومات، راجع إنشاء مهام سير عمل تستند إلى مستأجر أحادي في Visual Studio Code أو إنشاء مهام سير عمل تستند إلى مستأجر أحادي في مدخل Microsoft Azure.
هام
يجب أن تقرر نوع سير العمل، إما ذي الحالة أو عديم الحالة، للتنفيذ في وقت الإنشاء. تؤدي التغييرات التي تطرأ على نوع سير العمل بعد الإنشاء إلى حدوث أخطاء في وقت التشغيل.
اختلافات التلخيص بين مهام سير العمل ذات الحالة ومهام سير العمل عديمة الحالة
| ذو حالة | عديم الحالة |
|---|---|
| يخزن محفوظات التشغيل والمدخلات والمخرجات | لا يخزن محفوظات التشغيل أو المدخلات أو المخرجات بشكل افتراضي |
| مشغّلات الموصل المُدار متوفرة ومسموح بها | مشغّلات الموصل المُدار غير متوفرة أو غير مسموح بها |
| يدعم التقسيم | لا يدعم التقسيم |
| يدعم العمليات غير المتزامنة | لا يدعم العمليات غير المتزامنة |
| تحرير الحد الأقصى الافتراضي لمدة التشغيل في تكوين المضيف | الأفضل لسير العمل مع مدة قصوى أقل من 5 دقائق |
| يعالج الرسائل الكبيرة | الأفضل لمعالجة أحجام الرسائل الصغيرة (أقل من 64 كيلوبايت) |
اختلافات السلوك المتداخلة بين مهام سير العمل ذات الحالة ومهام سير العمل عديمة الحالة
يمكنك جعل سير العمل قابلا للاستدعاء من مهام سير العمل الأخرى الموجودة في نفس تطبيق المنطق القياسي باستخدام مشغل الطلب أو مشغل HTTP Webhook أو مشغلات الموصل المدارة التي تحتوي على نوع ApiConnectionWebhook ويمكنها تلقي طلبات HTTPS.
تصف القائمة التالية أنماط السلوك التي يمكن أن تتبعها مهام سير العمل المتداخلة بعد أن يستدعي سير العمل الأصل سير عمل فرعي:
نمط الاستقصاء غير المتزامن
لا ينتظر سير العمل الأصلي حتى يستجيب سير العمل الفرعي لاستدعائه الأولي. ومع ذلك، يتحقق الأصل باستمرار من محفوظات تشغيل الفرعي حتى ينتهي الفرعي من التشغيل. بشكل افتراضي، تتبع مهام سير العمل ذات الحالة هذا النمط، وهو مثالي لمهام سير العمل التابعة طويلة الأمد التي قد تتجاوز حدود مهلة الطلب.
نمط متزامن ("أطلق وانسَ")
يقر سير العمل الفرعي باستدعاء سير العمل الأصل من خلال إرجاع استجابة
202 ACCEPTEDعلى الفور. ومع ذلك، لا ينتظر الأصل حتى يرجع الفرعي النتائج. بدلاً من ذلك، يستمر الأصل في الإجراء التالي في سير العمل ويتلقى النتائج عندما ينتهي الفرعي من التشغيل. تتبع مهام سير العمل التابعة ذات الحالة التي لا تتضمن إجراء استجابة النمط المتزامن دائماً وتوفر لك محفوظات التشغيل لمراجعتها.لتمكين هذا السلوك، في تعريف JSON لسير العمل، قم بتعيين الخاصية
operationOptionsإلىDisableAsyncPattern. لمزيد من المعلومات، راجع أنواع المشغّلات والإجراءات - خيارات العملية.المشغّل والانتظار
يتم تشغيل مهام سير العمل عديمة الحالة داخل الذاكرة. لذلك عندما يستدعي سير العمل الأصل سير عمل عديم الحالة التابع، ينتظر الأصل استجابة تُرجع النتائج من التابع. يعمل هذا النمط بشكل مشابه لاستخدام مشغّل أو إجراء HTTP المُضمّن ليستدعي سير عمل تابع. تقوم مهام سير العمل التابعة عديمة الحالة التي لا تتضمن إجراء استجابة بإعادة استجابة
202 ACCEPTEDعلى الفور، ولكن الأصل ينتظر حتى ينتهي التابع قبل المتابعة إلى الإجراء التالي. تنطبق هذه السلوكيات فقط على مهام سير العمل التابعة عديمة الحالة.
يحدد هذا الجدول سلوك سير العمل التابع استناداً إلى ما إذا كان الأصل والتابع ذوي حالة أو عديمي الحالة أو نوعين مختلطين من سير العمل. راجع القائمة بعد الجدول
| سير العمل الأصل | سير العمل التابع | سلوك التابع |
|---|---|---|
| ذو حالة | ذو حالة | غير متزامن أو متزامن مع إعداد "operationOptions": "DisableAsyncPattern" |
| ذو حالة | عديم الحالة | المشغّل والانتظار |
| عديم الحالة | ذو حالة | متزامن |
| عديم الحالة | عديم الحالة | المشغّل والانتظار |
إمكانات نموذج المستأجر الأحادي الأخرى
يتضمن نموذج المستأجر الفردي وتطبيق المنطق القياسي العديد من القدرات الحالية والجديدة، على سبيل المثال:
إنشاء تطبيقات منطقية وسير عملها من مئات الموصلات المُدارة لتطبيقات وخدمات البرامج كخدمة (SaaS) والنظام الأساسي كخدمة (PaaS) بالإضافة إلى موصلات للأنظمة المحلية.
تتوفر الآن المزيد من الموصلات المدارة كموصلات مضمنة في مهام سير العمل القياسية. تعمل الإصدارات المضمنة أصلاً في وقت تشغيل Azure Logic Apps للمستأجر الفردي. تعرف بعض الموصلات المضمنة أيضاً بشكل غير رسمي باسم موصلات موفر الخدمة. للحصول على قائمة، راجع الموصلات المضمنة في كلاً من الاستهلاك والقياسي.
يمكنك إنشاء الموصلات المضمنة المخصصة الخاصة بك لأي خدمة تحتاجها باستخدام إطار عمل Azure Logic Apps للمستأجر الفردي. على غرار الموصلات المضمنة مثل Azure Service Bus وSQL Server، توفر الموصلات المضمنة المخصصة معدل نقل أعلى وزمن انتقال منخفض واتصال محلي لأنها تعمل في نفس العملية مثل وقت تشغيل المستأجر الفردي. ومع ذلك، لا تشبه الموصلات المضمنة المخصصة الموصلات المدارة المخصصة، والتي لا يتم دعمها حالياً. لمزيد من المعلومات، راجع نظرة عامة على الموصل المخصص وأنشئ موصلات مضمنة مخصصة لتطبيقات المنطق القياسي في تطبيقات Azure Logic للمستأجر الفردي.
يمكنك استخدام الإجراءات التالية لعمليات Liquid وعمليات XML دون حساب تكامل. تتضمن هذه العمليات الإجراءات التالية:
XML: تحويل XML والتحقق من صحة XML
Liquid: تحويل JSON إلى JSON، وتحويل JSON إلى TEXT، وتحويل XML إلى JSON، وتحويل XML إلى Text
إشعار
لاستخدام هذه الإجراءات في مهام سير العمل القياسية، يجب أن يكون لديك مخططات Liquid أو مخططات XML أو مخططات XML. يمكنك تحميل هذه البيانات الاصطناعية في مدخل Microsoft Azure من قائمة موارد التطبيق المنطقي الخاص بك، ضمن "Artifacts"، والتي تتضمن الأقسام "Schemas" و"Maps". أو يمكنك إضافة هذه البيانات الاصطناعية إلى مجلد Artifacts لمشروع Visual Studio Code باستخدام مجلدات Maps وSchemas المعنيين. يمكنك بعد ذلك استخدام هذه البيانات الاصطناعية عبر مهام سير عمل متعددة داخل نفس تطبيق المنطق.
يمكن تشغيل مهام سير عمل تطبيق المنطق القياسي في أي مكان لأن Azure Logic Apps تنشئ توقيع الوصول المشترك (SAS) سلسلة الاتصال التي يمكن لتطبيقات المنطق هذه استخدامها لإرسال الطلبات إلى نقطة نهاية وقت تشغيل اتصال السحابة. يحفظ Azure Logic Apps هذه سلسلة الاتصال مع إعدادات التطبيق الأخرى بحيث يمكنك تخزين هذه القيم بسهولة في Azure Key Vault عند النشر في Azure.
تدعم مهام سير عمل تطبيق المنطق القياسي تمكين كل من الهوية المدارة المعينة من قبل النظام والهويات المدارة المتعددة المعينة من قبل المستخدم في نفس الوقت، على الرغم من أنه يمكنك تحديد هوية واحدة فقط لاستخدامها في كل مرة. بينما تدعم الموصلات المستندة إلى موفر الخدمة المضمنة باستخدام الهوية المعينة من قبل النظام، لا يدعم معظمها حاليا تحديد الهويات المدارة المعينة من قبل المستخدم للمصادقة، باستثناء SQL Server وموصلات HTTP.
إشعار
بشكل افتراضي، يتم تمكين الهوية التي يُعيّنها النظام بالفعل لمصادقة الاتصالات في وقت التشغيل. تختلف هذه الهوية عن بيانات اعتماد المصادقة أو سلسلة الاتصال التي تستخدمها عند إنشاء اتصال. إذا قمت بتعطيل هذه الهوية، فلن تعمل الاتصالات في وقت التشغيل. لعرض هذا الإعداد، في قائمة تطبيق المَنطق، ضمن الإعدادات، حدد الهوية.
يمكنك تشغيل التطبيقات المنطقية ومهام سير العمل الخاصة بها واختبارها وتصحيحها محلياً في بيئة تطوير Visual Studio Code.
قبل تشغيل تطبيق منطقي واختباره، يمكنك تسهيل تصحيح الأخطاء عن طريق إضافة نقاط التوقف واستخدامها داخل ملف workflow.json لسير عمل. ومع ذلك، يتم دعم نقاط التوقف فقط للإجراءات في هذا الوقت، وليس للمشغّلات. لمزيد من المعلومات، راجع إنشاء مهام سير عمل تستند إلى مستأجر أحادي في Visual Studio Code.
نشر التطبيقات المنطقية ومهام سير عملها مباشرة من Visual Studio Code إلى بيئات استضافة مختلفة مثل Azure وAzure Arc enabled Logic Apps.
تمكين إمكانات تسجيل التشخيص والتتبع لتطبيقك المنطقي باستخدام Insights التطبيق عند دعمه بواسطة اشتراك Azure وإعدادات التطبيق المنطقي.
الوصول إلى إمكانات الشبكات، مثل الاتصال والتكامل بشكل خاص مع شبكات Azure الظاهرية، على غرار Azure Functions عند إنشاء تطبيقات منطقية وتوزيعها باستخدام خطة Azure Functions Premium. لمعرفة مزيد من المعلومات، راجع الوثائق التالية:
إعادة إنشاء مفاتيح الوصول للاتصالات المدارة التي تستخدمها مهام سير العمل الفردية في تطبيق منطق قياسي . لهذه المهمة، اتبع نفس الخطوات لتطبيق منطق الاستهلاك ولكن على مستوى سير العمل، وليس مستوى مورد تطبيق المنطق.
الموصلات المضمنة لـ Standard
يمكن أن يستخدم سير العمل القياسي العديد من الموصلات المضمنة نفسها مثل سير عمل Consumption، ولكن ليس كلها. العكس، يحتوي سير العمل القياسي على العديد من الموصلات المضمنة غير المتوفرة في سير عمل Consumption.
على سبيل المثال، يحتوي سير العمل القياسي على موصلات مدارة وموصلات مضمنة ل Azure Blob وAzure Cosmos DB وAzure Event Hubs ناقل خدمة Azure وDB2 وFTP وMQ وSFTP وSQL Server وغيرها. على الرغم من أن سير عمل Consumption لا يحتوي على نفس إصدارات الموصل المضمنة، إلا أن الموصلات المضمنة الأخرى مثل Azure API Management وAzure App Services متوفرة.
في تطبيقات Azure Logic للمستأجر الفردي، تُعرف الموصلات المضمنة ذات السمات المحددة بشكل غير رسمي باسم موفري الخدمة. تدعم بعض الموصلات المُضمّنة طريقة واحدة فقط لمصادقة الاتصال بالخدمة الأساسية. يمكن أن توفر الموصلات المضمنة الأخرى خيارا، مثل استخدام سلسلة الاتصال أو معرف Microsoft Entra أو هوية مدارة. تعمل جميع الموصلات المضمنة في نفس العملية مثل وقت تشغيل Azure Logic Apps المعاد تصميمه. للمزيد من المعلومات، راجع قائمة الموصلات المضمنة لسير عمل تطبيق المنطق القياسي.
هام
تأكد من إعداد واختبار أي مشغل يستند إلى موفر الخدمة بشكل صحيح لتأكيد نجاح العملية. قد يؤدي المشغل الفاشل المستند إلى موفر الخدمة إلى إنشاء تحجيم غير ضروري، مما قد يؤدي إلى زيادة تكاليف الفوترة بشكل كبير. على سبيل المثال، خطأ شائع هو تعيين مشغل دون منح إذن تطبيق المنطق الخاص بك أو الوصول إلى الوجهة، مثل قائمة انتظار ناقل خدمة Microsoft Azure وحاوية كائن ثنائي كبير الحجم لتخزين Azure وما إلى ذلك. تأكد أيضا من مراقبة مثل هذه المشغلات في جميع الأوقات حتى تتمكن من الكشف عن أي مشكلات وإصلاحها على الفور.
الإمكانات المتغيرة أو المحدودة أو غير المتوفرة أو غير المدعومة
بالنسبة لسير عمل تطبيق المنطق القياسي ، تغيرت هذه القدرات، أو أنها محدودة حاليا أو غير متوفرة أو غير مدعومة:
المشغلات والإجراءات: يتم تشغيل المشغلات والإجراءات المضمنة محليا في Azure Logic Apps، بينما تتم استضافة الموصلات المدارة وتشغيلها باستخدام الموارد المشتركة في Azure. بالنسبة إلى مهام سير العمل القياسية، لا تتوفر بعض المشغلات والإجراءات المضمنة حاليا، مثل النافذة المنزلقة وخدمة تطبيقات Azure وإدارة واجهة برمجة تطبيقات Azure. لبدء سير عمل ذي حالة أو عديم الحالة، استخدم مشغلاً مضمناً مثل مشغل الطلب أو مراكز الأحداث أو ناقل خدمة Azure. لا يتوفر مشغّل Recurrence إلا لمهام سير العمل ذات الحالة، وليس لمهام سير العمل عديمة الحالة. في المصمم، تظهر المشغلات والإجراءات المضمنة مع تسمية In-App ، بينما تظهر مشغلات الموصل المدارة والإجراءات مع التسمية Shared .
يمكن أن تستخدم مهام سير العمل عديمة الحالة مشغلات الدفع فقط حيث لا تحدد جدولا للتشغيل لسير العمل الخاص بك. تنتظر هذه المشغلات المستندة إلى خطاف الويب حتى يحدث حدث أو تصبح البيانات متاحة. على سبيل المثال، يتوفر مشغل التكرار فقط لسير العمل ذي الحالة. لبدء سير العمل، حدد مشغل دفع مثل مشغل الطلب أو مراكز الأحداث أو ناقل خدمة Microsoft Azure. على الرغم من أنه يمكنك تمكين الموصلات المدارة لسير العمل عديم الحالة، إلا أن معرض الموصلات لا يعرض أي مشغلات استطلاع موصل مدارة لإضافتها.
إشعار
للتشغيل محلياً في Visual Studio Code، تتطلب المشغّلات والإجراءات المستندة إلى خطاف الويب إعداداً إضافياً. لمزيد من المعلومات، راجع إنشاء مهام سير عمل تستند إلى مستأجر أحادي في Visual Studio Code.
تم تغيير المشغلات والإجراءات التالية أو أنها محدودة حاليا أو غير مدعومة أو غير متوفرة:
الإجراء المضمن، Azure Functions - اختيار دالة Azure هو الآن Azure Functions Operations - استدعاء دالة Azure. يعمل هذا الإجراء حالياً فقط للدوال التي تم إنشاؤها من قالب HTTP Trigger.
في مدخل Microsoft Azure، يمكنك تحديد دالة مشغّل HTTP التي يمكنك الوصول إليها عن طريق إنشاء اتصال من خلال تجربة المستخدم. إذا قمت بفحص تعريف JSON الخاص بإجراء الدالة في طريقة عرض التعليمات البرمجية أو ملف workflow.json باستخدام Visual Studio Code، يشير الإجراء إلى الدالة باستخدام مرجع
connectionName. يلخص هذا الإصدار معلومات الدالة كاتصال، والتي يمكنك العثور عليها في ملف connections.json الخاص بمشروع تطبيقك المنطقي، والذي يتوفر بعد إنشاء اتصال في Visual Studio Code.إشعار
في نموذج أحادي المستأجر، يدعم إجراء الدالة مصادقة سلسلة الاستعلام فقط. يحصل Azure Logic Apps على المفتاح الافتراضي من الدالة عند إجراء الاتصال، ويخزن هذا المفتاح في إعدادات التطبيق، ويستخدم المفتاح للمصادقة عند استدعاء الدالة.
كما هو الحال في النموذج متعدد المستأجرين، إذا قمت بتجديد هذا المفتاح، على سبيل المثال، من خلال تجربة Azure Functions في المدخل، فلن يعمل إجراء الدالة بسبب المفتاح غير الصالح. لإصلاح هذه المشكلة، تحتاج إلى إعادة إنشاء الاتصال بالدالة التي تريد استدعائها أو تحديث إعدادات التطبيق بالمفتاح الجديد.
الإجراء المُضمّن، Inline Code، تمت إعادة تسميته Inline Code Operations، ولم يعد يتطلب حساب تكامل، ولديه حدود محدثة.
الإجراء المُضمّن، Azure Logic Apps - اختيار سير عمل Logic App هو الآن Workflow Operations - استدعاء سير عمل في تطبيق سير العمل هذا.
موصل Gmail غير مدعوم حالياً.
الموصلات المُدارة المخصصة غير مدعومة حالياً. ومع ذلك، يمكنك إنشاء عمليات مضمّنة مخصصة عند استخدام Visual Studio Code. لمزيد من المعلومات، راجع إنشاء مهام سير عمل تستند إلى مستأجر أحادي باستخدام Visual Studio Code.
يمكن أن يحتوي سير عمل تطبيق المنطق القياسي على مشغل واحد فقط ولا يدعم مشغلات متعددة.
المصادقة: أنواع المصادقة التالية غير متوفرة حاليا لسير العمل القياسي :
Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) للمكالمات الواردة إلى المشغلات المستندة إلى الطلب، مثل مشغل الطلب ومشغل HTTP Webhook.
مصادقة الهوية المدارة: يتوفر دعم الهوية المدارة المعين من قبل النظام والمخصص من قبل المستخدم. بشكل افتراضي، يتم تمكين الهوية المدارة المعينة من قبل النظام تلقائيا. ومع ذلك، لا تدعم معظم الموصلات المضمنة والمستندة إلى موفر الخدمة حاليا تحديد الهويات المدارة المعينة من قبل المستخدم للمصادقة.
تحويل XML: XSLT 1.0 فقط مدعوم حاليا.
تصحيح أخطاء نقطة التوقف في Visual Studio Code: على الرغم من أنه يمكنك إضافة نقاط التوقف واستخدامها داخل ملف workflow.json لسير العمل، إلا إن نقاط التوقف مدعومة فقط للإجراءات في هذا الوقت، وليس للمشغّلات. لمزيد من المعلومات، راجع إنشاء مهام سير عمل تستند إلى مستأجر أحادي في Visual Studio Code.
محفوظات المشغل ومحفوظات التشغيل: بالنسبة لتطبيق المنطق القياسي ، تظهر محفوظات المشغل ومحفوظات التشغيل في مدخل Microsoft Azure على مستوى سير العمل، وليس مستوى مورد تطبيق المنطق. لمزيد من المعلومات، راجع إنشاء مهام سير عمل تستند إلى مستأجر أحادي باستخدام مدخل Microsoft Azure.
النسخ الاحتياطي والاستعادة لمحفوظات تشغيل سير العمل: لا تدعم تطبيقات المنطق القياسية حاليا النسخ الاحتياطي والاستعادة لمحفوظات تشغيل سير العمل.
قوالب Terraform: لا يمكنك استخدام هذه القوالب مع مورد تطبيق منطقي قياسي لنشر البنية الأساسية بالكامل. لمزيد من المعلومات، راجع ما هو Terraform على Azure؟
Azure API Management: لا يمكنك حاليا استيراد مورد تطبيق منطقي قياسي إلى Azure API Management. ومع ذلك، يمكنك استيراد مورد تطبيق منطق الاستهلاك .
أذونات صارمة لنسبة استخدام الشبكة وجدار الحماية
إذا كانت بيئتك تحتوي على متطلبات شبكة أو جدران حماية صارمة تحد من نسبة استخدام الشبكة، يجب عليك السماح بالوصول إلى أي اتصالات مشغّل أو إجراءات في مهام سير العمل الخاصة بك. يمكنك اختيارياً السماح بنسبة استخدام الشبكة من علامات الخدمة واستخدام نفس مستوى القيود أو النُهج مثل Azure App Service. تحتاج أيضاً إلى البحث عن أسماء المجالات المؤهلة بالكامل (FQDNs) واستخدامها للاتصالات الخاصة بك. لمزيد من المعلومات، راجع الأقسام المقابلة في الوثائق التالية:
- أذونات جدار الحماية للتطبيقات المنطقية أحادية المستأجر - مدخل Microsoft Azure
- أذونات جدار الحماية للتطبيقات المنطقية أحادية المستأجر - Visual Studio Code
الخطوات التالية
- إنشاء مهام سير عمل تستند إلى مستأجر أحادي في مدخل Microsoft Azure
- إنشاء مهام سير عمل تستند إلى مستأجر أحادي في Visual Studio Code
نود أيضاً أن نسمع عن تجاربك مع Azure Logic Apps أحادية المستأجر!
- بالنسبة للأخطاء أو المشكلات، قم بإنشاء مشكلاتك في GitHub.
- بالنسبة للأسئلة والطلبات والتعليقات والملاحظات الأخرى، استخدم نموذج الملاحظات هذا.