معالجة الأخطاء والاستثناءات في Azure Logic Apps

ينطبق على: Azure Logic Apps (الاستهلاك + قياسي)

يمكن أن تشكل الطريقة التي تتعامل بها أي بنية تكامل بشكل مناسب مع وقت التعطل أو المشكلات التي تسببها الأنظمة التابعة تحديًا. لمساعدتك على إنشاء تكاملات قوية ومرنة تعالج المشكلات والفشل بأمان، توفر Azure Logic Apps تجربة من الدرجة الأولى لمعالجة الأخطاء والاستثناءات.

Retry policies

For the most basic exception and error handling, you can use the retry policy if this capability exists on a trigger or action, such as the HTTP action. إذا انتهت مهلة الطلب الأصلي للمشغل أو الإجراء أو فشله، ما أدى إلى استجابة 408 أو 429 أو 5xx، فإن نهج إعادة المحاولة يحدد أن المشغل أو الإجراء يعيد إرسال الطلب لكل إعدادات النهج.

حدود نهج إعادة المحاولة

لمزيد من المعلومات حول نهج إعادة المحاولة والإعدادات والحدود والخيارات الأخرى، راجع حدود نهج إعادة المحاولة.

إعادة محاولة أنواع النهج

Connector operations that support retry policies use the Default policy unless you select a different retry policy.

Retry policy	Description
Default	For most operations, the Default retry policy is an exponential interval policy that sends up to 4 retries at exponentially increasing intervals. يتم قياس هذه الفواصل الزمنية بمقدار 7.5 ثانية ولكن يتم توجها بين 5 و45 ثانية. Several operations use a different Default retry policy, such as a fixed interval policy. لمزيد من المعلومات، راجع نوع نهج إعادة المحاولة الافتراضي.
None	لا تقم بإعادة إرسال الطلب. لمزيد من المعلومات، راجع بلا - لا يوجد نهج إعادة محاولة.
Exponential Interval	ينتظر هذا النهج فاصلاً زمنيًا عشوائيًا، والذي تم تحديده من نطاق متزايد بشكل كبير قبل إرسال الطلب التالي. لمزيد من المعلومات، راجع نوع نهج الفاصل الزمني الأسي.
Fixed Interval	ينتظر هذا النهج الفاصل الزمني المحدد قبل إرسال الطلب التالي. لمزيد من المعلومات، راجع نوع نهج الفاصل الزمني الثابت.

تغيير نوع نهج إعادة المحاولة في المصمم

In the Azure portal, open your logic app resource.
على الشريط الجانبي للمورد، اتبع هذه الخطوات لفتح مصمم سير العمل، استنادا إلى تطبيق المنطق الخاص بك:
- Consumption: Under Development Tools, select the designer to open your workflow.
- Standard
  1. Under Workflows, select Workflows.
  2. From the Workflows page, select your workflow.
  3. Under Tools, select the designer to open your workflow.
في المشغل أو الإجراء حيث تريد تغيير نوع نهج إعادة المحاولة، اتبع الخطوات التالية لفتح الإعدادات:
1. على المصمم، حدد العملية.
2. On the operation information pane, select Settings.
3. Under Networking, under Retry policy, select the policy type that you want.

تغيير نوع نهج إعادة المحاولة في محرر عرض التعليمات البرمجية

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

في تعريف المشغل أو الإجراء، أضف retryPolicy كائن JSON إلى كائن المشغل أو الإجراء inputs . إذا لم يكن هناك retryPolicy كائن، يستخدم default المشغل أو الإجراء نهج إعادة المحاولة.

"inputs": {
   <...>,
   "retryPolicy": {
      "type": "<retry-policy-type>",
      // The following properties apply to specific retry policies.
      "count": <retry-attempts>,
      "interval": "<retry-interval>",
      "maximumInterval": "<maximum-interval>",
      "minimumInterval": "<minimum-interval>"
   },
   <...>
},
"runAfter": {}

Required

Property	Value	Type	Description
`type`	< retry-policy-type>	String	نوع نهج إعادة المحاولة لاستخدامه: `default`أو`none`أو`fixed`أو`exponential`
`count`	< retry-attempts>	Integer	بالنسبة إلى نوعي النهج `fixed` و`exponential`، عدد محاولات إعادة المحاولة، وهي قيمة من 1 إلى 90. For more information, review Fixed Interval and Exponential Interval.
`interval`	< retry-interval>	String	بالنسبة إلى نوعي النهج `fixed` و`exponential`، قيمة الفاصل الزمني لإعادة المحاولة بتنسيق ISO 8601. بالنسبة إلى النهج `exponential`، يمكنك أيضًا تحديد الفواصل الزمنية القصوى والدنيا الاختيارية. For more information, review Fixed Interval and Exponential Interval. Consumption: 5 seconds (`PT5S`) to 1 day (`P1D`). Standard: For stateful workflows, 5 seconds (`PT5S`) to 1 day (`P1D`). بالنسبة إلى مهام سير العمل عديمة الحالة، من ثانية واحدة (`PT1S`) إلى دقيقة واحدة (`PT1M`).

Optional

Property	Value	Type	Description
`maximumInterval`	< maximum-interval>	String	بالنسبة إلى النهج `exponential`، أكبر فاصل زمني للفاصل الزمني المحدد عشوائيًا بتنسيق ISO 8601. القيمة الافتراضية هي يوم واحد (`P1D`). For more information, review Exponential Interval.
`minimumInterval`	< minimum-interval>	String	بالنسبة إلى النهج `exponential`، أصغر فاصل زمني للفاصل الزمني المحدد عشوائيًا بتنسيق ISO 8601. القيمة الافتراضية هي 5 ثوانٍ (`PT5S`). For more information, review Exponential Interval.

نهج إعادة المحاولة الافتراضي

Connector operations that support retry policies use the Default policy unless you select a different retry policy. For most operations, the Default retry policy is an exponential interval policy that sends up to 4 retries at exponentially increasing intervals. يتم قياس هذه الفواصل الزمنية بمقدار 7.5 ثانية ولكن يتم توجها بين 5 و45 ثانية. Several operations use a different Default retry policy, such as a fixed interval policy.

في تعريف سير العمل، لا يحدد تعريف المشغل أو الإجراء بشكل صريح النهج الافتراضي، ولكن يوضح المثال التالي كيفية تصرف نهج إعادة المحاولة الافتراضي لإجراء HTTP:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "http://myAPIendpoint/api/action",
      "retryPolicy" : {
         "type": "exponential",
         "interval": "PT7S",
         "count": 4,
         "minimumInterval": "PT5S",
         "maximumInterval": "PT1H"
      }
   },
   "runAfter": {}
}

بلا - لا توجد سياسة إعادة المحاولة

To specify that the action or trigger doesn't retry failed requests, set the <retry-policy-type> to none.

نهج إعادة محاولة الفاصل الزمني الثابت

To specify that the action or trigger waits the specified interval before sending the next request, set the <retry-policy-type> to fixed.

Example

يحاول نهج إعادة المحاولة هذا الحصول على أحدث الأخبار مرتين إضافيتين بعد الطلب الفاشل الأول مع تأخير 30 ثانية بين كل محاولة:

"Get_latest_news": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "https://mynews.example.com/latest",
      "retryPolicy": {
         "type": "fixed",
         "interval": "PT30S",
         "count": 2
      }
   }
}

نهج إعادة محاولة الفاصل الزمني الأسي

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

Name	Consumption limit	Standard limit	Notes
Maximum delay	افتراضي: يوم واحد	الافتراضي: ساعة واحدة	لتغيير الحد الافتراضي في سير عمل تطبيق منطق الاستهلاك، استخدم معلمة نهج إعادة المحاولة. لتغيير الحد الافتراضي في سير عمل تطبيق المنطق القياسي، راجع تحرير إعدادات المضيف والتطبيق للتطبيقات المنطقية في تطبيقات Azure Logic للمستأجر الفردي.
Minimum delay	الافتراضي: 5 ثوانٍ	الافتراضي: 5 ثوانٍ	لتغيير الحد الافتراضي في سير عمل تطبيق منطق الاستهلاك، استخدم معلمة نهج إعادة المحاولة. لتغيير الحد الافتراضي في سير عمل تطبيق المنطق القياسي، راجع تحرير إعدادات المضيف والتطبيق للتطبيقات المنطقية في تطبيقات Azure Logic للمستأجر الفردي.

Name

Consumption limit

Standard limit

Notes

Maximum delay

افتراضي: يوم واحد

الافتراضي: ساعة واحدة

لتغيير الحد الافتراضي في سير عمل تطبيق منطق الاستهلاك، استخدم معلمة نهج إعادة المحاولة.

لتغيير الحد الافتراضي في سير عمل تطبيق المنطق القياسي، راجع تحرير إعدادات المضيف والتطبيق للتطبيقات المنطقية في تطبيقات Azure Logic للمستأجر الفردي.

Minimum delay

الافتراضي: 5 ثوانٍ

لتغيير الحد الافتراضي في سير عمل تطبيق منطق الاستهلاك، استخدم معلمة نهج إعادة المحاولة.

نطاقات متغيرة عشوائية

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

Retry number	Minimum interval	Maximum interval
1	max(0, <minimum-interval>)	min(interval, <maximum-interval>)
2	max(interval, <minimum-interval>)	min(2 * interval, <maximum-interval>)
3	max(2 * interval, <minimum-interval>)	min(4 * interval, <maximum-interval>)
4	max(4 * interval, <minimum-interval>)	min(8 * interval, <maximum-interval>)
....	....	....

إدارة سلوك "التشغيل بعد"

عند إضافة إجراءات في مصمم سير العمل، فإنك تعلن ضمنيا عن تسلسل تشغيل هذه الإجراءات. After an action finishes running, that action is marked with a status such as Succeeded, Failed, Skipped, or TimedOut. بمعنى آخر، يجب أن ينتهي الإجراء السابق أولا بأي من الحالات المسموح بها قبل تشغيل الإجراء اللاحق.

By default, an action that you add in the designer runs only if the preceding action completes with Succeeded status. This run after behavior precisely specifies the run order for actions in a workflow.

في المصمم، يمكنك تغيير سلوك "التشغيل بعد" الافتراضي لإجراء ما عن طريق تحرير إعداد تشغيل بعد الإجراء. يتوفر هذا الإعداد فقط على الإجراءات اللاحقة التي تتبع الإجراء الأول في سير العمل. يتم تشغيل الإجراء الأول في سير العمل دائما بعد تشغيل المشغل بنجاح. So, the Run after setting isn't available and doesn't apply to the first action.

In an action's underlying JSON definition, the Run after setting is the same as the runAfter property. تحدد هذه الخاصية إجراء سابق واحد أو أكثر يجب أن ينتهي أولا بالحالات المسموح بها المحددة قبل تشغيل الإجراء اللاحق. runAfter الخاصية هي كائن JSON يوفر المرونة عن طريق السماح لك بتحديد كافة الإجراءات السابقة التي يجب أن تنتهي قبل تشغيل الإجراء اللاحق. يعرف هذا الكائن أيضا صفيفا من الحالات المقبولة.

على سبيل المثال، لتشغيل إجراء بعد نجاح الإجراء A وأيضا بعد نجاح الإجراء B أو فشله عند العمل على تعريف JSON للإجراء، قم بإعداد الخاصية التالية runAfter :

{
   // Other parts in action definition
   "runAfter": {
      "Action A": ["Succeeded"],
      "Action B": ["Succeeded", "Failed"]
    }
}

سلوك "التشغيل بعد" لمعالجة الأخطاء

When an action throws an unhandled error or exception, the action is marked Failed, and any successor action is marked Skipped. إذا حدث هذا السلوك لإجراء يحتوي على فروع متوازية، فإن محرك Azure Logic Apps يتبع الفروع الأخرى لتحديد حالات إكمالها. For example, if a branch ends with a Skipped action, that branch's completion status is based on that skipped action's predecessor status. بعد اكتمال تشغيل سير العمل، يحدد المحرك حالة التشغيل بالكامل عن طريق تقييم جميع حالات الفرع. If any branch ends in failure, the entire workflow run is marked Failed.

للتأكد من أنه لا يزال من الممكن تشغيل إجراء على الرغم من حالة سابقته، فإنه يمكنك تغيير سلوك "التشغيل بعد" الإجراء لمعالجة حالات السابقة غير الناجحة. That way, the action runs when the predecessor's status is Succeeded, Failed, Skipped, TimedOut, or all these statuses.

على سبيل المثال، لتشغيل Office 365 Outlook إرسال إجراء بريد إلكتروني بعد وضع علامة فشل على الإجراء السابق في Excel Online إضافة صف إلى جدول، بدلاً من نجاحه، قم بتغيير سلوك "التشغيل بعد" باستخدام المصمم أو محرر طريقة عرض التعليمات البرمجية.

تغيير سلوك "التشغيل بعد" في المصمم

In the Azure portal, open your logic app resource.
على الشريط الجانبي للمورد، اتبع هذه الخطوات لفتح مصمم سير العمل، استنادا إلى تطبيق المنطق الخاص بك:
- Consumption: Under Development Tools, select the designer to open your workflow.
- Standard
  1. On the resource sidebar, under Workflows, select Workflows.
  2. From the Workflows page, select your workflow.
  3. Under Tools, select the designer to open your workflow.
في المشغل أو الإجراء حيث تريد تغيير سلوك "التشغيل بعد"، اتبع الخطوات التالية لفتح إعدادات العملية:
1. على المصمم، حدد العملية.
2. On the operation information pane, select Settings.
  
  The Run after section contains a Select actions list, which shows the available predecessor operations for the currently selected operation, for example:
3. Under the Select actions list, expand the current predecessor operation, which is HTTP in this example:
  
  By default, the "run after" status is set to Is successful. تعني هذه القيمة أن العملية السابقة يجب أن تنتهي بنجاح قبل تشغيل الإجراء الحالي.
لتغيير سلوك "run after" إلى الحالات التي تريدها، حدد هذه الحالات.

The following example selects Has failed.
To specify that the current operation runs only when the predecessor action completes with the Has failed, Is skipped, or Has timed out status, select these statuses, and then clear the default status, for example:

Note

قبل مسح الحالة الافتراضية، تأكد من تحديد حالة أخرى أولا. يجب أن يكون لديك دائما حالة واحدة على الأقل محددة.
لمطالبة تشغيل عمليات سابقة متعددة وإنهاءها، لكل منها حالات "تشغيل بعد" الخاصة بها، اتبع الخطوات التالية:
1. Open the Select actions list, and select the predecessor operations that you want.
2. حدد حالات "run after" لكل عملية.
عند الانتهاء، أغلق جزء معلومات العملية.

تغيير سلوك "التشغيل بعد" في محرر عرض التعليمات البرمجية

على الشريط الجانبي للمورد، اتبع هذه الخطوات لفتح محرر عرض التعليمات البرمجية، استنادا إلى تطبيق المنطق الخاص بك:
- Consumption: Under Development Tools, select code view to open your workflow in the JSON editor.
- Standard
  1. Under Workflows, select Workflows.
  2. From the Workflows page, select your workflow.
  3. Under Tools, select code view to open your workflow in the JSON editor.

في تعريف JSON للإجراء، قم بتحرير الخاصية runAfter التي تحتوي على بناء الجملة التالي:

"<action-name>": {
   "inputs": {
      "<action-specific-inputs>"
   },
   "runAfter": {
      "<preceding-action>": [
         "Succeeded"
      ]
   },
   "type": "<action-type>"
}

على سبيل المثال، قم بتغيير الخاصية runAfter من Succeeded إلى Failed:

"Send_an_email_(V2)": {
   "inputs": {
      "body": {
         "Body": "<p>Failed to add row to table: @{body('Add_a_row_into_a_table')?['Terms']}</p>",
         "Subject": "Add row to table failed: @{body('Add_a_row_into_a_table')?['Terms']}",
         "To": "Sophia.Owen@fabrikam.com"
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "method": "post",
      "path": "/v2/Mail"
   },
   "runAfter": {
      "Add_a_row_into_a_table": [
         "Failed"
      ]
   },
   "type": "ApiConnection"
}

لتحديد تشغيل الإجراء سواء تم وضع علامة على الإجراء السابق على أنه Failedأو SkippedTimedOut، أضف الحالات الأخرى:
```
"runAfter": {
   "Add_a_row_into_a_table": [
      "Failed", "Skipped", "TimedOut"
   ]
},
```

تقييم الإجراءات باستخدام النطاقات ونتائجها

Similar to running steps after individual actions with the "run after" setting, you can group actions together inside a scope. يمكنك استخدام النطاقات عندما تريد تجميع الإجراءات معا منطقيًا وتقييم الحالة التجميعية للنطاق وتنفيذ الإجراءات استنادًا إلى تلك الحالة. بعد انتهاء تشغيل كافة الإجراءات في نطاق، يحصل النطاق نفسه على حالته الخاصة.

To check a scope's status, you can use the same criteria that you use to check a workflow run status, such as Succeeded, Failed, and so on.

By default, when all the scope's actions succeed, the scope's status is marked Succeeded. If the final action in a scope is marked Failed or Aborted, the scope's status is marked Failed.

To catch exceptions in a Failed scope and run actions that handle those errors, you can use the "run after" setting that Failed scope. That way, if any actions in the scope fail, and you use the "run after" setting for that scope, you can create a single action to catch failures.

للحصول على حدود النطاقات، انظرالحدود والتهيئة.

إعداد نطاق مع "تشغيل بعد" لمعالجة الاستثناء

In the Azure portal, open your logic app resource and workflow in the designer.

يجب أن يحتوي سير العمل الخاص بك بالفعل على مشغل يبدأ سير العمل.
على المصمم، اتبع هذه الخطوات العامة لإضافة إجراء Control يسمى Scope إلى سير العمل الخاص بك.
In the Scope action, follow these generic steps to the add actions to run, for example:

The following list shows some example actions that you might include inside a Scope action:
- الحصول على البيانات من واجهة برمجة التطبيقات.
- معالجة البيانات.
- احفظ البيانات في قاعدة بيانات.
الآن حدد قواعد "التشغيل بعد" لتشغيل الإجراءات في النطاق.
1. On the designer, select the Scope title. When the scope's information pane opens, select Settings.
2. If you have more than one preceding action in the workflow, from the Select actions list, select the action after which you want to run the scoped actions.
3. بالنسبة إلى الإجراء المحدد، حدد جميع حالات الإجراء التي يمكنها تشغيل الإجراءات المحددة النطاق.
  
  بمعنى آخر، تتسبب أي من الحالات المختارة الناتجة عن الإجراء المحدد في تشغيل الإجراءات في النطاق.
  
  In the following example, the scoped actions run after the HTTP action completes with any of the selected statuses:

الحصول على السياق والنتائج للفشل

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

Note

The result() function returns the results only from the top-level actions and not from deeper nested actions such as switch or condition actions.

للحصول على سياق حول الإجراءات التي فشلت في نطاق، يمكنك استخدام @result() التعبير باسم النطاق وإعداد "التشغيل بعد". To filter down the returned array to actions that have Failed status, you can add the Filter Array action. لتشغيل إجراء لفشل الإجراء الذي تم إرجاعه، اتخذ الصفيف الذي تمت تصفيته واستخدم لكل تكرار حلقي.

The following JSON example sends an HTTP POST request with the response body for any actions that failed within the scope action named My_Scope. ويتبع المثال شرح مفصل.

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": "@result('My_Scope')",
      "where": "@equals(item()['status'], 'Failed')"
   },
   "runAfter": {
      "My_Scope": [
         "Failed"
      ]
    }
},
"For_each": {
   "type": "foreach",
   "actions": {
      "Log_exception": {
         "type": "Http",
         "inputs": {
            "method": "POST",
            "body": "@item()['outputs']['body']",
            "headers": {
               "x-failed-action-name": "@item()['name']",
               "x-failed-tracking-id": "@item()['clientTrackingId']"
            },
            "uri": "http://requestb.in/"
         },
         "runAfter": {}
      }
   },
   "foreach": "@body('Filter_array')",
   "runAfter": {
      "Filter_array": [
         "Succeeded"
      ]
   }
}

تصف الخطوات التالية ما يحدث في هذا المثال:

To get the result from all actions inside My_Scope, the Filter Array action uses this filter expression: @result('My_Scope')
The condition for Filter Array is any @result() item that has a status equal to Failed. This condition filters the array that has all the action results from My_Scope down to an array with only the failed action results.
Perform a For_each loop action on the filtered array outputs. تنفذ هذه الخطوة إجراء لكل نتيجة إجراء فاشل تمت تصفيتها مسبقًا.

إذا فشل إجراء واحد في النطاق، يتم تشغيل الإجراءات في التكرار For_each الحلقي مرة واحدة فقط. تتسبب الإجراءات الفاشلة المتعددة في إجراء واحد لكل فشل.
إرسال HTTP POST على نص استجابة For_each العنصر، وهو @item()['outputs']['body'] التعبير.

@result() شكل العنصر هو نفسه @actions() الشكل ويمكن تحليله بنفس الطريقة.
قم بتضمين عنوانين مخصصين باسم الإجراء الفاشل (@item()['name']) ومعرف تعقب عميل التشغيل الفاشل (@item()['clientTrackingId']).

كمرجع، إليك مثال لعنصر @result()واحد، يعرضname، bodyوالخصائصclientTrackingId التي تم تحليلها في المثال السابق. For_each خارج الإجراء، @result() ترجع صفيفًا من هذه الكائنات.

{
   "name": "Example_Action_That_Failed",
   "inputs": {
      "uri": "https://myfailedaction.azurewebsites.net",
      "method": "POST"
   },
   "outputs": {
      "statusCode": 404,
      "headers": {
         "Date": "Thu, 11 Aug 2016 03:18:18 GMT",
         "Server": "Microsoft-IIS/8.0",
         "X-Powered-By": "ASP.NET",
         "Content-Length": "68",
         "Content-Type": "application/json"
      },
      "body": {
         "code": "ResourceNotFound",
         "message": "/docs/folder-name/resource-name does not exist"
      }
   },
   "startTime": "2016-08-11T03:18:19.7755341Z",
   "endTime": "2016-08-11T03:18:20.2598835Z",
   "trackingId": "bdd82e28-ba2c-4160-a700-e3a8f1a38e22",
   "clientTrackingId": "08587307213861835591296330354",
   "code": "NotFound",
   "status": "Failed"
}

لتنفيذ أنماط معالجة استثناء مختلفة، يمكنك استخدام التعبيرات الموضحة سابقا في هذه المقالة. قد تختار تنفيذ إجراء معالجة استثناء واحد خارج النطاق الذي يقبل صفيف الفشل الذي تمت تصفيته بالكامل، وإزالة For_each الإجراء. يمكنك أيضًا تضمين خصائص مفيدة أخرى من الاستجابة \@result() كما هو موضح سابقًا.

إعداد سجلات Azure مراقبة

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

For example, Azure Monitor provides a streamlined way to send all workflow events, including all run and action statuses, to a destination. يمكنك إعداد تنبيهات لمقاييس عتبات محددة في Azure Monitor. يمكنك أيضًا إرسال أحداث سير العمل إلى مساحة عمل Log Analytics أو حساب تخزين Azure. أو يمكنك دفق جميع الأحداث من خلال Azure Event Hubs إلى Azure Stream Analytics. في Stream Analytics، يمكنك كتابة استعلامات مباشرة استنادًا إلى أي حالات شاذة أو متوسطات أو فشل من سجلات التشخيص. يمكنك استخدام Stream Analytics لإرسال معلومات إلى مصادر بيانات أخرى، مثل قوائم الانتظار أو الموضوعات أو SQL أو Azure Cosmos DB أو Power BI.

لمزيد من المعلومات، راجعإعداد سجلات Azure Monitor وجمع بيانات التشخيص Azure Logic Apps.

أمثلة وسيناريوهات Azure Logic Apps

الملاحظات

هل كانت هذه الصفحة مفيدة؟

Last updated on 2025-07-22