الدليل المرجعي للمخطط لأنواع المشغلات والإجراءات في Azure Logic Apps
يصف هذا المرجع الأنواع العامة المستخدمة لتحديد المشغلات والإجراءات في تعريف سير العمل الأساسي لتطبيقك المنطقي، والذي تم وصفه والتحقق من صحته بواسطة لغة تعريف سير العمل. للعثور على مشغلات وإجراءات محددة للموصل يمكنك استخدامها في تطبيقاتك المنطقية، راجع القائمة الموجودة ضمن نظرة عامة على الموصلات.
نظرة عامة على المشغلات
يتضمن كل سير عمل مشغلاً، يحدد المكالمات التي تنشئ وتبدأ سير العمل. فيما يلي فئات المشغل العامة:
مشغل الاستقصاء، والذي يتحقق من نقطة نهاية الخدمة على فترات منتظمة
مشغل الدفع، والذي ينشئ اشتراكاً في نقطة نهاية ويوفر عنوان URL لمعاودة الاتصال بحيث يمكن لنقطة النهاية إخطار المشغل عند حدوث الحدث المحدد أو توفر البيانات. ثم ينتظر المشغل استجابة نقطة النهاية قبل الإطلاق.
تحتوي المشغلات على عناصر المستوى الأعلى هذه، رغم أن بعضها اختياري:
"<trigger-name>": {
"type": "<trigger-type>",
"inputs": { "<trigger-inputs>" },
"recurrence": {
"frequency": "<time-unit>",
"interval": <number-of-time-units>
},
"conditions": [ "<array-with-conditions>" ],
"runtimeConfiguration": { "<runtime-config-options>" },
"splitOn": "<splitOn-expression>",
"operationOptions": "<operation-option>"
},
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<trigger-name> | السلسلة | اسم المشغل |
<trigger-type> | السلسلة | نوع المشغل مثل "Http" أو "ApiConnection" |
<trigger-inputs> | كائن JSON | المدخلات التي تحدد سلوك المشغل |
<time-unit> | السلسلة | وحدة الوقت التي تصف عدد مرات إطلاق المشغل: "الثانية"، "الدقيقة"، "الساعة"، "اليوم"، "الأسبوع"، "الشهر" |
<عدد الوحدات الزمنية> | رقم صحيح | قيمة تحدد عدد مرات تشغيل المشغل استنادا إلى التردد، وهو عدد الوحدات الزمنية التي يجب انتظارها حتى يتم تشغيل المشغل مرة أخرى فيما يلي الحد الأدنى والحد الأقصى للفواصل الزمنية: - الشهر: 1-16 شهراً - اليوم: 1-500 يوم - الساعة: 1-12،000 ساعة - الدقيقة: 1-72،000 دقيقة - الثانية: 1-9،999،999 ثانية على سبيل المثال، إذا كان الفاصل الزمني هو 6، وكان التكرار "شهر"، يكون التكرار كل 6 أشهر. |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<array-with-conditions> | صفيف | صفيف يحتوي على واحد أو أكثر من الشروط التي تحدد ما إذا كان سيتم تشغيل سير العمل أم لا. متاح فقط للمشغلات. |
<خيارات تهيئة وقت التشغيل> | كائن JSON | يمكنك تغيير سلوك وقت التشغيل عن طريق تعيين خصائص runtimeConfiguration . لمزيد من المعلومات، راجع إعدادات تكوين وقت التشغيل. |
<splitOn-expression> | السلسلة | بالنسبة للمشغلات التي ترجع صفيفاً، يمكنك تحديد تعبير يقوم بتقسيم عناصر الصفيف أو تصحيحها إلى مثيلات سير عمل متعددة للمعالجة. |
<operation-option> | السلسلة | يمكنك تغيير السلوك الافتراضي عن طريق تعيين خاصية operationOptions . لمزيد من المعلومات، راجع خيارات العملية. |
قائمة أنواع الزناد
يحتوي كل نوع من أنواع المشغل على واجهة ومدخلات مختلفة تحدد سلوك المشغل.
مشغلات مدمجة
نوع الزناد | الوصف |
---|---|
HTTP | يتحقق أو يستقصي أي نقطة نهاية. يجب أن تتوافق نقطة النهاية هذه مع عقد بدء محدد إما باستخدام 202 نمط غير متزامن أو عن طريق إرجاع صفيف. |
HTTPWebhook | ينشئ نقطة نهاية قابلة للاستدعاء للتطبيق المنطقي الخاص بك ولكنه يستدعي عنوان URL المحدد للتسجيل أو إلغاء التسجيل. |
تكرار | الحرائق على أساس جدول زمني محدد. يمكنك تعيين التاريخ والوقت المستقبليين لإطلاق هذا المشغل. بناءً على التكرار، يمكنك أيضاً تحديد الأوقات والأيام لتشغيل سير العمل الخاص بك. |
Request | ينشئ نقطة نهاية قابلة للاستدعاء لتطبيقك المنطقي وتُعرف أيضاً باسم المشغل "اليدوي". على سبيل المثال، راجع استدعاء مهام سير العمل أو تشغيلها أو تداخلها باستخدام نقاط نهاية HTTP. |
مشغلات API المُدارة
نوع الزناد | الوصف |
---|---|
ApiConnection | التحقق من نقطة نهاية أو استقصاءها باستخدام واجهات برمجة التطبيقات التي تديرها Microsoft أو "الموصلات". |
ApiConnectionWebhook | إنشاء نقطة نهاية قابلة للاستدعاء لسير عمل تطبيق المنطق الخاص بك عن طريق استدعاء واجهات برمجة التطبيقات المدارة من قبل Microsoft أو "الموصلات" للاشتراك وإلغاء الاشتراك. |
المشغلات - مرجع مفصل
مشغل APIConnection
يتحقق هذا المشغل أو يستقصي نقطة نهاية باستخدام واجهات برمجة التطبيقات أو "الموصلات" المدارة من قبل Microsoft بحيث يمكن أن تختلف معلمات هذا المشغل استنادا إلى نقطة النهاية. العديد من الأقسام في تعريف المشغل هذا اختيارية. يعتمد سلوك المشغل على ما إذا كان قد تم تضمين الأقسام أم لا.
"<APIConnection_trigger_name>": {
"type": "ApiConnection",
"inputs": {
"host": {
"connection": {
"name": "@parameters('$connections')['<connection-name>']['connectionId']"
}
},
"method": "<method-type>",
"path": "/<api-operation>",
"retryPolicy": { "<retry-behavior>" },
"queries": { "<query-parameters>" }
},
"recurrence": {
"frequency": "<time-unit>",
"interval": <number-of-time-units>
},
"runtimeConfiguration": {
"concurrency": {
"runs": <max-runs>,
"maximumWaitingRuns": <max-runs-queue>
}
},
"splitOn": "<splitOn-expression>",
"operationOptions": "<operation-option>"
}
مطلوب
الخاصية | القيمة | النوع | الوصف |
---|---|---|---|
بلا | <APIConnection_trigger_name> | السلسلة | اسم المشغل |
host.connection.name | <اسم الاتصال> | السلسلة | اسم الاتصال بواجهة برمجة التطبيقات المُدارة التي يستخدمها سير العمل |
أسلوب | <method-type> | السلسلة | أسلوب HTTP للتواصل مع واجهة برمجة التطبيقات المدارة: GET، PUT، POST، PATCH، DELETE |
المسار | <عملية واجهة برمجة التطبيقات> | السلسلة | عملية API للاتصال |
recurrence.frequency | <time-unit> | السلسلة | وحدة الوقت التي تصف عدد مرات تشغيل المشغل: الثانية، الدقيقة، الساعة، اليوم، الأسبوع، الشهر |
التكرار.الفاصل الزمني | <عدد الوحدات الزمنية> | رقم صحيح | قيمة تحدد عدد مرات تشغيل المشغل استنادا إلى التردد، وهو عدد الوحدات الزمنية التي يجب انتظارها حتى يتم تشغيل المشغل مرة أخرى فيما يلي الحد الأدنى والحد الأقصى للفواصل الزمنية: - الشهر: 1-16 شهرا - اليوم: 1-500 يوم - الساعة: 1-12,000 ساعة - دقيقة: 1-72000 دقيقة - الثانية: 1-9999999 ثانية على سبيل المثال، إذا كان الفاصل الزمني هو 6، وكان التكرار شهر، فإن التكرار يكون كل 6 أشهر. |
اختياري
الخاصية | القيمة | النوع | الوصف |
---|---|---|---|
سياسة إعادة المحاولة | <إعادة المحاولة> | كائن JSON | يخصص سلوك إعادة المحاولة للفشل المتقطع، والذي يحتوي على تعليمة برمجية الحالة 408، و429، و5XX، وأي استثناءات تتعلق بالاتصال. لمزيد من المعلومات، راجع نُهج إعادة المحاولة. |
الاستعلامات | <معامِلات طلب البحث> | كائن JSON | أي معلمات استعلام لتضمينها مع استدعاء API. على سبيل المثال، يضيف العنصر "queries": { "api-version": "2018-01-01" } ?api-version=2018-01-01 إلى المكالمة. |
runtimeConfiguration.concurrency.runs | <الحد الأقصى للتشغيل> | رقم صحيح | بشكل افتراضي، يتم تشغيل مثيلات سير العمل في نفس الوقت (بشكل متزامن أو بشكل متواز) حتى الحد الافتراضي. لتغيير هذا الحد عن طريق تعيين قيمة <عدد> جديدة، راجع تغيير التزامن المشغل. |
runtimeConfiguration.maximumWaitingRuns | <max-runs-queue> | رقم صحيح | إذا كان سير العمل الخاص بك يشغل بالفعل الحد الأقصى لعدد المثيلات، يتم وضع أي عمليات تشغيل جديدة في قائمة الانتظار هذه حتى الحد الافتراضي. لتغيير الحد الافتراضي، راجع تغيير حد فترات الانتظار. لتغيير الحد الأقصى لعدد المثيلات، حدد قيمة للخاصية runtimeConfiguration.concurrency.runs . ملاحظة: إذا قمت بتعيين |
splitOn | <splitOn-expression> | السلسلة | بالنسبة للمشغلات التي ترجع الصفائف، يشير هذا التعبير إلى الصفيف المراد استخدامها بحيث يمكنك إنشاء مثيل سير عمل وتشغيله لكل عنصر صفيف، بدلاً من استخدام "لكل" حلقة. على سبيل المثال، يمثل هذا التعبير عنصراً في الصفيف يتم إرجاعه داخل محتوى نص المشغل: @triggerbody()?['value'] |
عمليات التشغيل | <operation-option> | السلسلة | يمكنك تغيير السلوك الافتراضي عن طريق تعيين خاصية operationOptions . لمزيد من المعلومات، راجع خيارات العملية. |
النواتج
العنصر | النوع | الوصف |
---|---|---|
العناوين | كائن JSON | رؤوس من الرد |
النص الأساسي | كائن JSON | الجسد من الاستجابة |
رمز الحالة | رقم صحيح | تعليمة برمجية الحالة من الرد |
مثال
يتحقق تعريف المشغل هذا من البريد الإلكتروني كل يوم داخل البريد الوارد لحساب العمل أو المدرسة:
"When_a_new_email_arrives": {
"type": "ApiConnection",
"inputs": {
"host": {
"connection": {
"name": "@parameters('$connections')['office365']['connectionId']"
}
},
"method": "get",
"path": "/Mail/OnNewEmail",
"queries": {
"fetchOnlyWithAttachment": false,
"folderPath": "Inbox",
"importance": "Any",
"includeAttachments": false
}
},
"recurrence": {
"frequency": "Day",
"interval": 1
}
}
ApiConnectionWebhook trigger
يرسل هذا المشغل طلب اشتراك إلى نقطة نهاية باستخدام واجهة برمجة تطبيقات تديرها Microsoft، ويوفر عنوان URL لمعاودة الاتصال حيث يمكن لنقطة النهاية إرسال استجابة، وتنتظر استجابة نقطة النهاية. لمزيد من المعلومات، راجع اشتراكات نقطة النهاية.
"<ApiConnectionWebhook_trigger_name>": {
"type": "ApiConnectionWebhook",
"inputs": {
"body": {
"NotificationUrl": "@{listCallbackUrl()}"
},
"host": {
"connection": {
"name": "@parameters('$connections')['<connection-name>']['connectionId']"
}
},
"retryPolicy": { "<retry-behavior>" },
"queries": "<query-parameters>"
},
"runTimeConfiguration": {
"concurrency": {
"runs": <max-runs>,
"maximumWaitingRuns": <max-run-queue>
}
},
"splitOn": "<splitOn-expression>",
"operationOptions": "<operation-option>"
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<اسم الاتصال> | السلسلة | اسم الاتصال بواجهة برمجة التطبيقات المُدارة التي يستخدمها سير العمل |
<محتوى الجسم> | كائن JSON | أي محتوى رسالة لإرساله كحمولة إلى واجهة برمجة التطبيقات المُدارة |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<إعادة المحاولة> | كائن JSON | يخصص سلوك إعادة المحاولة للفشل المتقطع، والذي يحتوي على تعليمة برمجية الحالة 408، و429، و5XX، وأي استثناءات تتعلق بالاتصال. لمزيد من المعلومات، راجع نُهج إعادة المحاولة. |
<معامِلات طلب البحث> | كائن JSON | أي معلمات استعلام لتضمينها مع استدعاء واجهة برمجة التطبيقات على سبيل المثال، يضيف العنصر "queries": { "api-version": "2018-01-01" } ?api-version=2018-01-01 إلى المكالمة. |
<الحد الأقصى للتشغيل> | رقم صحيح | بشكل افتراضي، يتم تشغيل مثيلات سير العمل في نفس الوقت (بشكل متزامن أو بشكل متواز) حتى الحد الافتراضي. لتغيير هذا الحد عن طريق تعيين قيمة <عدد> جديدة، راجع تغيير التزامن المشغل. |
<max-runs-queue> | رقم صحيح | عندما يقوم سير العمل بالفعل بتشغيل الحد الأقصى لعدد المثيلات، والتي يمكنك تغييرها بناءً على خاصية runtimeConfiguration.concurrency.runs ، يتم وضع أي عمليات تشغيل جديدة في قائمة الانتظار هذه حتى الحد الافتراضي. لتغيير الحد الافتراضي، راجع تغيير حد فترات الانتظار. |
<splitOn-expression> | السلسلة | بالنسبة للمشغلات التي ترجع الصفائف، يشير هذا التعبير إلى الصفيف المراد استخدامها بحيث يمكنك إنشاء مثيل سير عمل وتشغيله لكل عنصر صفيف، بدلاً من استخدام "لكل" حلقة. على سبيل المثال، يمثل هذا التعبير عنصراً في الصفيف يتم إرجاعه داخل محتوى نص المشغل: @triggerbody()?['value'] |
<operation-option> | السلسلة | يمكنك تغيير السلوك الافتراضي عن طريق تعيين خاصية operationOptions . لمزيد من المعلومات، راجع خيارات العملية. |
مثال
يشترك تعريف المشغل هذا في Office 365 Outlook API، ويوفر عنوان URL لرد الاتصال لنقطة نهاية API، وينتظر استجابة نقطة النهاية عند وصول بريد إلكتروني جديد.
"When_a_new_email_arrives_(webhook)": {
"type": "ApiConnectionWebhook",
"inputs": {
"body": {
"NotificationUrl": "@{listCallbackUrl()}"
},
"host": {
"connection": {
"name": "@parameters('$connections')['office365']['connectionId']"
}
},
"path": "/MailSubscription/$subscriptions",
"queries": {
"folderPath": "Inbox",
"hasAttachment": "Any",
"importance": "Any"
}
},
"splitOn": "@triggerBody()?['value']"
}
مشغل HTTP
يرسل هذا المشغل طلباً إلى نقطة نهاية HTTP أو HTTPS المحددة بناءً على جدول التكرار المحدد. ثم يتحقق المشغل من الاستجابة لتحديد ما إذا كان سير العمل يعمل أم لا. لمزيد من المعلومات، راجع الاتصال بنقاط نهاية الخدمة عبر HTTP أو HTTPS من Azure Logic Apps.
"HTTP": {
"type": "Http",
"inputs": {
"method": "<method-type>",
"uri": "<HTTP-or-HTTPS-endpoint-URL>",
"headers": { "<header-content>" },
"queries": "<query-parameters>",
"body": "<body-content>",
"authentication": { "<authentication-type-and-property-values>" },
"retryPolicy": {
"type": "<retry-behavior>"
}
},
"recurrence": {
"frequency": "<time-unit>",
"interval": <number-of-time-units>
},
"runtimeConfiguration": {
"concurrency": {
"runs": <max-runs>,
"maximumWaitingRuns": <max-runs-queue>
}
},
"operationOptions": "<operation-option>"
}
مطلوب
الخاصية | القيمة | النوع | الوصف |
---|---|---|---|
method |
<method-type> | السلسلة | الطريقة المستخدمة لإرسال الطلب الصادر: "GET" أو "PUT" أو "POST" أو "PATCH" أو "DELETE" |
uri |
<عنوان URL لنقطة نهاية HTTP أو HTTPS> | السلسلة | عنوان URL لنقطة نهاية HTTP أو HTTPS حيث تريد إرسال الطلب الصادر. الحد الأقصى لحجم السلسلة: 2 كيلوبايت بالنسبة إلى مورد أو خدمة Azure، يتضمن بناء جملة URI هذا معرف المورد والمسار إلى المورد الذي تريد الوصول إليه. |
frequency |
<time-unit> | السلسلة | وحدة الوقت التي تصف عدد مرات إطلاق المشغل: "الثانية"، "الدقيقة"، "الساعة"، "اليوم"، "الأسبوع"، "الشهر" |
interval |
<عدد الوحدات الزمنية> | رقم صحيح | قيمة تحدد عدد مرات تشغيل المشغل استنادا إلى التردد، وهو عدد الوحدات الزمنية التي يجب انتظارها حتى يتم تشغيل المشغل مرة أخرى فيما يلي الحد الأدنى والحد الأقصى للفواصل الزمنية: - الشهر: 1-16 شهراً - اليوم: 1-500 يوم - الساعة: 1-12،000 ساعة - الدقيقة: 1-72،000 دقيقة - الثانية: 1-9،999،999 ثانية على سبيل المثال، إذا كان الفاصل الزمني هو 6، وكان التكرار "شهر"، يكون التكرار كل 6 أشهر. |
اختياري
الخاصية | القيمة | النوع | الوصف |
---|---|---|---|
headers |
<header-content> | كائن JSON | أي رؤوس تحتاج إلى تضمينها مع الطلب على سبيل المثال، لتعيين اللغة والنوع: "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" } |
queries |
<معامِلات طلب البحث> | كائن JSON | أي معلمات استعلام تحتاج إلى استخدامها في الطلب على سبيل المثال، يضيف العنصر "queries": { "api-version": "2018-01-01" } ?api-version=2018-01-01 إلى الطلب. |
body |
<محتوى الجسم> | كائن JSON | محتوى الرسالة المراد إرسالها كحمولة مع الطلب |
authentication |
<نوع المصادقة وقيم الخاصية> | كائن JSON | نموذج المصادقة الذي يستخدمه الطلب لمصادقة الطلبات الصادرة. لمزيد من المعلومات، راجع إضافة مصادقة للمكالمات الصادرة. بعد برنامج الجدولة، يتم دعم خاصية authority . في حالة عدم تحديدها، تكون القيمة الافتراضية هي https://management.azure.com/ ، ولكن يمكنك استخدام قيمة مختلفة. |
retryPolicy > type |
<إعادة المحاولة> | كائن JSON | يخصص سلوك إعادة المحاولة للفشل المتقطع، والذي يحتوي على تعليمة برمجية الحالة 408، و429، و5XX، وأي استثناءات تتعلق بالاتصال. لمزيد من المعلومات، راجع نُهج إعادة المحاولة. |
runs |
<الحد الأقصى للتشغيل> | رقم صحيح | بشكل افتراضي، يتم تشغيل مثيلات سير العمل في نفس الوقت (بشكل متزامن أو بشكل متواز) حتى الحد الافتراضي. لتغيير هذا الحد عن طريق تعيين قيمة <عدد> جديدة، راجع تغيير التزامن المشغل. |
maximumWaitingRuns |
<max-runs-queue> | رقم صحيح | عندما يقوم سير العمل بالفعل بتشغيل الحد الأقصى لعدد المثيلات، والتي يمكنك تغييرها بناءً على خاصية runtimeConfiguration.concurrency.runs ، يتم وضع أي عمليات تشغيل جديدة في قائمة الانتظار هذه حتى الحد الافتراضي. لتغيير الحد الافتراضي، راجع تغيير حد فترات الانتظار. |
operationOptions |
<operation-option> | السلسلة | يمكنك تغيير السلوك الافتراضي عن طريق تعيين خاصية operationOptions . لمزيد من المعلومات، راجع خيارات العملية. |
النواتج
العنصر | النوع | الوصف |
---|---|---|
headers |
كائن JSON | رؤوس من الرد |
body |
كائن JSON | الجسد من الاستجابة |
status code |
رقم صحيح | تعليمة برمجية الحالة من الرد |
متطلبات الطلبات الواردة
للعمل بشكل جيد مع تطبيقك المنطقي، يجب أن تتوافق نقطة النهاية مع نمط أو عقد تشغيل محدد، وأن تتعرف على خصائص الاستجابة هذه:
الخاصية | المطلوب | الوصف |
---|---|---|
كود الحالة | نعم | يبدأ تعليمة برمجية الحالة "200 OK" تشغيل. أي رمز حالة آخر لا يبدأ تشغيل. |
إعادة المحاولة بعد العنوان | لا | عدد الثواني حتى يستقصي تطبيقك المنطقي نقطة النهاية مرة أخرى |
رأس الموقع | لا | عنوان URL المطلوب الاتصال به في فترة الاقتراع التالية. إذا لم يتم تحديده، فسيتم استخدام عنوان URL الأصلي. |
أمثلة سلوكيات لطلبات مختلفة
كود الحالة | أعد المحاولة بعد | سلوك |
---|---|---|
200 | {none} | قم بتشغيل سير العمل، ثم تحقق مرة أخرى للحصول على مزيد من البيانات بعد التكرار المحدد. |
200 | 10 ثوان | قم بتشغيل سير العمل، ثم تحقق مرة أخرى للحصول على مزيد من البيانات بعد 10 ثوانٍ. |
202 | 60 ثانية | لا تقم بتشغيل سير العمل. المحاولة التالية تحدث في دقيقة واحدة، مع مراعاة التكرار المحدد. إذا كان التكرار المحدد أقل من دقيقة واحدة، فستكون الأولوية لرأس إعادة المحاولة. خلاف ذلك، يتم استخدام التكرار المحدد. |
400 | {none} | طلب غير صالح، لا تقم بتشغيل سير العمل. إذا لم يتم تحديد retryPolicy ، فسيتم استخدام النهج الافتراضية. بعد الوصول إلى عدد مرات إعادة المحاولة، يتحقق المشغل مرة أخرى من البيانات بعد التكرار المحدد. |
500 | {none} | خطأ في الخادم، لا تقم بتشغيل سير العمل. إذا لم يتم تحديد retryPolicy ، فسيتم استخدام النهج الافتراضية. بعد الوصول إلى عدد مرات إعادة المحاولة، يتحقق المشغل مرة أخرى من البيانات بعد التكرار المحدد. |
مشغل HTTPWebhook
يجعل هذا المشغل تطبيقك المنطقي قابلاً للاستدعاء عن طريق إنشاء نقطة نهاية يمكنها تسجيل اشتراك عن طريق الاتصال بعنوان URL لنقطة النهاية المحددة. عند إنشاء هذا المشغل في سير العمل الخاص بك، يقوم الطلب الصادر بإجراء المكالمة لتسجيل الاشتراك. بهذه الطريقة، يمكن أن يبدأ المشغل في الاستماع إلى الأحداث. عندما تجعل إحدى العمليات هذا المشغل غير صالح، يقوم الطلب الصادر تلقائياً بإجراء المكالمة لإلغاء الاشتراك. لمزيد من المعلومات، راجع اشتراكات نقطة النهاية.
يمكنك أيضاً تحديد حدود غير متزامنة على مشغل HTTPWebhook. يعتمد سلوك المشغل على الأقسام التي تستخدمها أو تحذفها.
"HTTP_Webhook": {
"type": "HttpWebhook",
"inputs": {
"subscribe": {
"method": "<method-type>",
"uri": "<endpoint-subscribe-URL>",
"headers": { "<header-content>" },
"body": "<body-content>",
"authentication": { "<authentication-type>" },
"retryPolicy": { "<retry-behavior>" }
},
"unsubscribe": {
"method": "<method-type>",
"url": "<endpoint-unsubscribe-URL>",
"headers": { "<header-content>" },
"body": "<body-content>",
"authentication": { "<authentication-type>" }
}
},
"runTimeConfiguration": {
"concurrency": {
"runs": <max-runs>,
"maximumWaitingRuns": <max-runs-queue>
}
},
"operationOptions": "<operation-option>"
}
تتوفر بعض القيم، مثل <نوع الأسلوب>، لكل من عنصرين "subscribe"
و"unsubscribe"
.
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<method-type> | السلسلة | طريقة HTTP المستخدمة في طلب الاشتراك: "GET" أو "PUT" أو "POST" أو "PATCH" أو "DELETE" |
<عنوان URL للاشتراك لنقطة النهاية> | السلسلة | عنوان URL لنقطة النهاية حيث يتم إرسال طلب الاشتراك |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<method-type> | السلسلة | طريقة HTTP المستخدمة في طلب الإلغاء: "GET" أو "PUT" أو "POST" أو "PATCH" أو "DELETE" |
<عنوان URL لنقطة النهاية-إلغاء الاشتراك> | السلسلة | عنوان URL لنقطة النهاية حيث يتم إرسال طلب الإلغاء |
<محتوى الجسم> | السلسلة | أي محتوى رسالة لإرساله في طلب الاشتراك أو الإلغاء |
<نوع المصادقة> | كائن JSON | نموذج المصادقة الذي يستخدمه الطلب لمصادقة الطلبات الصادرة. لمزيد من المعلومات، راجع إضافة مصادقة للمكالمات الصادرة. |
<إعادة المحاولة> | كائن JSON | يخصص سلوك إعادة المحاولة للفشل المتقطع، والذي يحتوي على تعليمة برمجية الحالة 408، و429، و5XX، وأي استثناءات تتعلق بالاتصال. لمزيد من المعلومات، راجع نُهج إعادة المحاولة. |
<الحد الأقصى للتشغيل> | رقم صحيح | بشكل افتراضي، تعمل جميع مثيلات سير العمل في نفس الوقت (بشكل متزامن أو بالتوازي) حتى الحد الافتراضي. لتغيير هذا الحد عن طريق تعيين قيمة <عدد> جديدة، راجع تغيير التزامن المشغل. |
<max-runs-queue> | رقم صحيح | عندما يقوم سير العمل بالفعل بتشغيل الحد الأقصى لعدد المثيلات، والتي يمكنك تغييرها بناءً على خاصية runtimeConfiguration.concurrency.runs ، يتم وضع أي عمليات تشغيل جديدة في قائمة الانتظار هذه حتى الحد الافتراضي. لتغيير الحد الافتراضي، راجع تغيير حد فترات الانتظار. |
<operation-option> | السلسلة | يمكنك تغيير السلوك الافتراضي عن طريق تعيين خاصية operationOptions . لمزيد من المعلومات، راجع خيارات العملية. |
النواتج
العنصر | النوع | الوصف |
---|---|---|
رؤوس | كائن JSON | رؤوس من الرد |
النص الأساسي | كائن JSON | الجسد من الاستجابة |
تعليمة برمجية الحالة | رقم صحيح | تعليمة برمجية الحالة من الرد |
مثال
ينشئ هذا المشغل اشتراكاً في نقطة النهاية المحددة، ويوفر عنوان URL فريداً لمعاودة الاتصال، وينتظر مقالات التكنولوجيا المنشورة حديثاً.
"HTTP_Webhook": {
"type": "HttpWebhook",
"inputs": {
"subscribe": {
"method": "POST",
"uri": "https://pubsubhubbub.appspot.com/subscribe",
"body": {
"hub.callback": "@{listCallbackUrl()}",
"hub.mode": "subscribe",
"hub.topic": "https://pubsubhubbub.appspot.com/articleCategories/technology"
},
},
"unsubscribe": {
"method": "POST",
"url": "https://pubsubhubbub.appspot.com/subscribe",
"body": {
"hub.callback": "@{workflow().endpoint}@{listCallbackUrl()}",
"hub.mode": "unsubscribe",
"hub.topic": "https://pubsubhubbub.appspot.com/articleCategories/technology"
}
}
}
}
مشغل التكرار
يتم تشغيل هذا المشغل بناءً على جدول التكرار المحدد ويوفر طريقة سهلة لإنشاء سير عمل قيد التشغيل بانتظام.
"Recurrence": {
"type": "Recurrence",
"recurrence": {
"frequency": "<time-unit>",
"interval": <number-of-time-units>,
"startTime": "<start-date-time-with-format-YYYY-MM-DDThh:mm:ss>",
"timeZone": "<time-zone>",
"schedule": {
// Applies only when frequency is Day or Week. Separate values with commas.
"hours": [ <one-or-more-hour-marks> ],
// Applies only when frequency is Day or Week. Separate values with commas.
"minutes": [ <one-or-more-minute-marks> ],
// Applies only when frequency is Week. Separate values with commas.
"weekDays": [ "Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday" ]
}
},
"runtimeConfiguration": {
"concurrency": {
"runs": <max-runs>,
"maximumWaitingRuns": <max-runs-queue>
}
},
"operationOptions": "<operation-option>"
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<time-unit> | السلسلة | وحدة الوقت التي تصف عدد مرات إطلاق المشغل: "الثانية"، "الدقيقة"، "الساعة"، "اليوم"، "الأسبوع"، "الشهر" |
<عدد الوحدات الزمنية> | رقم صحيح | قيمة تحدد عدد مرات تشغيل المشغل استنادا إلى التردد، وهو عدد الوحدات الزمنية التي يجب انتظارها حتى يتم تشغيل المشغل مرة أخرى فيما يلي الحد الأدنى والحد الأقصى للفواصل الزمنية: - الشهر: 1-16 شهراً - اليوم: 1-500 يوم - الساعة: 1-12،000 ساعة - الدقيقة: 1-72،000 دقيقة - الثانية: 1-9،999،999 ثانية على سبيل المثال، إذا كان الفاصل الزمني هو 6، وكان التكرار "شهر"، يكون التكرار كل 6 أشهر. |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<start-date-time-with-format-YYYY-MM-DDThh:mm:ss> | السلسلة | تاريخ البدء ووقته بهذا التنسيق: YYYY-MM-DDThh:mm:ss إذا قمت بتحديد منطقة زمنية -او- YYYY-MM-DDThh:mm:ssZ إذا لم تحدد منطقة زمنية لذلك على سبيل المثال، إذا كنت تريد 18 سبتمبر 2017 الساعة 2:00 مساءً، فحدد "2017-09-18T14: 00: 00" وحدد منطقة زمنية مثل "توقيت المحيط الهادي"، أو حدد "2017-09- 18T14: 00: 00Z "دون منطقة زمنية. ملاحظة: يبلغ الحد الأقصى لوقت البدء 49 عاماً في المستقبل ويجب أن يتبع مواصفات وقت التاريخ ISO 8601 في تنسيق وقت التاريخ UTC، ولكن دون تعويض التوقيت العالمي المتفق عليه. إذا لم تحدد منطقة زمنية، يجب إضافة الحرف "Z" في النهاية دون أي مسافات. يشير هذا الحرف "Z" إلى ما يعادل الوقت البحري. بالنسبة للجداول الزمنية البسيطة، يكون وقت البدء هو أول ظهور، بينما بالنسبة للجداول المعقدة، لا يتم إطلاق المشغل في وقت أقرب من وقت البدء. لمزيد من المعلومات بشأن تواريخ وأوقات البدء، راجع إنشاء وجدولة المهام قيد التشغيل بانتظام. |
<المنطقة الزمنية> | السلسلة | يسري فقط عندما تحدد وقت بدء لأن هذا المشغل لا يقبل تعويض التوقيت العالمي المتفق عليه. حدد المنطقة الزمنية التي تريد تطبيقها. |
<علامة ساعة واحدة أو أكثر> | عدد صحيح أو مجموعة صحيحة | إذا حددت "يوم" أو "أسبوع" لـ frequency ، يمكنك تحديد عدد صحيح واحد أو أكثر من 0 إلى 23، مفصولاً بفاصلات، كساعات اليوم التي تريد فيها تشغيل سير العمل. على سبيل المثال، إذا حددت "10" و"12" و"14"، فستحصل على 10 صباحاً و12 ظهراً و2 ظهراً كعلامات ساعة. |
<علامة دقيقة واحدة أو أكثر> | عدد صحيح أو مجموعة صحيحة | إذا حددت "يوم" أو "أسبوع" لـ frequency ، يمكنك تحديد عدد صحيح واحد أو أكثر من 0 إلى 59، مفصولاً بفاصلات، كدقائق الساعة التي تريد فيها تشغيل سير العمل. على سبيل المثال، يمكنك تحديد "30" كعلامة دقيقة واستخدام المثال السابق لساعات اليوم، تحصل على 10:30 صباحاً و12:30 ظهراً و2:30 مساءً. |
أيام الأسبوع | سلسلة أو مجموعة سلسلة | إذا حددت "أسبوع" لـ frequency ، يمكنك تحديد يوم واحد أو أكثر، مفصولاً بفواصل، عندما تريد تشغيل سير العمل: "الاثنين"، "الثلاثاء"، "الأربعاء"، "الخميس"، "الجمعة"، "السبت والأحد" |
<الحد الأقصى للتشغيل> | رقم صحيح | بشكل افتراضي، تعمل جميع مثيلات سير العمل في نفس الوقت (بشكل متزامن أو بالتوازي) حتى الحد الافتراضي. لتغيير هذا الحد عن طريق تعيين قيمة <عدد> جديدة، راجع تغيير التزامن المشغل. |
<max-runs-queue> | رقم صحيح | عندما يقوم سير العمل بالفعل بتشغيل الحد الأقصى لعدد المثيلات، والتي يمكنك تغييرها بناءً على خاصية runtimeConfiguration.concurrency.runs ، يتم وضع أي عمليات تشغيل جديدة في قائمة الانتظار هذه حتى الحد الافتراضي. لتغيير الحد الافتراضي، راجع تغيير حد فترات الانتظار. |
<operation-option> | السلسلة | يمكنك تغيير السلوك الافتراضي عن طريق تعيين خاصية operationOptions . لمزيد من المعلومات، راجع خيارات العملية. |
مثال 1
يعمل مشغل التكرار الأساسي هذا يومياً:
"Recurrence": {
"type": "Recurrence",
"recurrence": {
"frequency": "Day",
"interval": 1
}
}
مثال 2
يمكنك تحديد تاريخ البدء والوقت لإطلاق الزناد. يبدأ مشغل التكرار هذا في التاريخ المحدد ثم يتم تشغيله يومياً:
"Recurrence": {
"type": "Recurrence",
"recurrence": {
"frequency": "Day",
"interval": 1,
"startTime": "2017-09-18T00:00:00Z"
}
}
مثال 3
يبدأ مشغل التكرار هذا في 9 أيلول (سبتمبر) 2017 الساعة 2:00 ظهراً، وينطلق أسبوعياً كل يوم اثنين في الساعة 10:30 صباحاً و12:30 ظهراً و2:30 مساءً بتوقيت المحيط الهادي القياسي:
"Recurrence": {
"type": "Recurrence",
"recurrence": {
"frequency": "Week",
"interval": 1,
"schedule": {
"hours": [ 10, 12, 14 ],
"minutes": [ 30 ],
"weekDays": [ "Monday" ]
},
"startTime": "2017-09-07T14:00:00",
"timeZone": "Pacific Standard Time"
}
}
لمزيد من المعلومات بالإضافة إلى أمثلة لهذا المشغل، راجع إنشاء وجدولة المهام قيد التشغيل بانتظام.
مشغل الطلب
يجعل هذا المشغل تطبيقك المنطقي قابلاً للاستدعاء من خلال إنشاء نقطة نهاية يمكنها قبول الطلبات الواردة. بالنسبة إلى هذا المشغل، قم بتوفير مخطط JSON الذي يصف الحمولة أو المدخلات التي يتلقاها المشغل من الطلب الوارد ويتحقق منها. يسهل المخطط أيضاً الرجوع إلى خصائص المشغل من الإجراءات اللاحقة في سير العمل.
لاستدعاء هذا المشغل، يجب عليك استخدام listCallbackUrl
API، الموصوفة في Workflow Service REST API. لمعرفة كيفية استخدام هذا المشغل كنقطة نهاية HTTP، راجع استدعاء مهام سير العمل أو تشغيلها أو تداخلها مع نقاط نهاية HTTP.
"manual": {
"type": "Request",
"kind": "Http",
"inputs": {
"method": "<method-type>",
"relativePath": "<relative-path-for-accepted-parameter>",
"schema": {
"type": "object",
"properties": {
"<property-name>": {
"type": "<property-type>"
}
},
"required": [ "<required-properties>" ]
}
},
"runTimeConfiguration": {
"concurrency": {
"runs": <max-runs>,
"maximumWaitingRuns": <max-run-queue>
},
},
"operationOptions": "<operation-option>"
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<property-name> | السلسلة | اسم الخاصية في مخطط JSON، الذي يصف الحمولة |
<property-type> | السلسلة | نوع الخاصية |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<method-type> | السلسلة | الطريقة التي يجب أن تستخدمها الطلبات الواردة لاستدعاء التطبيق المنطقي الخاص بك: "GET"، "PUT"، "POST"، "PATCH"، "DELETE" |
<relative-path-for-accepted-parameter> | السلسلة | المسار النسبي للمعلمة التي يمكن أن يقبلها عنوان URL لنقطة النهاية |
<الخصائص المطلوبة> | صفيف | خاصية واحدة أو أكثر تتطلب قيماً |
<الحد الأقصى للتشغيل> | رقم صحيح | بشكل افتراضي، تعمل جميع مثيلات سير العمل في نفس الوقت (بشكل متزامن أو بالتوازي) حتى الحد الافتراضي. لتغيير هذا الحد عن طريق تعيين قيمة <عدد> جديدة، راجع تغيير التزامن المشغل. |
<max-runs-queue> | رقم صحيح | عندما يقوم سير العمل بالفعل بتشغيل الحد الأقصى لعدد المثيلات، والتي يمكنك تغييرها بناءً على خاصية runtimeConfiguration.concurrency.runs ، يتم وضع أي عمليات تشغيل جديدة في قائمة الانتظار هذه حتى الحد الافتراضي. لتغيير الحد الافتراضي، راجع تغيير حد فترات الانتظار. |
<operation-option> | السلسلة | يمكنك تغيير السلوك الافتراضي عن طريق تعيين خاصية operationOptions . لمزيد من المعلومات، راجع خيارات العملية. |
مثال
يحدد هذا المشغل أن الطلب الوارد يجب أن يستخدم طريقة HTTP POST لاستدعاء المشغل ويتضمن مخططاً يتحقق من صحة الإدخال من الطلب الوارد:
"manual": {
"type": "Request",
"kind": "Http",
"inputs": {
"method": "POST",
"schema": {
"type": "object",
"properties": {
"customerName": {
"type": "String"
},
"customerAddress": {
"type": "Object",
"properties": {
"streetAddress": {
"type": "string"
},
"city": {
"type": "string"
}
}
}
}
}
}
}
شروط المشغّل
بالنسبة لأي مشغل، والمشغلات فقط، يمكنك تضمين صفيف يحتوي على تعبير واحد أو أكثر للشروط التي تحدد ما إذا كان يجب تشغيل سير العمل أم لا. لإضافة خاصية conditions
إلى مشغل في سير عملك، افتح تطبيقك المنطقي في محرر عرض التعليمة البرمجية.
على سبيل المثال، يمكنك تحديد تنشيط المشغل فقط عندما يعرض موقع الويب خطأ خادم داخلي من خلال الرجوع إلى رمز حالة المشغل في الخاصية conditions
:
"Recurrence": {
"type": "Recurrence",
"recurrence": {
"frequency": "Hour",
"interval": 1
},
"conditions": [ {
"expression": "@equals(triggers().code, 'InternalServerError')"
} ]
}
بشكل افتراضي، يتم إطلاق المشغل فقط بعد الحصول على استجابة "200 موافق". عندما يشير تعبير إلى رمز حالة المشغل، يتم استبدال السلوك الافتراضي للمشغل. لذلك، إذا كنت تريد تنشيط المشغل لأكثر من رمز حالة واحد، مثل تعليمة برمجية الحالة "200" و"201"، يجب عليك تضمين هذا التعبير كشرط:
@or(equals(triggers().code, 200),equals(triggers().code, 201))
تشغيل عمليات تشغيل متعددة على صفيف
إذا تلقى المشغل صفيفًا من أجل معالجة سير العمل، فقد تستغرق أحيانًا "لكل" حلقة وقتًا طويلاً لمعالجة كل عنصر من عناصر الصفيف. بدلاً من ذلك، يمكنك استخدام الخاصية SplitOn في المشغل الخاص بك debatch الصفيف. تؤدي عملية التصحيح إلى تقسيم عناصر الصفيف وتبدأ مثيل سير عمل جديد يتم تشغيله لكل عنصر صفيف. هذا الأسلوب مفيد، على سبيل المثال، عندما تريد استقصاء نقطة نهاية قد ترجع عدة عناصر جديدة بين فترات الاستقصاء.
إذا كان ملف Swagger الخاص بالمشغل يصف حمولة عبارة عن صفيف، تتم إضافة خاصية SplitOn تلقائيًا إلى المشغل. بخلاف ذلك، أضف هذه الخاصية داخل حمولة الاستجابة التي تحتوي على الصفيف التي تريد تحريرها.
قبل استخدام إمكانية SplitOn، راجع الاعتبارات التالية:
عند تمكين تشغيل التزامن، يتم تقليل حد SplitOn بشكل ملحوظ. إذا تجاوز عدد العناصر هذا الحد، فسيتم تعطيل إمكانية SplitOn.
لا يمكنك استخدام إمكانية SplitOn مع نمط استجابة متزامن. أي سير عمل يستخدم خاصية SplitOn ويتضمن إجراء استجابة يعمل بشكل غير متزامن ويرسل فورًا استجابة
202 ACCEPTED
.للحصول على أقصى عدد من عناصر الصفيف التي يمكن لـ SplitOn معالجتها في تشغيل سير عمل واحد، راجع الحدود والتكوين.
مثال
لنفترض أن لديك مشغل HTTP يستدعي واجهة برمجة التطبيقات ويتلقى هذه الاستجابة:
{
"Status": "Succeeded",
"Rows": [
{
"id": 938109380,
"name": "customer-name-one"
},
{
"id": 938109381,
"name": "customer-name-two"
}
]
}
يحتاج سير العمل الخاص بك فقط إلى المحتوى من الصفيف في Rows
، لذا يمكنك إنشاء مشغل مثل هذا المثال:
"HTTP_Debatch": {
"type": "Http",
"inputs": {
"uri": "https://mydomain.com/myAPI",
"method": "GET"
},
"recurrence": {
"frequency": "Second",
"interval": 1
},
"splitOn": "@triggerBody()?.Rows"
}
إشعار
إذا استخدمت الأمر SplitOn
، فلن تتمكن من الحصول على الخصائص الموجودة خارج الصفيف.
لذلك في هذا المثال، لا يمكنك الحصول على الخاصية status
في الاستجابة التي يتم إرجاعها من واجهة برمجة التطبيقات.
لتجنب الفشل في حالة عدم وجود خاصية Rows
، يستخدم هذا المثال عامل التشغيل ?
.
يمكن أن يستخدم تعريف سير العمل الآن @triggerBody().name
للحصول على قيم name
، والتي هي "customer-name-one"
من التشغيل الأول و"customer-name-two"
من التشغيل الثاني. لذلك، تبدو مخرجات المشغل مثل هذه الأمثلة:
{
"body": {
"id": 938109380,
"name": "customer-name-one"
}
}
{
"body": {
"id": 938109381,
"name": "customer-name-two"
}
}
نظرة عامة على الإجراءات
توفر Azure Logic Apps أنواع إجراءات متنوعة - لكل منها مدخلات مختلفة تحدد السلوك الفريد للإجراء. تحتوي الإجراءات على هذه العناصر عالية المستوى، رغم أن بعضها اختياري:
"<action-name>": {
"type": "<action-type>",
"inputs": {
"<input-name>": { "<input-value>" },
"retryPolicy": "<retry-behavior>"
},
"runAfter": { "<previous-trigger-or-action-status>" },
"runtimeConfiguration": { "<runtime-config-options>" },
"operationOptions": "<operation-option>"
},
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<اسم الإجراء> | السلسلة | اسم العمل |
<نوع الإجراء> | السلسلة | نوع الإجراء، على سبيل المثال، "Http" أو "ApiConnection" |
<input-name> | السلسلة | اسم الإدخال الذي يحدد سلوك الإجراء |
<input-value> | مختلف | قيمة الإدخال، والتي يمكن أن تكون سلسلة وعدد صحيح وعنصر JSON وما إلى ذلك |
<previous-trigger-or-action-status> | كائن JSON | الاسم والحالة الناتجة للمشغل أو الإجراء الذي يجب تشغيله على الفور قبل أن يتم تشغيل هذا الإجراء الحالي |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<إعادة المحاولة> | كائن JSON | يخصص سلوك إعادة المحاولة للفشل المتقطع، والذي يحتوي على تعليمة برمجية الحالة 408، و429، و5XX، وأي استثناءات تتعلق بالاتصال. لمزيد من المعلومات، راجع نُهج إعادة المحاولة. |
<خيارات تهيئة وقت التشغيل> | كائن JSON | بالنسبة لبعض الإجراءات، يمكنك تغيير سلوك الإجراء في وقت التشغيل عن طريق تعيين خصائص runtimeConfiguration . لمزيد من المعلومات، راجع إعدادات تكوين وقت التشغيل. |
<operation-option> | السلسلة | بالنسبة لبعض الإجراءات، يمكنك تغيير السلوك الافتراضي عن طريق تعيين الخاصية operationOptions . لمزيد من المعلومات، راجع خيارات العملية. |
قائمة أنواع الإجراءات
فيما يلي بعض أنواع الإجراءات الشائعة الاستخدام:
أنواع الإجراءات المضمنة مثل هذه الأمثلة والمزيد:
HTTP لاستدعاء نقاط النهاية عبر HTTP أو HTTPS
استجابة للرد على الطلبات
تنفيذ تعليمة JavaScript البرمجية لتشغيل مقتطفات تعليمة JavaScript البرمجية
وظيفة لاستدعاء Azure Functions
إجراءات تشغيل البيانات مثل انضمام، إنشاء، جدول، حدد، وأخرى تنشئ أو تحوّل بيانات من مدخلات مختلفة
سير العمل لاستدعاء سير عمل تطبيق منطقي آخر
أنواع إجراءات واجهة برمجة التطبيقات المُدارة مثل ApiConnection وApiConnectionWebHook التي تستدعي موصلات وواجهات برمجة تطبيقات متنوعة تديرها Microsoft، لـ مثال، Azure Service Bus وOffice 365 Outlook وPower BI وAzure Blob Storage وOneDrive وGitHub والمزيد
التحكم في أنواع إجراءات سير العمل مثل If، Foreach، Switchو النطاق وحتى، والتي تحتوي على إجراءات أخرى وتساعدك على تنظيم تنفيذ سير العمل
إجراءات مدمجة
نوع الإجراء | الوصف |
---|---|
انشاء | لإنشاء مخرجات فردية من المدخلات، والتي يمكن أن يكون لها أنواع مختلفة. |
تنفيذ تعليمة JavaScript البرمجية | قم بتشغيل مقتطفات تعليمات JavaScript البرمجية التي تناسب معايير محددة. للحصول على متطلبات التعليمة البرمجية ومزيد من المعلومات، راجع إضافة وتشغيل مقتطفات التعليمة البرمجية مع التعليمة البرمجية المضمنة. |
دالة | يستدعي وظيفة Azure. |
HTTP | يستدعي نقطة نهاية HTTP. |
الانضمام | يُنشئ سلسلة من جميع العناصر في صفيف ويفصل بين تلك العناصر بحرف محدد. |
تحليل JSON | ينشئ رموزاً سهلة الاستخدام من خصائص في محتوى JSON. يمكنك بعد ذلك الرجوع إلى تلك الخصائص من خلال تضمين الرموز المميزة في التطبيق المنطقي الخاص بك. |
الاستعلام | ينشئ صفيفاً من عناصر في صفيف آخر بناءً على شرط أو عامل تصفية. |
Response | ينشئ رداً على مكالمة واردة أو طلب. |
Select | يُنشئ صفيفاً بعناصر JSON بتحويل العناصر من صفيف آخر بناءً على الخريطة المحددة. |
جدول | ينشئ جدول CSV أو HTML من صفيف. |
انهاء | يوقف سير عمل نشط. |
انتظري | إيقاف سير العمل مؤقتاً لمدة محددة أو حتى التاريخ والوقت المحددين. |
سير العمل | يداخل سير عمل داخل سير عمل آخر. |
إجراءات API المُدارة
نوع الإجراء | الوصف |
---|---|
ApiConnection | لاستدعاء نقطة نهاية HTTP باستخدام واجهة برمجة تطبيقات تديرها Microsoft. |
ApiConnectionWebhook | يعمل مثل HTTP Webhook ولكنه يستخدم واجهة برمجة تطبيقات تديرها Microsoft. |
التحكم في إجراءات سير العمل
تساعدك هذه الإجراءات في التحكم في تنفيذ سير العمل وتضمين إجراءات أخرى. من خارج إجراء سير عمل التحكم، يمكنك الرجوع مباشرة إلى الإجراءات الموجودة داخل إجراء التحكم في سير العمل. على سبيل المثال، إذا كان لديك إجراء Http
داخل نطاق، يمكنك الرجوع إلى التعبير @body('Http')
من أي مكان في سير العمل. ومع ذلك، يمكن للإجراءات الموجودة داخل إجراء سير عمل التحكم فقط "تشغيلها بعد" الإجراءات الأخرى الموجودة في نفس بنية مسار عمل التحكم.
نوع الإجراء | الوصف |
---|---|
ForEach | قم بتشغيل نفس الإجراءات في حلقة لكل عنصر في الصفيف. |
If | قم بتشغيل الإجراءات بناءً على ما إذا كان الشرط المحدد صحيحاً أم خطأ. |
النطاق | قم بتشغيل الإجراءات بناءً على حالة المجموعة من مجموعة من الإجراءات. |
Switch | قم بتشغيل الإجراءات المنظمة في حالات عندما تتطابق القيم من التعبيرات أو العناصر أو الرموز المميزة مع القيم المحددة بواسطة كل حالة. |
حتي | قم بتشغيل الإجراءات في حلقة حتى يتحقق الشرط المحدد. |
الإجراءات - مرجع مفصل
عمل APIConnection
يرسل هذا الإجراء طلب HTTP إلى واجهة برمجة تطبيقات تديرها Microsoft ويتطلب معلومات بشأن واجهة برمجة التطبيقات والمعلمات بالإضافة إلى مرجع لاتصال صالح.
"<action-name>": {
"type": "ApiConnection",
"inputs": {
"host": {
"connection": {
"name": "@parameters('$connections')['<api-name>']['connectionId']"
},
"<other-action-specific-input-properties>"
},
"method": "<method-type>",
"path": "/<api-operation>",
"retryPolicy": "<retry-behavior>",
"queries": { "<query-parameters>" },
"<other-action-specific-properties>"
},
"runAfter": {}
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<اسم الإجراء> | السلسلة | اسم الإجراء الذي قدمه الموصل |
<api-name> | السلسلة | اسم API الذي تديره Microsoft والمستخدم للاتصال |
<method-type> | السلسلة | طريقة HTTP لاستدعاء واجهة برمجة التطبيقات: "GET" أو "PUT" أو "POST" أو "PATCH" أو "DELETE" |
<عملية واجهة برمجة التطبيقات> | السلسلة | عملية API للاتصال |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<other-action-specific-input-properties> | كائن JSON | أي خصائص إدخال أخرى تنطبق على هذا الإجراء المحدد |
<إعادة المحاولة> | كائن JSON | يخصص سلوك إعادة المحاولة للفشل المتقطع، والذي يحتوي على تعليمة برمجية الحالة 408، و429، و5XX، وأي استثناءات تتعلق بالاتصال. لمزيد من المعلومات، راجع نُهج إعادة المحاولة. |
<معامِلات طلب البحث> | كائن JSON | أي معلمات استعلام لتضمينها مع استدعاء API. على سبيل المثال، يضيف العنصر "queries": { "api-version": "2018-01-01" } ?api-version=2018-01-01 إلى المكالمة. |
<other-action-specific-properties> | كائن JSON | أي خصائص أخرى تنطبق على هذا الإجراء المحدد |
مثال
يصف هذا التعريف إجراء إرسال بريد إلكتروني لموصل Office 365 Outlook، وهو واجهة برمجة تطبيقات تديرها Microsoft:
"Send_an_email": {
"type": "ApiConnection",
"inputs": {
"body": {
"Body": "Thank you for your membership!",
"Subject": "Hello and welcome!",
"To": "Sophie.Owen@contoso.com"
},
"host": {
"connection": {
"name": "@parameters('$connections')['office365']['connectionId']"
}
},
"method": "POST",
"path": "/Mail"
},
"runAfter": {}
}
إجراء APIConnectionWebhook
يرسل هذا الإجراء طلب اشتراك عبر HTTP إلى نقطة نهاية باستخدام واجهة برمجة تطبيقات تديرها Microsoft، ويوفر عنوان URL لمعاودة الاتصال حيث يمكن لنقطة النهاية إرسال استجابة، وتنتظر نقطة النهاية إلى رد. لمزيد من المعلومات، راجع اشتراكات نقطة النهاية.
"<action-name>": {
"type": "ApiConnectionWebhook",
"inputs": {
"subscribe": {
"method": "<method-type>",
"uri": "<api-subscribe-URL>",
"headers": { "<header-content>" },
"body": "<body-content>",
"authentication": { "<authentication-type>" },
"retryPolicy": "<retry-behavior>",
"queries": { "<query-parameters>" },
"<other-action-specific-input-properties>"
},
"unsubscribe": {
"method": "<method-type>",
"uri": "<api-unsubscribe-URL>",
"headers": { "<header-content>" },
"body": "<body-content>",
"authentication": { "<authentication-type>" },
"<other-action-specific-properties>"
},
},
"runAfter": {}
}
تتوفر بعض القيم، مثل <نوع الأسلوب>، لكل من عنصرين "subscribe"
و"unsubscribe"
.
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<اسم الإجراء> | السلسلة | اسم الإجراء الذي قدمه الموصل |
<method-type> | السلسلة | طريقة HTTP المستخدمة للاشتراك أو إلغاء الاشتراك من نقطة نهاية: "GET" أو "PUT" أو "POST" أو "PATCH" أو "DELETE" |
<api-subscribe-URL> | السلسلة | URI المراد استخدامه للاشتراك في API |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<عنوان URL لواجهة برمجة تطبيقات إلغاء الاشتراك> | السلسلة | URI المراد استخدامه لإلغاء الاشتراك من API |
<header-content> | كائن JSON | أي رؤوس لإرسالها في الطلب على سبيل المثال، لتعيين اللغة والكتابة على طلب: "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" } |
<محتوى الجسم> | كائن JSON | أي محتوى رسالة لإرساله في الطلب |
<نوع المصادقة> | كائن JSON | نموذج المصادقة الذي يستخدمه الطلب لمصادقة الطلبات الصادرة. لمزيد من المعلومات، راجع إضافة مصادقة للمكالمات الصادرة. |
<إعادة المحاولة> | كائن JSON | يخصص سلوك إعادة المحاولة للفشل المتقطع، والذي يحتوي على تعليمة برمجية الحالة 408، و429، و5XX، وأي استثناءات تتعلق بالاتصال. لمزيد من المعلومات، راجع نُهج إعادة المحاولة. |
<معامِلات طلب البحث> | كائن JSON | أي معلمات استعلام لتضمينها مع استدعاء واجهة برمجة التطبيقات على سبيل المثال، يضيف العنصر "queries": { "api-version": "2018-01-01" } ?api-version=2018-01-01 إلى المكالمة. |
<other-action-specific-input-properties> | كائن JSON | أي خصائص إدخال أخرى تنطبق على هذا الإجراء المحدد |
<other-action-specific-properties> | كائن JSON | أي خصائص أخرى تنطبق على هذا الإجراء المحدد |
يمكنك أيضاً تحديد حدود لإجراء ApiConnectionWebhook بنفس طريقة حدود HTTP غير المتزامنة.
إجراء الإنشاء
ينشئ هذا الإجراء ناتجاً واحداً من مدخلات متعددة، بما في ذلك التعبيرات. يمكن أن يكون لكل من المخرجات والمدخلات أي نوع تدعمه Azure Logic Apps في الأصل، مثل الصفائف وعناصر JSON وXML والثنائي. يمكنك بعد ذلك استخدام ناتج الإجراء في إجراءات أخرى.
"Compose": {
"type": "Compose",
"inputs": "<inputs-to-compose>",
"runAfter": {}
},
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<inputs-to-compose> | أي | المدخلات لإنشاء مخرجات فردية |
مثال 1
يدمج تعريف الإجراء هذا abcdefg
مع مسافة لاحقة والقيمة 1234
:
"Compose": {
"type": "Compose",
"inputs": "abcdefg 1234",
"runAfter": {}
},
هذا هو الناتج الذي يُنشئه هذا الإجراء:
abcdefg 1234
مثال 2
يدمج تعريف الإجراء هذا متغير سلسلة يحتوي على abcdefg
ومتغير عدد صحيح يحتوي على 1234
:
"Compose": {
"type": "Compose",
"inputs": "@{variables('myString')}@{variables('myInteger')}",
"runAfter": {}
},
هذا هو الناتج الذي يُنشئه هذا الإجراء:
"abcdefg1234"
قم بتنفيذ إجراء JavaScript Code
يقوم هذا الإجراء بتشغيل قصاصة برمجية تعليمات JavaScript البرمجية وإرجاع النتائج من خلال تعليمة برمجية مميز يمكن للإجراءات اللاحقة في سير العمل الرجوع إليها.
"Execute_JavaScript_Code": {
"type": "JavaScriptCode",
"inputs": {
"code": "<JavaScript-code-snippet>",
"explicitDependencies": {
"actions": [ <preceding-actions> ],
"includeTrigger": true
}
},
"runAfter": {}
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<JavaScript-code-snippet> | يتفاوت | تعليمة JavaScript البرمجية الذي تريد تشغيله. للحصول على متطلبات التعليمة البرمجية ومزيد من المعلومات، راجع تشغيل مقتطفات التعليمة البرمجية في مهام سير العمل. في السمة code ، يمكن لمقتطف التعليمة البرمجية استخدام عنصر للقراءة فقط workflowContext كإدخال. يحتوي هذا العنصر على خصائص فرعية تمنحك حق الوصول إلى التعليمة البرمجية إلى المخرجات من المشغل وأي إجراءات سابقة في سير عملك. لمزيد من المعلومات بشأن العنصر workflowContext ، راجع مشغل الإشارة ونتائج الإجراء باستخدام عنصر workflowContext. |
مطلوب في بعض الحالات
تحدد السمة explicitDependencies
أنك تريد تضمين النتائج صراحةً من المشغل أو الإجراءات السابقة أو كليهما كتبعيات لمقتطف التعليمة البرمجية. لمزيد من المعلومات بشأن إضافة هذه التبعيات، راجع إضافة تبعيات كمعلمات إلى إجراء Inline Code.
بالنسبة للسمة includeTrigger
، يمكنك تحديد قيم true
أو false
.
القيمة | النوع | الوصف |
---|---|---|
<preceding-actions> | صفيف سلسلة | صفيف بأسماء الإجراء بتنسيق JSON كتبعيات. تأكد من استخدام أسماء الإجراءات التي تظهر في تعريف سير العمل الخاص بك حيث تستخدم أسماء الإجراءات الشرطات السفلية (_)، وليس المسافات (""). |
مثال 1
يؤدي هذا الإجراء إلى تشغيل التعليمة البرمجية التي تحصل على اسم سير عمل التطبيق المنطقي وإرجاع النص "مرحباً بالعالم من <اسم التطبيق المنطقي>" كنتيجة لذلك. في هذا المثال، تشير التعليمة البرمجية إلى اسم سير العمل من خلال الوصول إلى الخاصية workflowContext.workflow.name
من خلال عنصر للقراءة فقط workflowContext
. لمزيد من المعلومات بشأن استخدام العنصر workflowContext
، راجع مشغل الإشارة ونتائج الإجراء في التعليمة البرمجية الخاصة بك.
"Execute_JavaScript_Code": {
"type": "JavaScriptCode",
"inputs": {
"code": "var text = \"Hello world from \" + workflowContext.workflow.name;\r\n\r\nreturn text;"
},
"runAfter": {}
}
مثال 2
يقوم هذا الإجراء بتشغيل التعليمة البرمجية في سير عمل تطبيق منطقي يتم تشغيله عند وصول بريد إلكتروني جديد إلى حساب Outlook. يستخدم سير العمل أيضاً إجراء Office 365 Outlook إرسال بريد إلكتروني للموافقة الذي يعيد توجيه المحتوى من البريد الإلكتروني المستلم مع طلب الموافقة.
يستخرج التعليمة البرمجية عناوين البريد الإلكتروني من خاصية Body
لرسالة البريد الإلكتروني، ويعيد العناوين مع قيمة خاصية SelectedOption
من إجراء الموافقة. يتضمن الإجراء بشكل صريح إجراء إرسال بريد إلكتروني للموافقة كعنصر تابع في عنصر actions
داخل العنصر explicitDependencies
.
"Execute_JavaScript_Code": {
"type": "JavaScriptCode",
"inputs": {
"code": "var myResult = /(([^<>()\\[\\]\\\\.,;:\\s@\"]+(\\.[^<>()\\[\\]\\\\.,;:\\s@\"]+)*)|(\".+\"))@((\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}])|(([a-zA-Z\\-0-9]+\\.)+[a-zA-Z]{2,}))/g;\r\n\r\nvar email = workflowContext.trigger.outputs.body.Body;\r\n\r\nvar reply = workflowContext.actions.Send_approval_email.outputs.body.SelectedOption;\r\n\r\nreturn email.match(myResult) + \" - \" + reply;\r\n;",
"explicitDependencies": {
"actions": [
"Send_approval_email"
]
}
},
"runAfter": {}
}
عمل الوظيفة
يستدعي هذا الإجراء وظيفة Azureالتي تم إنشاؤها مسبقاً.
"<Azure-function-name>": {
"type": "Function",
"inputs": {
"function": {
"id": "<Azure-function-ID>"
},
"method": "<method-type>",
"headers": { "<header-content>" },
"body": { "<body-content>" },
"queries": { "<query-parameters>" }
},
"runAfter": {}
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<معرّف وظيفة Azure> | السلسلة | معرّف المورد لوظيفة Azure التي تريد الاتصال بها. فيما يلي تنسيق هذه القيمة: "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group>/providers/Microsoft.Web/sites/<Azure-function-app-name>/functions/<Azure-function-name>" |
<method-type> | السلسلة | أسلوب HTTP لاستخدامه لاستدعاء الدالة: "GET" أو "PUT" أو "POST" أو "PATCH" أو "DELETE" إذا لم يتم تحديده، يكون الإعداد الافتراضي هو طريقة "POST". |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<header-content> | كائن JSON | أي رؤوس لإرسالها مع المكالمة على سبيل المثال، لتعيين اللغة والكتابة على طلب: "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" } |
<محتوى الجسم> | كائن JSON | أي محتوى رسالة لإرساله في الطلب |
<معامِلات طلب البحث> | كائن JSON | أي معلمات استعلام لتضمينها مع استدعاء واجهة برمجة التطبيقات على سبيل المثال، يضيف العنصر "queries": { "api-version": "2018-01-01" } ?api-version=2018-01-01 إلى المكالمة. |
<other-action-specific-input-properties> | كائن JSON | أي خصائص إدخال أخرى تنطبق على هذا الإجراء المحدد |
<other-action-specific-properties> | كائن JSON | أي خصائص أخرى تنطبق على هذا الإجراء المحدد |
عند حفظ تطبيق المنطق الخاص بك، تقوم Azure Logic Apps بإجراء هذه الفحوصات على الدالة المشار إليها:
يجب أن يكون لسير العمل الخاص بك حق الوصول إلى الوظيفة.
يمكن لسير العمل استخدام مشغل HTTP قياسي أو مشغل خطاف ويب JSON عام.
تحصل Azure Logic Apps على عنوان URL للمشغل وتخزنه مؤقتا، والذي يتم استخدامه في وقت التشغيل. ومع ذلك، إذا أبطلت أي عملية عنوان URL المخزن مؤقتاً، فسيفشل إجراء الوظيفة في وقت التشغيل. لإصلاح هذه المشكلة، احفظ التطبيق المنطقي مرة أخرى حتى يحصل التطبيق المنطقي على عنوان URL المشغل ويخزنه مؤقتاً مرة أخرى.
لا يمكن تحديد أي مسار للوظيفة.
يُسمح فقط بمستويات المصادقة "الوظيفية" و"المجهولة".
مثال
يستدعي تعريف الإجراء هذا وظيفة "GetProductID" التي تم إنشاؤها مسبقاً:
"GetProductID": {
"type": "Function",
"inputs": {
"function": {
"id": "/subscriptions/<XXXXXXXXXXXXXXXXXXXX>/resourceGroups/myLogicAppResourceGroup/providers/Microsoft.Web/sites/InventoryChecker/functions/GetProductID"
},
"method": "POST",
"headers": {
"x-ms-date": "@utcnow()"
},
"body": {
"Product_ID": "@variables('ProductID')"
}
},
"runAfter": {}
}
إجراء HTTP
يرسل هذا الإجراء طلباً إلى نقطة نهاية HTTP أو HTTPS المحددة ويتحقق من الاستجابة لتحديد ما إذا كان سير العمل سيتم تشغيله أم لا. لمزيد من المعلومات، راجع الاتصال بنقاط نهاية الخدمة عبر HTTP أو HTTPS من Azure Logic Apps.
"HTTP": {
"type": "Http",
"inputs": {
"method": "<method-type>",
"uri": "<HTTP-or-HTTPS-endpoint-URL>",
"headers": { "<header-content>" },
"queries": { "<query-parameters>" },
"body": "<body-content>",
"authentication": { "<authentication-type-and-property-values>" },
"retryPolicy": {
"type": "<retry-behavior>"
},
},
"runAfter": {}
}
مطلوب
الخاصية | القيمة | النوع | الوصف |
---|---|---|---|
method |
<method-type> | السلسلة | الطريقة المستخدمة لإرسال الطلب الصادر: "GET" أو "PUT" أو "POST" أو "PATCH" أو "DELETE" |
uri |
<عنوان URL لنقطة نهاية HTTP أو HTTPS> | السلسلة | عنوان URL لنقطة نهاية HTTP أو HTTPS حيث تريد إرسال الطلب الصادر. الحد الأقصى لحجم السلسلة: 2 كيلوبايت بالنسبة إلى مورد أو خدمة Azure، يتضمن بناء جملة URI هذا معرف المورد والمسار إلى المورد الذي تريد الوصول إليه. |
اختياري
الخاصية | القيمة | النوع | الوصف |
---|---|---|---|
headers |
<header-content> | كائن JSON | أي رؤوس تحتاج إلى تضمينها مع الطلب على سبيل المثال، لتعيين اللغة والنوع: "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" } |
queries |
<معامِلات طلب البحث> | كائن JSON | أي معلمات استعلام تحتاج إلى استخدامها في الطلب على سبيل المثال، يضيف العنصر "queries": { "api-version": "2018-01-01" } ?api-version=2018-01-01 إلى المكالمة. |
body |
<محتوى الجسم> | كائن JSON | محتوى الرسالة المراد إرسالها كحمولة مع الطلب |
authentication |
<نوع المصادقة وقيم الخاصية> | كائن JSON | نموذج المصادقة الذي يستخدمه الطلب لمصادقة الطلبات الصادرة. لمزيد من المعلومات، راجع إضافة مصادقة للمكالمات الصادرة. بعد برنامج الجدولة، يتم دعم خاصية authority . في حالة عدم تحديدها، تكون القيمة الافتراضية هي https://management.azure.com/ ، ولكن يمكنك استخدام قيمة مختلفة. |
retryPolicy > type |
<إعادة المحاولة> | كائن JSON | يخصص سلوك إعادة المحاولة للفشل المتقطع، والذي يحتوي على تعليمة برمجية الحالة 408، و429، و5XX، وأي استثناءات تتعلق بالاتصال. لمزيد من المعلومات، راجع نُهج إعادة المحاولة. |
<other-action-specific-input-properties> | <خاصية الإدخال> | كائن JSON | أي خصائص إدخال أخرى تنطبق على هذا الإجراء المحدد |
<other-action-specific-properties> | <property-value> | كائن JSON | أي خصائص أخرى تنطبق على هذا الإجراء المحدد |
مثال
يحصل تعريف الإجراء هذا على آخر الأخبار عن طريق إرسال طلب إلى نقطة النهاية المحددة:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://mynews.example.com/latest"
}
}
إجراء الانضمام
ينشئ هذا الإجراء سلسلة من جميع العناصر في صفيف ويفصل بين تلك العناصر بحرف المحدد.
"Join": {
"type": "Join",
"inputs": {
"from": <array>,
"joinWith": "<delimiter>"
},
"runAfter": {}
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<صفيف> | صفيف | الصفيف أو التعبير الذي يوفر العناصر المصدر. إذا حددت تعبيراً، فقم بإحاطة هذا التعبير بعلامات اقتباس مزدوجة. |
<المحدِّد> | سلسلة ذات حرف واحد | الحرف الذي يفصل بين كل عنصر في السلسلة |
مثال
لنفترض أن لديك متغير "myIntegerArray" تم إنشاؤه مسبقاً ويحتوي على صفيف عدد صحيح:
[1,2,3,4]
يحصل تعريف الإجراء هذا على القيم من المتغير باستخدام الوظيفة variables()
في تعبير وإنشاء هذه السلسلة بهذه القيم، والتي يتم فصلها بفاصلة: "1,2,3,4"
"Join": {
"type": "Join",
"inputs": {
"from": "@variables('myIntegerArray')",
"joinWith": ","
},
"runAfter": {}
}
إجراء تحليل JSON
يؤدي هذا الإجراء إلى إنشاء حقول سهلة الاستخدام أو رموز مميزة من الخصائص الموجودة في محتوى JSON. يمكنك بعد ذلك الوصول إلى تلك الخصائص في التطبيق المنطقي الخاص بك باستخدام الرموز المميزة بدلاً من ذلك. على سبيل المثال، عندما تريد استخدام إخراج JSON من خدمات مثل Azure Service Bus وAzure Cosmos DB، يمكنك تضمين هذا الإجراء في تطبيقك المنطقي بحيث يمكنك بسهولة الرجوع إلى البيانات في هذا الإخراج.
"Parse_JSON": {
"type": "ParseJson",
"inputs": {
"content": "<JSON-source>",
"schema": { "<JSON-schema>" }
},
"runAfter": {}
},
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<JSON-source> | كائن JSON | محتوى JSON الذي تريد تحليله |
<JSON-schema> | كائن JSON | مخطط JSON الذي يصف محتوى JSON الأساسي، والذي يستخدمه الإجراء لتحليل محتوى JSON المصدر. تلميح: في مصمم سير العمل، يمكنك إما توفير المخطط أو توفير حمولة عينة بحيث يمكن للإجراء إنشاء المخطط. |
مثال
ينشئ تعريف الإجراء هذا الرموز المميزة التي يمكنك استخدامها في سير العمل الخاص بك ولكن فقط في الإجراءات التي يتم تشغيلها بعد إجراء تحليل JSON :
FirstName
وLastName
وEmail
"Parse_JSON": {
"type": "ParseJson",
"inputs": {
"content": {
"Member": {
"Email": "Sophie.Owen@contoso.com",
"FirstName": "Sophie",
"LastName": "Owen"
}
},
"schema": {
"type": "object",
"properties": {
"Member": {
"type": "object",
"properties": {
"Email": {
"type": "string"
},
"FirstName": {
"type": "string"
},
"LastName": {
"type": "string"
}
}
}
}
}
},
"runAfter": { }
},
في هذا المثال، تحدد خاصية "المحتوى" محتوى JSON للإجراء المطلوب تحليله. يمكنك أيضاً توفير محتوى JSON هذا كنموذج حمولة لإنشاء مخطط قاعدة البيانات.
"content": {
"Member": {
"FirstName": "Sophie",
"LastName": "Owen",
"Email": "Sophie.Owen@contoso.com"
}
},
تحدد خاصية "المخطط" مخطط JSON المستخدم لوصف محتوى JSON:
"schema": {
"type": "object",
"properties": {
"Member": {
"type": "object",
"properties": {
"FirstName": {
"type": "string"
},
"LastName": {
"type": "string"
},
"Email": {
"type": "string"
}
}
}
}
}
إجراء الاستعلام
ينشئ هذا الإجراء صفيفاً من عناصر في صفيف آخر بناءً على شرط أو عامل تصفية محدد.
"Filter_array": {
"type": "Query",
"inputs": {
"from": <array>,
"where": "<condition-or-filter>"
},
"runAfter": {}
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<صفيف> | صفيف | الصفيف أو التعبير الذي يوفر العناصر المصدر. إذا حددت تعبيراً، فقم بإحاطة هذا التعبير بعلامات اقتباس مزدوجة. |
<condition-or-filter> | السلسلة | الشرط المستخدم لتصفية العناصر في الصفيف المصدر ملاحظة: إذا لم تكن هناك قيم تفي بالشرط، فإن الإجراء ينشئ صفيفاً فارغاً. |
مثال
ينشئ تعريف الإجراء هذا صفيفاً يحتوي على قيم أكبر من القيمة المحددة، وهي اثنان:
"Filter_array": {
"type": "Query",
"inputs": {
"from": [ 1, 3, 0, 5, 4, 2 ],
"where": "@greater(item(), 2)"
}
}
إجراء الاستجابة
ينشئ هذا الإجراء حمولة الاستجابة لطلب HTTP.
"Response" {
"type": "Response",
"kind": "http",
"inputs": {
"statusCode": 200,
"headers": { <response-headers> },
"body": { <response-body> }
},
"runAfter": {}
},
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<response-status-code> | رقم صحيح | رمز حالة HTTP الذي تم إرساله إلى الطلب الوارد. التعليمة البرمجية الافتراضي هو "200 OK"، ولكن يمكن أن يكون التعليمة البرمجية أي رمز حالة صالح يبدأ بـ 2xx أو 4xx أو 5xx، ولكن ليس بـ 3xxx. |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<response-headers> | كائن JSON | رأس واحد أو أكثر لتضمينه مع الاستجابة |
<response-body> | مختلف | نص الاستجابة، والذي يمكن أن يكون سلسلة أو عنصر JSON أو حتى محتوى ثنائي من إجراء سابق |
مثال
ينشئ تعريف الإجراء هذا استجابة لطلب HTTP بتعليمة برمجية الحالة المحدد ونص الرسالة ورؤوس الرسائل:
"Response": {
"type": "Response",
"inputs": {
"statusCode": 200,
"body": {
"ProductID": 0,
"Description": "Organic Apples"
},
"headers": {
"x-ms-date": "@utcnow()",
"content-type": "application/json"
}
},
"runAfter": {}
}
القيود
بخلاف الإجراءات الأخرى، فإن الإجراء الاستجابة له قيود خاصة:
يمكن لسير العمل استخدام الإجراء الاستجابة فقط عندما يبدأ سير العمل بمشغل طلب HTTP، ما يعني أنه يجب تشغيل سير العمل الخاص بك عن طريق طلب HTTP.
يمكن أن يستخدم سير العمل إجراء الاستجابة في أي مكان باستثناء داخل حلقات Foreach، وحلقات حتى، بما في ذلك الحلقات المتسلسلة والفروع المتوازية.
يحصل الطلب الأصلي على استجابة سير العمل فقط عندما تنتهي جميع الإجراءات المطلوبة بواسطة إجراء الاستجابة ضمن حد مهلة HTTP.
ومع ذلك، إذا كان سير العمل الخاص بك يستدعي تطبيقاً منطقياً آخر كسير عمل متداخل، فإن سير العمل الأصل ينتظر حتى ينتهي سير العمل المتداخل، بغض النظر عن الوقت الذي يمر قبل انتهاء سير العمل المتداخل.
عندما يستخدم سير العمل إجراء الاستجابة ونمط استجابة متزامن، لا يمكن لسير العمل أيضاً استخدام الأمر splitOn في تعريف المشغل لأن هذا الأمر ينشئ عمليات تشغيل متعددة. تحقق من هذه الحالة عند استخدام طريقة PUT، وإذا كان هذا صحيحاً، فقم بإرجاع استجابة "طلب غير صالح".
وإلا، فإذا كان سير العمل الخاص بك يستخدم الأمر splitOn وإجراء Response، فسيتم تشغيل سير العمل بشكل غير متزامن ويعيد على الفور استجابة "202 ACCEPTED".
عندما يصل تنفيذ سير العمل إلى إجراء الاستجابة، ولكن الطلب الوارد قد تلقى استجابة بالفعل، يتم وضع علامة على الإجراء الاستجابة على أنه "فشل" بسبب التعارض. ونتيجة لذلك، يتم أيضاً تمييز تشغيل تطبيقك المنطقي بحالة "فشل".
تحديد إجراء
ينشئ هذا الإجراء صفيفاً يحتوي على عناصر JSON عن طريق تحويل العناصر من صفيف آخر بناءً على الخريطة المحددة. صفيف الإخراج والصفيف المصدر لها دائماً نفس عدد العناصر. رغم أنه لا يمكنك تغيير عدد العناصر في صفيف الإخراج، إلا إنه يمكنك إضافة أو إزالة الخصائص وقيمها عبر تلك العناصر. تحدد الخاصية select
زوجاً واحداً على الأقل من قيم المفاتيح والقيمة يحدد الخريطة لتحويل العناصر في الصفيف المصدر. يمثل زوج المفتاح والقيمة خاصية وقيمتها عبر جميع العناصر في صفيف الإخراج.
"Select": {
"type": "Select",
"inputs": {
"from": <array>,
"select": {
"<key-name>": "<expression>",
"<key-name>": "<expression>"
}
},
"runAfter": {}
},
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<صفيف> | صفيف | الصفيف أو التعبير الذي يوفر العناصر المصدر. تأكد من إحاطة تعبير بعلامات اقتباس مزدوجة. ملاحظة: إذا كانت الصفيف المصدر فارغاً، يؤدي الإجراء إلى إنشاء صفيف فارغ. |
<key-name> | السلسلة | اسم الخاصية المعين للنتيجة من <التعبير> لإضافة خاصية جديدة عبر جميع العناصر في صفيف الإخراج، قم بتوفير <اسم مفتاح> لهذه الخاصية و<تعبيراً> لـ قيمة الممتلكات. لإزالة خاصية من كافة العناصر في الصفيف، احذف <key-name> لهذه الخاصية. |
<تعبير> | السلسلة | التعبير الذي يحول العنصر في الصفيف المصدر ويعين النتيجة إلى <key-name> |
ينشئ الإجراء Select صفيفاً كمخرجات، لذا يجب أن يقبل أي إجراء يريد استخدام هذا الإخراج إما صفيف، أو يجب عليك تحويل الصفيف إلى النوع الذي يقبله إجراء المستهلك. على سبيل المثال، لتحويل صفيف الإخراج إلى سلسلة، يمكنك تمرير تلك الصفيف إلى الإجراء إنشاء، ثم الرجوع إلى الإخراج من إجراء إنشاء في إجراءاتك الأخرى.
مثال
ينشئ تعريف الإجراء هذا صفيف عنصر JSON من صفيف عدد صحيح. يتكرر الإجراء من خلال الصفيف المصدر، ويحصل على كل قيمة عدد صحيح باستخدام التعبير @item()
، ويخصص كل قيمة للخاصية "number
" في كل عنصر JSON:
"Select": {
"type": "Select",
"inputs": {
"from": [ 1, 2, 3 ],
"select": {
"number": "@item()"
}
},
"runAfter": {}
},
إليك الصفيف التي ينشئها هذا الإجراء:
[ { "number": 1 }, { "number": 2 }, { "number": 3 } ]
لاستخدام ناتج الصفيف هذا في إجراءات أخرى، قم بتمرير هذا الإخراج إلى إجراء إنشاء :
"Compose": {
"type": "Compose",
"inputs": "@body('Select')",
"runAfter": {
"Select": [ "Succeeded" ]
}
},
يمكنك بعد ذلك استخدام الإخراج من إجراء إنشاء في إجراءاتك الأخرى، على سبيل المثال، إجراء Office 365 Outlook - إرسال بريد إلكتروني :
"Send_an_email": {
"type": "ApiConnection",
"inputs": {
"body": {
"Body": "@{outputs('Compose')}",
"Subject": "Output array from Select and Compose actions",
"To": "<your-email@domain>"
},
"host": {
"connection": {
"name": "@parameters('$connections')['office365']['connectionId']"
}
},
"method": "post",
"path": "/Mail"
},
"runAfter": {
"Compose": [ "Succeeded" ]
}
},
إجراء الجدول
يقوم هذا الإجراء بإنشاء جدول CSV أو HTML من صفيف. بالنسبة للصفائف التي تحتوي على عناصر JSON، يقوم هذا الإجراء تلقائياً بإنشاء رؤوس الأعمدة من أسماء خصائص العناصر. بالنسبة للصفائف ذات أنواع البيانات الأخرى، يجب عليك تحديد رؤوس الأعمدة وقيمها. على سبيل المثال، يتضمن هذا الصفيف خصائص "ID" و"Product_Name" التي يمكن لهذا الإجراء استخدامها لأسماء رؤوس الأعمدة:
[ {"ID": 0, "Product_Name": "Apples"}, {"ID": 1, "Product_Name": "Oranges"} ]
"Create_<CSV | HTML>_table": {
"type": "Table",
"inputs": {
"format": "<CSV | HTML>",
"from": <array>,
"columns": [
{
"header": "<column-name>",
"value": "<column-value>"
},
{
"header": "<column-name>",
"value": "<column-value>"
}
]
},
"runAfter": {}
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<CSV أو HTML> | السلسلة | تنسيق الجدول الذي تريد إنشاءه |
<صفيف> | صفيف | الصفيف أو التعبير الذي يوفر العناصر المصدر للجدول ملاحظة: إذا كانت الصفيف المصدر فارغاً، يؤدي الإجراء إلى إنشاء جدول فارغ. |
اختياري
لتحديد أو تخصيص رؤوس الأعمدة والقيم، استخدم الصفيف columns
. عندما يكون لأزواج header-value
نفس اسم الرأس، تظهر قيمها في نفس العمود تحت اسم الرأس هذا. وإلا، فإن كل رأس فريد يحدد عموداً فريداً.
القيمة | النوع | الوصف |
---|---|---|
<column-name> | السلسلة | اسم رأس العمود |
<column-value> | أي | القيمة في هذا العمود |
مثال 1
لنفترض أن لديك متغير "myItemArray" تم إنشاؤه مسبقاً ويحتوي حالياً على هذا الصفيف:
[ {"ID": 0, "Product_Name": "Apples"}, {"ID": 1, "Product_Name": "Oranges"} ]
يقوم تعريف الإجراء هذا بإنشاء جدول CSV من المتغير "myItemArray". يحصل التعبير الذي تستخدمه الخاصية from
على الصفيف من "myItemArray" باستخدام الدالة variables()
:
"Create_CSV_table": {
"type": "Table",
"inputs": {
"format": "CSV",
"from": "@variables('myItemArray')"
},
"runAfter": {}
}
إليك جدول CSV الذي ينشئه هذا الإجراء:
ID,Product_Name
0,Apples
1,Oranges
مثال 2
يقوم تعريف الإجراء هذا بإنشاء جدول HTML من المتغير "myItemArray". يحصل التعبير الذي تستخدمه الخاصية from
على الصفيف من "myItemArray" باستخدام الدالة variables()
:
"Create_HTML_table": {
"type": "Table",
"inputs": {
"format": "HTML",
"from": "@variables('myItemArray')"
},
"runAfter": {}
}
إليك جدول HTML الذي ينشئه هذا الإجراء:
بطاقة تعريف | اسم المنتج |
---|---|
0 | Apples |
1 | Oranges |
مثال 3
يقوم تعريف الإجراء هذا بإنشاء جدول HTML من المتغير "myItemArray". ومع ذلك، يتجاوز هذا المثال أسماء رؤوس الأعمدة الافتراضية بـ "Stock_ID" و"الوصف"، ويضيف كلمة "عضوي" إلى القيم الموجودة في عمود "الوصف".
"Create_HTML_table": {
"type": "Table",
"inputs": {
"format": "HTML",
"from": "@variables('myItemArray')",
"columns": [
{
"header": "Stock_ID",
"value": "@item().ID"
},
{
"header": "Description",
"value": "@concat('Organic ', item().Product_Name)"
}
]
},
"runAfter": {}
},
إليك جدول HTML الذي ينشئه هذا الإجراء:
معرف_المخزون | الوصف |
---|---|
0 | تفاح عضوي |
1 | البرتقال العضوي |
إنهاء العمل
يوقف هذا الإجراء تشغيل مثيل سير العمل، ويلغي أي إجراءات قيد التقدم، ويتخطى أي إجراءات متبقية، ويعيد الحالة المحددة. على سبيل المثال، يمكنك استخدام إجراء إنهاء عندما يجب أن يخرج تطبيقك المنطقي تماماً من حالة خطأ. لا يؤثر هذا الإجراء في الإجراءات المكتملة بالفعل ولا يمكن أن يظهر داخل حلقات Foreach وUntil، بما في ذلك الحلقات المتسلسلة.
"Terminate": {
"type": "Terminate",
"inputs": {
"runStatus": "<status>",
"runError": {
"code": "<error-code-or-name>",
"message": "<error-message>"
}
},
"runAfter": {}
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<الحالة> | السلسلة | الحالة المراد إرجاعها للتشغيل: "فشل" أو "تم الإلغاء" أو "تم النجاح" |
اختياري
تنطبق خصائص العنصر "runStatus" فقط عند تعيين خاصية "runStatus" إلى الحالة "فشل".
القيمة | النوع | الوصف |
---|---|---|
<error-code-or-name> | السلسلة | تعليمة برمجية أو اسم الخطأ |
<رسالة خطأ> | السلسلة | الرسالة أو النص الذي يصف الخطأ وأي إجراءات يمكن لمستخدم التطبيق اتخاذها |
مثال
يعمل تعريف الإجراء هذا على إيقاف تشغيل سير العمل، وتعيين حالة التشغيل على "فشل"، وإرجاع الحالة، ورمز الخطأ، ورسالة الخطأ:
"Terminate": {
"type": "Terminate",
"inputs": {
"runStatus": "Failed",
"runError": {
"code": "Unexpected response",
"message": "The service received an unexpected response. Please try again."
}
},
"runAfter": {}
}
انتظر العمل
يوقف هذا الإجراء تنفيذ سير العمل مؤقتاً للفاصل الزمني المحدد أو حتى الوقت المحدد، ولكن ليس لكليهما.
الفاصل الزمني المحدد
"Delay": {
"type": "Wait",
"inputs": {
"interval": {
"count": <number-of-units>,
"unit": "<interval>"
}
},
"runAfter": {}
},
الوقت المحدد
"Delay_until": {
"type": "Wait",
"inputs": {
"until": {
"timestamp": "<date-time-stamp>"
}
},
"runAfter": {}
},
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<عدد الوحدات> | رقم صحيح | بالنسبة إلى إجراء Delay، عدد الوحدات المطلوب انتظارها |
<الفاصل الزمني> | السلسلة | بالنسبة إلى إجراء التأخير، فاصل الانتظار: "الثانية"، "الدقيقة"، "الساعة"، "اليوم"، "الأسبوع"، "الشهر" |
<طابع التاريخ والوقت> | السلسلة | بالنسبة إلى إجراء التأخير حتى، تاريخ ووقت استئناف التنفيذ. يجب أن تستخدم هذه القيمة تنسيق وقت تاريخ UTC. |
مثال 1
يعمل تعريف الإجراء هذا على إيقاف سير العمل مؤقتاً لمدة 15 دقيقة:
"Delay": {
"type": "Wait",
"inputs": {
"interval": {
"count": 15,
"unit": "Minute"
}
},
"runAfter": {}
},
مثال 2
يعمل تعريف الإجراء هذا على إيقاف سير العمل مؤقتاً حتى الوقت المحدد:
"Delay_until": {
"type": "Wait",
"inputs": {
"until": {
"timestamp": "2017-10-01T00:00:00Z"
}
},
"runAfter": {}
},
إجراء سير العمل
يستدعي هذا الإجراء تطبيقاً منطقياً آخر تم إنشاؤه مسبقاً، ما يعني أنه يمكنك تضمين وإعادة استخدام مهام سير عمل التطبيق المنطقي الأخرى. يمكنك أيضاً استخدام المخرجات من التطبيق الفرعي أو التطبيق المنطقي المدمج في الإجراءات التي تتبع التطبيق المنطقي المتداخل، بشرط أن يعرض التطبيق المنطقي الفرعي استجابة.
تتحقق Azure Logic Apps من الوصول إلى المشغل الذي تريد الاتصال به، لذا تأكد من أنه يمكنك الوصول إلى هذا المشغل. أيضاً، يجب أن يفي التطبيق المنطقي المتداخل بهذه المعايير:
المشغل يجعل التطبيق المنطقي المتداخل قابلاً للاستدعاء، مثل مشغل طلب أو HTTP
نفس اشتراك Azure مثل التطبيق المنطقي الأصلي
لاستخدام المخرجات من التطبيق المنطقي المتداخل في التطبيق المنطقي الرئيسي، يجب أن يحتوي التطبيق المنطقي المتداخل على إجراء استجابة
"<nested-logic-app-name>": {
"type": "Workflow",
"inputs": {
"body": { "<body-content" },
"headers": { "<header-content>" },
"host": {
"triggerName": "<trigger-name>",
"workflow": {
"id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group>/providers/Microsoft.Logic/<nested-logic-app-name>"
}
}
},
"runAfter": {}
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<nested-logic-app-name> | السلسلة | اسم التطبيق المنطقي الذي تريد الاتصال به |
<trigger-name> | السلسلة | اسم المشغل في التطبيق المنطقي المتداخل الذي تريد الاتصال به |
<معرف اشتراك Azure> | السلسلة | معرف اشتراك Azure للتطبيق المنطقي المتداخل |
<مجموعة موارد Azure> | السلسلة | اسم مجموعة موارد Azure للتطبيق المنطقي المتداخل |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<header-content> | كائن JSON | أي رؤوس لإرسالها مع المكالمة |
<محتوى الجسم> | كائن JSON | أي محتوى رسالة لإرساله مع المكالمة |
النواتج
تختلف مخرجات هذا الإجراء بناءً على إجراء استجابة التطبيق المنطقي المتداخل. إذا كان التطبيق المنطقي المتداخل لا يتضمن إجراء استجابة، فإن المخرجات تكون فارغة.
مثال
بعد انتهاء إجراء "Start_search" بنجاح، يستدعي تعريف إجراء سير العمل هذا تطبيقاً منطقياً آخر يسمى "Get_product_information"، والذي يمر في المدخلات المحددة:
"actions": {
"Start_search": { <action-definition> },
"Get_product_information": {
"type": "Workflow",
"inputs": {
"body": {
"ProductID": "24601",
},
"host": {
"id": "/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/InventoryManager-RG/providers/Microsoft.Logic/Get_product_information",
"triggerName": "Find_product"
},
"headers": {
"content-type": "application/json"
}
},
"runAfter": {
"Start_search": [ "Succeeded" ]
}
}
},
التحكم في تفاصيل إجراءات سير العمل
عمل Foreach
يتكرر إجراء التكرار هذا عبر صفيف وينفذ إجراءات على كل عنصر صفيف. بشكل افتراضي، تعمل حلقة "for each" بالتوازي حتى أقصى عدد من الحلقات. لهذا الحد الأقصى، راجع الحدود والتكوين. تعرف على كيفية إنشاء حلقات "لكل".
"For_each": {
"type": "Foreach",
"actions": {
"<action-1>": { "<action-definition-1>" },
"<action-2>": { "<action-definition-2>" }
},
"foreach": "<for-each-expression>",
"runAfter": {},
"runtimeConfiguration": {
"concurrency": {
"repetitions": <count>
}
},
"operationOptions": "<operation-option>"
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<إجراء -1...n> | السلسلة | أسماء الإجراءات التي يتم تشغيلها على كل عنصر صفيف |
<action-definition-1...n> | كائن JSON | تعريفات الإجراءات التي يتم تشغيلها |
<for-each-expression> | السلسلة | التعبير الذي يشير إلى كل عنصر في الصفيف المحدد |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<count> | رقم صحيح | بشكل افتراضي، يتم تشغيل تكرار الحلقات "لكل" في نفس الوقت (بشكل متزامن أو بالتوازي) حتى الحد الافتراضي. لتغيير هذا الحد عن طريق تعيين قيمة جديدة <count>، راجع تغيير "لكل" حلقة التزامن. |
<operation-option> | السلسلة | لتشغيل حلقة "لكل" بشكل تسلسلي، بدلاً من التوازي، عيّن إما <operation-option> على Sequential أو <count> إلى 1 ، ولكن ليس كليهما. لمزيد من المعلومات، راجع تشغيل "لكل" حلقات بالتتابع. |
مثال
ترسل حلقة "لكل" رسالة بريد إلكتروني لكل عنصر في الصفيف، والتي تحتوي على مرفقات من بريد إلكتروني وارد. الحلقة ترسل بريداً إلكترونياً، بما في ذلك المرفق، إلى الشخص الذي يراجع المرفق.
"For_each": {
"type": "Foreach",
"actions": {
"Send_an_email": {
"type": "ApiConnection",
"inputs": {
"body": {
"Body": "@base64ToString(items('For_each')?['Content'])",
"Subject": "Review attachment",
"To": "Sophie.Owen@contoso.com"
},
"host": {
"connection": {
"id": "@parameters('$connections')['office365']['connectionId']"
}
},
"method": "post",
"path": "/Mail"
},
"runAfter": {}
}
},
"foreach": "@triggerBody()?['Attachments']",
"runAfter": {}
}
لتحديد صفيف تم تمريرها كناتج من المشغل فقط، يحصل هذا التعبير على صفيف <اسم الصفيف> من جسم المشغل. لتجنب الفشل في حالة عدم وجود الصفيف، يستخدم التعبير عامل التشغيل ?
:
@triggerBody()?['<array-name>']
إذا كان العمل
يقوم هذا الإجراء، وهو عبارة شرطية، بتقييم تعبير يمثل شرطاً ويقوم بتشغيل فرع مختلف بناءً على ما إذا كان الشرط صحيحاً أم خطأ. إذا كان الشرط صحيحاً، يتم تمييز الحالة بحالة "تم النجاح". تعرف على كيفية إنشاء جمل شرطية.
"Condition": {
"type": "If",
"expression": { "<condition>" },
"actions": {
"<action-1>": { "<action-definition>" }
},
"else": {
"actions": {
"<action-2>": { "<action-definition" }
}
},
"runAfter": {}
}
القيمة | النوع | الوصف |
---|---|---|
<condition> | كائن JSON | الشرط، الذي يمكن أن يكون تعبيراً، للتقييم |
<action-1> | كائن JSON | الإجراء الذي يتم تشغيله عند تقييم <الشرط> إلى true |
<action-definition> | كائن JSON | تعريف العمل |
<action-2> | كائن JSON | الإجراء الذي يتم تشغيله عند تقييم <الشرط> إلى خطأ |
تحصل الإجراءات في العناصر actions
أو else
على هذه الحالات:
- "نجحوا" عندما يجرون وينجحون
- "فشل" عندما يجرون ويفشلون
- "تم التخطي" عندما لا يعمل الفرع المعني
مثال
يحدد هذا الشرط أنه عندما يكون لمتغير العدد الصحيح قيمة أكبر من الصفر، يتحقق سير العمل من موقع ويب. إذا كان المتغير صفراً أو أقل، يتحقق سير العمل من موقع ويب مختلف.
"Condition": {
"type": "If",
"expression": {
"and": [ {
"greater": [ "@variables('myIntegerVariable')", 0 ]
} ]
},
"actions": {
"HTTP - Check this website": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "http://this-url"
},
"runAfter": {}
}
},
"else": {
"actions": {
"HTTP - Check this other website": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "http://this-other-url"
},
"runAfter": {}
}
}
},
"runAfter": {}
}
كيف تستخدم الشروط التعبيرات
فيما يلي بعض الأمثلة التي توضح كيف يمكنك استخدام التعبيرات في الشروط:
JSON | نتيجة |
---|---|
"expression": "@parameters('<hasSpecialAction>')" | بالنسبة للتعبيرات المنطقية فقط، يمر الشرط لأي قيمة يتم تقييمها على صواب. لتحويل الأنواع الأخرى إلى Boolean، استخدم هاتين الدالتين: empty() أو equals() . |
"expression": "@greater(actions('<action>').output.value, parameters('<threshold>'))" | بالنسبة إلى وظائف المقارنة، يتم تشغيل الإجراء فقط عندما يكون الناتج من <الإجراء> أكبر من قيمة <الحد>. |
"تعبير": "or (أكبر (إجراءات ('<إجراء>'). output.value، معلمات ('<حد>' ))، أقل (الإجراءات ('<نفس الإجراء>'). output.value، 100)) " | بالنسبة إلى الوظائف المنطقية وإنشاء التعبيرات المنطقية المتداخلة، يتم تشغيل الإجراء عندما يكون الناتج من <الإجراء> أكبر من قيمة <الحد> أو أقل من 100. |
"تعبير": "@equals(length(actions('<action>').outputs.errors), 0)" | يمكنك استخدام وظائف الصفيف للتحقق مما إذا كان الصفيف يحتوي على أي عناصر. يتم تشغيل الإجراء عندما يكون الصفيف errors فارغاً. |
عمل النطاق
يعمل هذا الإجراء على تجميع الإجراءات منطقياً في نطاقات، والتي تحصل على حالتها الخاصة بعد انتهاء تشغيل الإجراءات في هذا النطاق. يمكنك بعد ذلك استخدام حالة النطاق لتحديد ما إذا كان سيتم تشغيل الإجراءات الأخرى أم لا. تعرف على كيفية إنشاء النطاقات.
"Scope": {
"type": "Scope",
"actions": {
"<inner-action-1>": {
"type": "<action-type>",
"inputs": { "<action-inputs>" },
"runAfter": {}
},
"<inner-action-2>": {
"type": "<action-type>",
"inputs": { "<action-inputs>" },
"runAfter": {}
}
}
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<inner-action-1...n> | كائن JSON | إجراء واحد أو أكثر يتم تشغيله داخل النطاق |
<action-inputs> | كائن JSON | المدخلات لكل عمل |
إجراء Switch
هذا الإجراء، المعروف أيضاً باسم بيان التبديل، ينظم الإجراءات الأخرى في حالات، ويعين قيمة لكل حالة، باستثناء الحالة الافتراضية إن وجدت. عند تشغيل سير العمل، يقارن الإجراء Switch القيمة من تعبير أو عنصر أو رمز مميز بالقيم المحددة لكل حالة. إذا عثر إجراء التبديل على حالة مطابقة، فسيؤدي سير العمل الخاص بك إلى تشغيل الإجراءات الخاصة بهذه الحالة فقط. في كل مرة يتم فيها تشغيل إجراء التبديل، توجد حالة مطابقة واحدة فقط أو لا توجد مطابقات. في حالة عدم وجود مطابقات، يقوم إجراء التبديل بتشغيل الإجراءات الافتراضية. تعرف على كيفية إنشاء عبارات التحويل.
"Switch": {
"type": "Switch",
"expression": "<expression-object-or-token>",
"cases": {
"Case": {
"actions": {
"<action-name>": { "<action-definition>" }
},
"case": "<matching-value>"
},
"Case_2": {
"actions": {
"<action-name>": { "<action-definition>" }
},
"case": "<matching-value>"
}
},
"default": {
"actions": {
"<default-action-name>": { "<default-action-definition>" }
}
},
"runAfter": {}
}
مطلوب
القيمة | النوع | الوصف |
---|---|---|
<expression-object-or-token> | يتفاوت | التعبير أو عنصر JSON أو الرمز المراد تقييمه |
<اسم الإجراء> | السلسلة | اسم الإجراء المراد تشغيله للحالة المطابقة |
<action-definition> | كائن JSON | تعريف الإجراء المراد تشغيله لحالة المطابقة |
<matching-value> | يتفاوت | القيمة المطلوب مقارنتها بالنتيجة المقيمة |
اختياري
القيمة | النوع | الوصف |
---|---|---|
<اسم الإجراء الافتراضي> | السلسلة | اسم الإجراء الافتراضي الذي يتم تشغيله عند عدم وجود حالة مطابقة |
<تعريف الإجراء الافتراضي> | كائن JSON | تعريف الإجراء الذي سيتم تشغيله في حالة عدم وجود حالة مطابقة |
مثال
يعمل تعريف الإجراء هذا على تقييم ما إذا كان الشخص الذي قام بالرد على البريد الإلكتروني لطلب الموافقة قد حدد خيار "الموافقة" أو خيار "الرفض". بناءً على هذا الاختيار، يقوم إجراء التبديل بتشغيل الإجراءات الخاصة بحالة المطابقة، والتي تتمثل في إرسال بريد إلكتروني آخر إلى المستجيب ولكن بصياغة مختلفة في كل حالة.
"Switch": {
"type": "Switch",
"expression": "@body('Send_approval_email')?['SelectedOption']",
"cases": {
"Case": {
"actions": {
"Send_an_email": {
"type": "ApiConnection",
"inputs": {
"Body": "Thank you for your approval.",
"Subject": "Response received",
"To": "Sophie.Owen@contoso.com"
},
"host": {
"connection": {
"name": "@parameters('$connections')['office365']['connectionId']"
}
},
"method": "post",
"path": "/Mail"
},
"runAfter": {}
},
"case": "Approve"
},
"Case_2": {
"actions": {
"Send_an_email_2": {
"type": "ApiConnection",
"inputs": {
"Body": "Thank you for your response.",
"Subject": "Response received",
"To": "Sophie.Owen@contoso.com"
},
"host": {
"connection": {
"name": "@parameters('$connections')['office365']['connectionId']"
}
},
"method": "post",
"path": "/Mail"
},
"runAfter": {}
},
"case": "Reject"
}
},
"default": {
"actions": {
"Send_an_email_3": {
"type": "ApiConnection",
"inputs": {
"Body": "Please respond with either 'Approve' or 'Reject'.",
"Subject": "Please respond",
"To": "Sophie.Owen@contoso.com"
},
"host": {
"connection": {
"name": "@parameters('$connections')['office365']['connectionId']"
}
},
"method": "post",
"path": "/Mail"
},
"runAfter": {}
}
},
"runAfter": {
"Send_approval_email": [
"Succeeded"
]
}
}
حتى العمل
يحتوي إجراء الحلقة هذا على الإجراءات التي يتم تشغيلها حتى تحقق الشرط المحدد. تتحقق الحلقة من الشرط كخطوة أخيرة بعد تشغيل جميع الإجراءات الأخرى. يمكنك تضمين أكثر من إجراء واحد في عنصر "actions"
، ويجب أن يحدد الإجراء حداً واحداً على الأقل. تعرف على كيفية إنشاء حلقات "حتى".
"Until": {
"type": "Until",
"actions": {
"<action-name>": {
"type": "<action-type>",
"inputs": { "<action-inputs>" },
"runAfter": {}
},
"<action-name>": {
"type": "<action-type>",
"inputs": { "<action-inputs>" },
"runAfter": {}
}
},
"expression": "<condition>",
"limit": {
"count": <loop-count>,
"timeout": "<loop-timeout>"
},
"runAfter": {}
}
القيمة | النوع | الوصف |
---|---|---|
<اسم الإجراء> | السلسلة | اسم الإجراء الذي تريد تشغيله داخل الحلقة |
<نوع الإجراء> | السلسلة | نوع الإجراء الذي تريد تشغيله |
<action-inputs> | مختلف | مدخلات للعمل للتشغيل |
<condition> | السلسلة | الشرط أو التعبير المراد تقييمه بعد انتهاء تشغيل جميع الإجراءات في الحلقة |
<lعدد الحلقات> | رقم صحيح | الحد الأقصى لعدد الحلقات التي يمكن للإجراء تشغيلها. لمزيد من المعلومات بشأن الحد الأقصى والحد الأقصى الافتراضي، راجع الحدود والتكوين لـ Azure Logic Apps. |
<loop-timeout> | السلسلة | الحد الأقصى لأطول وقت يمكن تشغيل الحلقة فيه. القيمة الافتراضية timeout هي PT1H ، وهي تنسيق ISO 8601المطلوب. |
إشعار
إذا كان التعبير يعتمد على الإخراج من أي إجراء داخل الحلقة حتى، فتأكد من حساب أي فشل ناتج عن هذا الإجراء.
مثال
يرسل تعريف إجراء الحلقة هذا طلب HTTP إلى عنوان URL المحدد حتى يتم استيفاء أحد الشروط التالية:
- يحصل الطلب على استجابة بتعليمة برمجية الحالة "200 OK".
- تم تشغيل الحلقة 60 مرة.
- الحلقة تعمل لمدة ساعة واحدة.
"Run_until_loop_succeeds_or_expires": {
"type": "Until",
"actions": {
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "http://myurl"
},
"runAfter": {}
}
},
"expression": "@equals(outputs('HTTP')['statusCode'], 200)",
"limit": {
"count": 60,
"timeout": "PT1H"
},
"runAfter": {}
}
Webhooks والاشتراكات
لا تتحقق المشغلات والإجراءات المستندة إلى Webhook من نقاط النهاية بانتظام، ولكن تنتظر أحداثاً أو بيانات معينة في نقاط النهاية هذه بدلاً من ذلك. هذه المشغلات والإجراءات تشترك في نقاط النهاية من خلال توفير عنوان URL لمعاودة الاتصال حيث يمكن لنقطة النهاية إرسال ردود.
يحدث استدعاء subscribe
عندما يتغير سير العمل بأي طريقة، على سبيل المثال، عندما يتم تجديد معلومات تسجيل الدخول، أو عندما تتغير معلمات الإدخال لمشغل أو إجراء. يستخدم هذا الاستدعاء نفس عمليات إجراءات HTTP القياسية.
تحدث المكالمة unsubscribe
تلقائياً عندما تجعل العملية المشغل أو الإجراء غير صالح، على سبيل المثال:
- حذف أو تعطيل الزناد.
- حذف أو تعطيل سير العمل.
- حذف أو تعطيل الاشتراك.
لدعم هذه الاستدعاءات، يعرض التعبير @listCallbackUrl()
"عنوان URL لمعاودة الاتصال" فريداً للمشغل أو الإجراء. يمثل عنوان URL هذا معرفاً فريداً لنقاط النهاية التي تستخدم واجهة برمجة تطبيقات REST الخاصة بالخدمة. معلمات هذه الوظيفة هي نفسها مشغل أو إجراء خطاف الويب.
تغيير المدة غير المتزامنة
لكل من المشغلات والإجراءات، يمكنك قصر مدة النمط غير المتزامن على فترة زمنية محددة عن طريق إضافة خاصية limit.timeout
. بهذه الطريقة، إذا لم ينته الإجراء عند انقضاء الفاصل الزمني، يتم وضع علامة على حالة الإجراء على أنها Cancelled
مع تعليمة برمجية ActionTimedOut
. تستخدم الخاصية timeout
تنسيق ISO 8601.
"<trigger-or-action-name>": {
"type": "Workflow | Webhook | Http | ApiConnectionWebhook | ApiConnection",
"inputs": {},
"limit": {
"timeout": "PT10S"
},
"runAfter": {}
}
إعدادات تكوين وقت التشغيل
يمكنك تغيير سلوك وقت التشغيل الافتراضي للمشغلات والإجراءات عن طريق إضافة هذه الخصائص runtimeConfiguration
إلى تعريف المشغل أو الإجراء.
الخاصية | نوع | الوصف | الزناد أو الإجراء |
---|---|---|---|
runtimeConfiguration.concurrency.runs |
رقم صحيح | قم بتغيير الحد الافتراضي على عدد مثيلات سير العمل التي يمكن تشغيلها في نفس الوقت (بشكل متزامن أو متوازٍ). يمكن أن يساعد تعديل هذه القيمة في الحد من عدد الطلبات التي تتلقاها أنظمة الواجهة الخلفية. يعمل تعيين الخاصية runs على 1 بنفس طريقة تعيين الخاصية operationOptions على SingleInstance . يمكنك تعيين أي من الخاصيتين، ولكن ليس كليهما. لتغيير الحد الافتراضي، راجع تغيير التزامن المشغل أو تشغيل المثيلات بالتتابع. |
كل المشغلات |
runtimeConfiguration.concurrency.maximumWaitingRuns |
رقم صحيح | غيّر الحد الافتراضي على عدد مثيلات سير العمل التي يجب أن تنتظر للتشغيل عندما يقوم تطبيقك المنطقي بالفعل بتشغيل الحد الأقصى من المثيلات المتزامنة. لتغيير الحد الافتراضي، راجع تغيير حد فترات الانتظار. |
كل المشغلات |
runtimeConfiguration.concurrency.repetitions |
رقم صحيح | غيّر الحد الافتراضي على عدد التكرارات "لكل" حلقة يمكن تشغيلها في نفس الوقت (بشكل متزامن أو متوازٍ). يعمل تعيين الخاصية repetitions على 1 بنفس طريقة تعيين الخاصية operationOptions على SingleInstance . يمكنك تعيين أي من الخاصيتين، ولكن ليس كليهما. لتغيير الحد الافتراضي، راجع تغيير "لكل" تزامن أو تشغيل "لكل" حلقات متسلسلة. |
الإجراء: Foreach |
runtimeConfiguration.paginationPolicy.minimumItemCount |
رقم صحيح | بالنسبة للإجراءات المحددة التي تدعم ترقيم الصفحات وتم تشغيلها، تحدد هذه القيمة الحد الأدنى من عدد النتائج لاستردادها. لتشغيل ترقيم الصفحات، راجع الحصول على بيانات أو عناصر أو نتائج مجمعة باستخدام ترقيم الصفحات |
العمل: متنوع |
runtimeConfiguration.secureData.properties |
صفيف | في العديد من المشغلات والإجراءات، تخفي هذه الإعدادات المدخلات أو المخرجات أو كليهما من سجل تشغيل تطبيق المنطق. لمعرفة المزيد بشأن حماية هذه البيانات، راجع إخفاء المدخلات والمخرجات من سجل التشغيل. |
معظم المحفزات والأفعال |
runtimeConfiguration.staticResult |
كائن JSON | بالنسبة للإجراءات التي تدعم إعداد النتيجة الثابتة وتشغيله، يحتوي العنصر على staticResult هذه السمات:- name ، الذي يشير إلى اسم تعريف النتيجة الثابت للإجراء الحالي، والذي يظهر داخل السمة staticResults في سمة definition لسير عمل التطبيق المنطقي. لمزيد من المعلومات، راجع النتائج الثابتة - مرجع المخطط للغة تعريف سير العمل. - staticResultOptions ، والتي تحدد ما إذا كانت النتائج الثابتة Enabled للإجراء الحالي أم لا. لتشغيل النتائج الثابتة، راجع اختبار التطبيقات المنطقية باستخدام بيانات وهمية عن طريق إعداد نتائج ثابتة |
العمل: متنوع |
خيارات العملية
يمكنك تغيير السلوك الافتراضي للمشغلات والإجراءات باستخدام الخاصية operationOptions
في تعريف المشغل أو الإجراء.
خيار التشغيل | النوع | الوصف | الزناد أو الإجراء |
---|---|---|---|
DisableAsyncPattern |
السلسلة | قم بتشغيل الإجراءات المستندة إلى HTTP بشكل متزامن، بدلاً من تشغيلها بشكل غير متزامن. لتعيين هذا الخيار، راجع تشغيل الإجراءات بشكل متزامن. |
الاجراءات: Api الاتصال ion، HTTP، Response |
IncludeAuthorizationHeadersInOutputs |
السلسلة | بالنسبة لتطبيقات المنطق التي تمكن OAuth باستخدام معرف Microsoft Entra لتخويل الوصول إلى المكالمات الواردة إلى نقطة نهاية المشغل المستندة إلى الطلب، قم بتضمين Authorization العنوان من الرمز المميز للوصول إلى OAuth في مخرجات المشغل. لمزيد من المعلومات، راجع تضمين رأس "التخويل" في مخرجات تشغيل الطلب. |
مشغلات: طلب، HTTP Webhook |
Sequential |
السلسلة | قم بتشغيل "لكل" تكرار حلقة واحدة تلو الأخرى، بدلاً من الكل في نفس الوقت بالتوازي. يعمل هذا الخيار بنفس طريقة تعيين خاصية runtimeConfiguration.concurrency.repetitions على 1 . يمكنك تعيين أي من الخاصيتين، ولكن ليس كليهما. لتعيين هذا الخيار، راجع تشغيل "لكل" حلقات بالتتابع. |
الإجراء: Foreach |
SingleInstance |
السلسلة | قم بتشغيل المشغل لكل مثيل تطبيق منطقي بالتتابع وانتظر انتهاء التشغيل النشط سابقاً قبل تشغيل مثيل التطبيق المنطقي التالي. يعمل هذا الخيار بنفس طريقة تعيين خاصية runtimeConfiguration.concurrency.runs على 1 . يمكنك تعيين أي من الخاصيتين، ولكن ليس كليهما. لتعيين هذا الخيار، راجع تشغيل المثيلات بالتتابع. |
كل المشغلات |
SuppressWorkflowHeaders |
السلسلة | لا ترسل x-ms-* رؤوس بيانات تعريف في الطلبات الصادرة. بشكل افتراضي، تتضمن Azure Logic Apps رؤوس بيانات تعريف إضافية مع البادئة x-ms- في اسم الرأس كجزء من الطلبات الصادرة. ومع ذلك، لن تقبل بعض الخدمات القديمة الطلبات ذات الرؤوس الإضافية غير المعروفة، ما يؤدي إلى فشل الطلبات. |
الاجراءات: HTTP، دالة، APIManagement |
SuppressWorkflowHeadersOnResponse |
السلسلة | لا ترسل x-ms-* رؤوس بيانات تعريف رداً على طلبات التشغيل الواردة. بشكل افتراضي، يرسل Azure Logic Apps استجابات للطلبات الواردة التي تتضمن عناوين بيانات تعريف إضافية مع البادئة x-ms- في اسم العنوان. ومع ذلك، لن تقبل بعض الخدمات القديمة الطلبات أو الاستجابات ذات الرؤوس الإضافية غير المعروفة، ما يؤدي إلى فشل الطلبات. |
مشغلات: طلب، HTTP Webhook |
تغيير المشغل التزامن
بشكل افتراضي، تعمل جميع مثيلات سير عمل التطبيق المنطقي في نفس الوقت (بشكل متزامن أو بالتوازي). يعني هذا السلوك أن كل مثيل مشغل يتم تشغيله قبل انتهاء تشغيل مثيل سير العمل النشط سابقاً. ومع ذلك، فإن عدد المثيلات التي يتم تشغيلها بشكل متزامن له حد افتراضي. عندما يصل عدد مثيلات سير العمل التي يتم تشغيلها بشكل متزامن إلى هذا الحد، يجب أن تنتظر أي مثيلات جديدة أخرى للتشغيل. يساعد هذا الحد في التحكم في عدد الطلبات التي تتلقاها الأنظمة الخلفية.
عند تشغيل عنصر تحكم التزامن الخاص بالمشغل، يتم تشغيل المثيلات بالتوازي مع الحد الافتراضي. لتغيير حد التزامن الافتراضي هذا، يمكنك استخدام إما محرر عرض التعليمات البرمجية أو مصمم سير العمل لأن تغيير إعداد التزامن من خلال المصمم يضيف الخاصية في تعريف المشغل الأساسي أو يحدثها runtimeConfiguration.concurrency.runs
والعكس صحيح. تتحكم هذه الخاصية في الحد الأقصى لعدد مثيلات سير العمل الجديدة التي يمكن تشغيلها بالتوازي.
قبل تمكين التزامن على مشغل، راجع الاعتبارات التالية:
لا يمكنك تعطيل التزامن بعد تمكين التحكم في التزامن.
إذا وصل الحد الأقصى لعدد عمليات تشغيل المشغل المتزامنة إلى الحد الأقصى لدرجة التوازي، فقد تواجه عمليات تشغيل المشغل اللاحقة أخطاء تقييد أو "429 - طلبات كثيرة جدا". إذا قمت بإعداد نهج إعادة المحاولة الذي يعالج 429 خطأ، فقد يواجه المشغل دورة من سلوك إعادة المحاولة والتقييد الذي يسبب تأخيرات طويلة في معالجة طلبات المشغل الجديدة.
عند تمكين التزامن، يتم تقليل حد SplitOn بشكل ملحوظ لصفائف التصحيح. إذا تجاوز عدد العناصر هذا الحد، فسيتم تعطيل إمكانية SplitOn.
عند تمكين التزامن، قد يتسبب مثيل تطبيق منطقي طويل التشغيل في دخول مثيلات تطبيق منطقي جديدة في حالة انتظار. تمنع هذه الحالة Azure Logic Apps من إنشاء مثيلات جديدة وتحدث حتى عندما يكون عدد عمليات التشغيل المتزامنة أقل من الحد الأقصى المحدد لعدد مرات التشغيل المتزامنة.
لمقاطعة هذه الحالة، قم بإلغاء أقدم المثيلات التي لا تزال قيد التشغيل.
في قائمة تطبيق المنطق، حدد Overview.
في قسم Runs history، حدد أول مثيل لا يزال قيد التشغيل، على سبيل المثال:
تلميح
لعرض المثيلات التي لا تزال قيد التشغيل فقط، افتح قائمة All، وحدد Running.
ضمن Logic app run، حدد Cancel run.
للتغلب على هذا الاحتمال، أضف مهلة إلى أي إجراء قد يعيق عمليات التشغيل هذه. إذا كنت تعمل في محرر التعليمة البرمجية، فراجع تغيير المدة غير المتزامنة. بخلاف ذلك، إذا كنت تستخدم المصمم، فاتبع الخطوات التالية:
في سير عمل تطبيق المنطق، حدد الإجراء الذي تريد إضافة مهلة فيه. في الزاوية العلوية اليمنى للإجراء، حدد زر الحذف (...)، ثم حدد Settings.
ضمن Timeout، حدد مدة المهلة ISO 8601 format.
لتشغيل تطبيقك المنطقي بشكل تسلسلي، عيّن تزامن المشغل على
1
إما باستخدام محرر عرض التعليمة البرمجية أو المصمم. تأكد أيضاً من عدم تعيين خاصية المشغلoperationOptions
علىSingleInstance
في محرر عرض التعليمة البرمجية. خلاف ذلك، تحصل على خطأ في التحقق من الصحة. لمزيد من المعلومات، راجع تشغيل المثيلات بالتتابع.
تحرير في عرض التعليمة البرمجية
في تعريف المشغل الأساسي، أضف الخاصية runtimeConfiguration.concurrency.runs
، وعيِّن القيمة بناءً على حدود التزامن المشغل. لتشغيل سير العمل الخاص بك بشكل تسلسلي، قم بتعيين قيمة الخاصية إلى 1
.
يحد هذا المثال من عمليات التشغيل المتزامنة إلى 10 حالات:
"<trigger-name>": {
"type": "<trigger-name>",
"recurrence": {
"frequency": "<time-unit>",
"interval": <number-of-time-units>,
},
"runtimeConfiguration": {
"concurrency": {
"runs": 10
}
}
}
لمزيد من المعلومات، راجع إعدادات تكوين وقت التشغيل.
التحرير في مصمم سير العمل
في الزاوية العلوية اليمنى للمشغل، حدد زر الحذف (...)، ثم حدد Settings.
ضمن Concurrency Control، عيّن Limit على On.
اسحب شريط التمرير درجة التوازي إلى القيمة التي تريدها. لتشغيل التطبيق المنطقي بشكل تسلسلي، اسحب قيمة شريط التمرير إلى 1.
تغيير "لكل" التزامن
بشكل افتراضي، يتم تشغيل جميع التكرارات "لكل" حلقة في نفس الوقت (بشكل متزامن أو بالتوازي). يعني هذا السلوك أن كل تكرار يبدأ تشغيله قبل انتهاء تشغيل التكرار السابق. ومع ذلك، فإن عدد عمليات التكرار التي تعمل في نفس الوقت له حد افتراضي. عندما يصل عدد التكرارات التي يتم تشغيلها بشكل متزامن إلى هذا الحد، يجب أن تنتظر أي تكرارات أخرى للتشغيل.
لتغيير الحد الافتراضي، يمكنك استخدام محرر عرض التعليمات runtimeConfiguration.concurrency.repetitions
البرمجية أو مصمم سير العمل لأن تغيير إعداد التزامن من خلال المصمم يضيف الخاصية أو يحدثها في تعريف الإجراء الأساسي "لكل" والعكس صحيح. تتحكم هذه الخاصية في الحد الأقصى لعدد التكرارات التي يمكن تشغيلها بالتوازي.
إشعار
إذا قمت بتعيين إجراء "لكل" ليتم تشغيله بالتتابع إما باستخدام المصمم أو محرر عرض التعليمة البرمجية، فلا تقم بتعيين خاصية الإجراء operationOptions
على Sequential
في محرر عرض التعليمة البرمجية. خلاف ذلك، تحصل على خطأ في التحقق من الصحة. لمزيد من المعلومات، راجع تشغيل "لكل" حلقات بالتتابع.
تحرير في عرض التعليمة البرمجية
في التعريف الأساسي "لكل"، قم بإضافة أو تحديث خاصية runtimeConfiguration.concurrency.repetitions
، والتي يمكن أن تحتوي على قيمة تتراوح من 1
و50
.
إليك مثال يحد من عمليات التشغيل المتزامنة إلى 10 تكرارات:
"For_each" {
"type": "Foreach",
"actions": { "<actions-to-run>" },
"foreach": "<for-each-expression>",
"runAfter": {},
"runtimeConfiguration": {
"concurrency": {
"repetitions": 10
}
}
}
لمزيد من المعلومات، راجع إعدادات تكوين وقت التشغيل.
التحرير في مصمم سير العمل
في For each إجراء، من الزاوية العلوية اليمنى، حدد زر علامات الحذف (...)، ثم حدد Settings.
ضمن Concurrency Control، اضبط التحكم في التزامن على On.
اسحب شريط التمرير درجة التوازي إلى القيمة التي تريدها. لتشغيل التطبيق المنطقي بشكل تسلسلي، اسحب قيمة شريط التمرير إلى 1.
تغيير حد فترات الانتظار
بشكل افتراضي، تعمل جميع مثيلات سير عمل التطبيق المنطقي في نفس الوقت (بشكل متزامن أو بالتوازي). يعني هذا السلوك أن كل مثيل مشغل يتم تشغيله قبل انتهاء تشغيل مثيل سير العمل النشط سابقاً. ومع ذلك، يوجد حد افتراضي لعدد مثيلات سير العمل قيد التشغيل بشكل متزامن. عندما يصل عدد عمليات التشغيل المتزامنة إلى هذا الحد، يجب أن تنتظر أي مثيلات سير عمل جديدة أخرى للتشغيل. يوجد حد افتراضي أيضا لعدد مثيلات سير العمل قيد الانتظار. عندما يصل عدد مثيلات الانتظار إلى هذا الحد، لم تعد Azure Logic Apps تقبل مثيلات سير العمل الجديدة لتشغيلها. ترجع مشغلات الطلب والإخطار على الويب 429 - العديد من أخطاء الطلبات، وتبدأ المشغلات المتكررة في تخطي محاولات التحقق.
يمكنك تغيير الحد الافتراضي لتزامن المشغل بالإضافة إلى الحد الافتراضي لانتظار التشغيل. ومع ذلك، يؤدي هذا التغيير في المقام الأول إلى إبطاء المشغل لتخفيف الضغط بسبب التزامن. على سبيل المثال، إذا كان لديك مشغل استقصاء، وكانت قائمة انتظار عمليات التشغيل ممتلئة بسبب عمليات التشغيل قيد التقدم، تتوقف Azure Logic Apps عن التحقق. إذا كان سير العمل يستخدم مشغلا يستند إلى الطلب، وكانت قائمة انتظار عمليات التشغيل ممتلئة، تبدأ Azure Logic Apps في إرجاع الخطأ 429. توجد بعض السيناريوهات حيث لا يمكن ل Azure Logic Apps إيقاف المشغل من الاستقصاء دون إدخال حالات الفشل واختيار إضافة مثل هذه التشغيلات إلى قائمة انتظار عمليات التشغيل على أي حال دون فشل عمليات تشغيل الاستدعاء.
في تعريف المشغل الأساسي، أضف الخاصية runtimeConfiguration.concurrency.maximumWaitingRuns
، والتي يمكن أن تحتوي على قيمة تتراوح من 1
إلى 100
.
"<trigger-name>": {
"type": "<trigger-name>",
"recurrence": {
"frequency": "<time-unit>",
"interval": <number-of-time-units>,
},
"runtimeConfiguration": {
"concurrency": {
"maximumWaitingRuns": 50
}
}
}
لمزيد من المعلومات، راجع إعدادات تكوين وقت التشغيل.
مثيلات الزناد بالتتابع
لتشغيل كل مثيل سير عمل تطبيق منطقي فقط بعد انتهاء تشغيل المثيل السابق، قم بتعيين المشغل للتشغيل بالتسلسل. يمكنك استخدام إما محرر عرض التعليمات البرمجية أو مصمم سير العمل لأن تغيير إعداد التزامن من خلال المصمم يضيف أيضا الخاصية أو يحدثها runtimeConfiguration.concurrency.runs
في تعريف المشغل الأساسي والعكس صحيح.
إشعار
عند تعيين مشغل للتشغيل بالتتابع إما باستخدام المصمم أو محرر عرض التعليمة البرمجية، لا تقم بتعيين خاصية المشغل operationOptions
على Sequential
في محرر عرض التعليمة البرمجية.
خلاف ذلك، تحصل على خطأ في التحقق من الصحة.
تحرير في عرض التعليمة البرمجية
في تعريف المشغل، عيّن أياً من هاتين الخاصيتين، ولكن ليس كليهما.
عيّن الخاصية runtimeConfiguration.concurrency.runs
على 1
:
"<trigger-name>": {
"type": "<trigger-name>",
"recurrence": {
"frequency": "<time-unit>",
"interval": <number-of-time-units>,
},
"runtimeConfiguration": {
"concurrency": {
"runs": 1
}
}
}
-or-
عيّن الخاصية operationOptions
على SingleInstance
:
"<trigger-name>": {
"type": "<trigger-name>",
"recurrence": {
"frequency": "<time-unit>",
"interval": <number-of-time-units>,
},
"operationOptions": "SingleInstance"
}
لمزيد من المعلومات، راجع إعدادات تكوين وقت التشغيل وخيارات التشغيل.
التحرير في مصمم سير العمل
في الزاوية العلوية اليمنى للمشغل، حدد زر الحذف (...)، ثم حدد Settings.
ضمن Concurrency Control، عيّن Limit على On.
اسحب شريط التمرير درجة التوازي إلى الرقم
1
.
تشغيل "لكل" حلقات بالتتابع
لتشغيل تكرار حلقة "لكل" فقط بعد انتهاء التكرار السابق، قم بتعيين إجراء "لكل" للتشغيل بالتتابع. يمكنك استخدام محرر عرض التعليمات البرمجية أو مصمم سير العمل لأن تغيير تزامن الإجراء من خلال المصمم يضيف أيضا الخاصية أو يحدثها runtimeConfiguration.concurrency.repetitions
في تعريف الإجراء الأساسي والعكس صحيح.
إشعار
عند تعيين إجراء "لكل" ليتم تشغيله بالتتابع إما باستخدام المصمم أو محرر عرض التعليمة البرمجية، لا تقم بتعيين خاصية الإجراء operationOptions
على Sequential
في محرر عرض التعليمة البرمجية.
خلاف ذلك، تحصل على خطأ في التحقق من الصحة.
تحرير في عرض التعليمة البرمجية
في تعريف الإجراء، قم بتعيين أي من هاتين الخاصيتين، ولكن ليس كليهما.
عيّن الخاصية runtimeConfiguration.concurrency.repetitions
على 1
:
"For_each" {
"type": "Foreach",
"actions": { "<actions-to-run>" },
"foreach": "<for-each-expression>",
"runAfter": {},
"runtimeConfiguration": {
"concurrency": {
"repetitions": 1
}
}
}
-or-
عيّن الخاصية operationOptions
على Sequential
:
"For_each" {
"type": "Foreach",
"actions": { "<actions-to-run>" },
"foreach": "<for-each-expression>",
"runAfter": {},
"operationOptions": "Sequential"
}
لمزيد من المعلومات، راجع إعدادات تكوين وقت التشغيل وخيارات التشغيل.
التحرير في مصمم سير العمل
في الزاوية العلوية اليمنى For each إجراء، حدد زر الحذف (...)، ثم حدد Settings.
ضمن Concurrency Control، اضبط التحكم في التزامن على On.
اسحب شريط التمرير درجة التوازي إلى الرقم
1
.
قم بتشغيل الإجراءات في نمط عملية متزامن
بشكل افتراضي، يتبع إجراء HTTP وإجراءات APIConnection في Azure Logic Apps نمط العملية غير المتزامنالقياسي، بينما يتبع إجراء الاستجابة نمط العملية المتزامنة. يحدد النمط غير المتزامن أنه بعد استدعاء الإجراء أو إرسال طلب إلى نقطة النهاية أو الخدمة أو النظام أو واجهة برمجة التطبيقات المحددة، يقوم جهاز الاستقبال فوراً بإرجاع استجابة "تم قبول 202". تؤكد هذه التعليمة البرمجية أن المتلقي قبل الطلب ولكنه لم ينته من المعالجة. يمكن أن تتضمن الاستجابة رأساً location
يحدد عنوان URL ومعرف التحديث الذي يمكن للمتصل استخدامه للاستقصاء المستمر أو التحقق من حالة الطلب غير المتزامن حتى يتوقف المستلم عن المعالجة ويعيد "200 موافق" نجاح أو استجابة أخرى غير 202. لمزيد من المعلومات، راجع يفرض تكامل الخدمات المصغرة غير المتزامن استقلالية الخدمات المصغرة.
في Logic App Designer، يكون لكل من إجراء HTTP وإجراءات APIConnection وإجراء الاستجابة إعداد Asynchronous Pattern. عند التمكين، يحدد هذا الإعداد أن المتصل لا ينتظر انتهاء المعالجة ويمكنه الانتقال إلى الإجراء التالي ولكنه يستمر في التحقق من الحالة حتى تتوقف المعالجة. إذا تم تعطيله، فإن هذا الإعداد يحدد أن المتصل ينتظر انتهاء المعالجة قبل الانتقال إلى الإجراء التالي. للعثور على هذا الإعداد، اتبع الخطوات التالية:
في شريط عنوان إجراء HTTP، حدد زر الحذف (...) الذي يفتح إعدادات الإجراء.
ابحث عن إعداد Asynchronous Pattern.
في تعريف JavaScript Object Notation (JSON) الأساسي للإجراء، يتبع إجراء HTTP وإجراءات APIConnection بشكل ضمني نمط التشغيل غير المتزامن.
في بعض السيناريوهات، قد ترغب في اتخاذ إجراء ليتبع النمط المتزامن بدلاً من ذلك. على سبيل المثال، عند استخدام إجراء HTTP، قد ترغب في:
في هذه الحالات، يمكنك تنفيذ الإجراء بشكل متزامن باستخدام الخيارات التالية:
استبدل إصدار الاستطلاع لهذا الإجراء بإصدار الرد التلقائي على الويب، إذا كان متاحاً.
قم بتعطيل السلوك غير المتزامن للإجراء باتباع أي من الخيارين:
في Logic App Designer، أوقف إعداد النمط غير المتزامن.
في تعريف JSON الأساسي للإجراء، أضف
"DisableAsyncPattern"
خيار العملية.
قم بإيقاف تشغيل إعداد النمط غير المتزامن
في Logic App Designer، في شريط عنوان الإجراء، حدد زر الحذف (...) الذي يفتح إعدادات الإجراء.
ابحث عن إعداد النمط غير المتزامن، وقم بتحويل الإعداد إلى Off إذا تم تمكينه، وحدد Done.
تعطيل النمط غير المتزامن في تعريف JSON للإجراء
في تعريف JSON الأساسي للإجراء، قم بإضافة وتعيين خاصية "operationOptions" إلى "DisableAsyncPattern"
ضمن قسم "inputs"
الإجراء، على سبيل المثال:
"<some-long-running-action>": {
"type": "Http",
"inputs": { "<action-inputs>" },
"operationOptions": "DisableAsyncPattern",
"runAfter": {}
}
قم بمصادقة المشغلات والإجراءات
تدعم نقاط نهاية HTTP وHTTPS أنواعاً مختلفة من المصادقة. استناداً إلى المشغل أو الإجراء الذي تستخدمه لإجراء مكالمات صادرة أو طلبات للوصول إلى نقاط النهاية هذه، يمكنك الاختيار من بين نطاقات مختلفة من أنواع المصادقة. لمزيد من المعلومات، راجع إضافة مصادقة للمكالمات الصادرة.
الخطوات التالية
- تعرف على المزيد بشأن لغة تعريف سير العمل