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

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

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

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

لمعالجة الاستثناءات والأخطاء، يمكنك استخدام سياسة إعادة المحاولة إذا كانت هذه القدرة موجودة على مشغل أو إجراء، مثل إجراء HTTP. إذا انتهت مهلة الطلب الأصلي للمشغل أو الإجراء أو فشله، ما أدى إلى استجابة 408 أو 429 أو 5xx، فإن نهج إعادة المحاولة يحدد أن المشغل أو الإجراء يعيد إرسال الطلب لكل إعدادات النهج.

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

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

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

عمليات الموصل التي تدعم سياسات إعادة المحاولة تستخدم سياسة الإعداد الافتراضي ما لم تختر سياسة إعادة محاولة مختلفة.

نهج إعادة المحاولة	Description
Default	بالنسبة لمعظم العمليات، سياسة إعادة المحاولة الافتراضية هي سياسة فاصل أسي ترسل حتى 4 محاولات بفواصل متزايدة بشكل أسي . يتم قياس هذه الفواصل الزمنية بمقدار 7.5 ثانية ولكن يتم توجها بين 5 و45 ثانية. تستخدم عدة عمليات سياسة إعادة محاولة افتراضية مختلفة، مثل سياسة الفترات الزمنية المحددة. لمزيد من المعلومات، راجع نوع نهج إعادة المحاولة الافتراضي.
None	لا تقم بإعادة إرسال الطلب. لمزيد من المعلومات، راجع بلا - لا يوجد نهج إعادة محاولة.
الفترة الأسية	ينتظر هذا النهج فاصلاً زمنيًا عشوائيًا، والذي تم تحديده من نطاق متزايد بشكل كبير قبل إرسال الطلب التالي. لمزيد من المعلومات، راجع نوع نهج الفاصل الزمني الأسي.
الفترة الزمنية الثابتة	ينتظر هذا النهج الفاصل الزمني المحدد قبل إرسال الطلب التالي. لمزيد من المعلومات، راجع نوع نهج الفاصل الزمني الثابت.

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

في مدخل Microsoft Azure، افتح مورد التطبيق المنطقي.
على الشريط الجانبي للمورد، اتبع هذه الخطوات لفتح مصمم سير العمل، استنادا إلى تطبيق المنطق الخاص بك:
- الاستهلاك: تحت أدوات التطوير، اختر المصمم لفتح سير عملك.
- Standard
  1. تحت قسم سير العمل، اختر سير العمل.
  2. من صفحة سير العمل ، اختر سير العمل الخاص بك.
  3. تحت الأدوات، اختر المصمم لفتح سير عملك.
في المشغل أو الإجراء حيث تريد تغيير نوع نهج إعادة المحاولة، اتبع الخطوات التالية لفتح الإعدادات:
1. على المصمم، حدد العملية.
2. في لوحة معلومات العمليات، اختر الإعدادات.
3. تحت قسم الشبكات، وتحت سياسة إعادة المحاولة، اختر نوع السياسة الذي تريده.

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

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

في تعريف المشغل أو الإجراء، أضف 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`	< نوع سياسة إعادة المحاولة>	String	نوع نهج إعادة المحاولة لاستخدامه: `default`أو`none`أو`fixed`أو`exponential`
`count`	< محاولات إعادة المحاولة>	Integer	بالنسبة إلى نوعي النهج `fixed` و`exponential`، عدد محاولات إعادة المحاولة، وهي قيمة من 1 إلى 90. لمزيد من المعلومات، راجع الفترة الثابتة والفاصل الأسي.
`interval`	< فترة إعادة المحاولة>	String	بالنسبة إلى نوعي النهج `fixed` و`exponential`، قيمة الفاصل الزمني لإعادة المحاولة بتنسيق ISO 8601. بالنسبة إلى النهج `exponential`، يمكنك أيضًا تحديد الفواصل الزمنية القصوى والدنيا الاختيارية. لمزيد من المعلومات، راجع الفترة الثابتة والفاصل الأسي. الاستهلاك: 5 ثوان (`PT5S`) إلى يوم واحد (`P1D`). القياسي: لسير العمل القائم على الحالة، من 5 ثوان (`PT5S`) إلى يوم واحد (`P1D`). بالنسبة إلى مهام سير العمل عديمة الحالة، من ثانية واحدة (`PT1S`) إلى دقيقة واحدة (`PT1M`).

Optional

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

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

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

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

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

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

لتحديد أن الإجراء أو المشغلة لا يعيد محاولة الطلبات الفاشلة، قم بتعيين < نوع > إلى none.

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

لتحديد أن الإجراء أو المحفز ينتظر الفترة المحددة قبل إرسال الطلب التالي، قم بتعيين < نوع > على 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	حد الاستهلاك	الحد القياسي	Notes
أقصى تأخير	افتراضي: يوم واحد	الافتراضي: ساعة واحدة	لتغيير الحد الافتراضي في سير عمل تطبيق منطق الاستهلاك، استخدم معلمة نهج إعادة المحاولة. لتغيير الحد الافتراضي في سير عمل تطبيق المنطق القياسي، راجع تحرير إعدادات المضيف والتطبيق للتطبيقات المنطقية في تطبيقات Azure Logic للمستأجر الفردي.
الحد الأدنى للتأخير	الافتراضي: 5 ثوانٍ	الافتراضي: 5 ثوانٍ	لتغيير الحد الافتراضي في سير عمل تطبيق منطق الاستهلاك، استخدم معلمة نهج إعادة المحاولة. لتغيير الحد الافتراضي في سير عمل تطبيق المنطق القياسي، راجع تحرير إعدادات المضيف والتطبيق للتطبيقات المنطقية في تطبيقات Azure Logic للمستأجر الفردي.

Name

حد الاستهلاك

الحد القياسي

Notes

أقصى تأخير

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

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

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

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

الحد الأدنى للتأخير

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

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

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

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

رقم إعادة المحاولة	الحد الأدنى للفاصل الزمني	الحد الأقصى للفاصل الزمني
1	max(0، <الحد الأدنى-الفترة>)	min(interperiod، <أقصى فاصل>)
2	max(interval, <grimum-interth>)	min(2 * فاصل، <الحد الأقصى-الفترة>)
3	max(2 * فاصل، <الحد الأدنى-الفترة>)	min(4 * فاصل، <الحد الأقصى-الفترة>)
4	max(4 * interval، <الحد الأدنى-الفترة>)	min(8 * فاصل، <أقصى فاصل>)
....	....	....

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

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

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

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

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

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

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

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

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

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

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

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

في مدخل Microsoft Azure، افتح مورد التطبيق المنطقي.
على الشريط الجانبي للمورد، اتبع هذه الخطوات لفتح مصمم سير العمل، استنادا إلى تطبيق المنطق الخاص بك:
- الاستهلاك: تحت أدوات التطوير، اختر المصمم لفتح سير عملك.
- Standard
  1. في الشريط الجانبي للمورد، ضمن مهام سير العمل، حدد مهام سير العمل.
  2. من صفحة سير العمل ، اختر سير العمل الخاص بك.
  3. تحت الأدوات، اختر المصمم لفتح سير عملك.
في المشغل أو الإجراء حيث تريد تغيير سلوك "التشغيل بعد"، اتبع الخطوات التالية لفتح إعدادات العملية:
1. على المصمم، حدد العملية.
2. في لوحة معلومات العمليات، اختر الإعدادات.
  
  يحتوي قسم "بعد الجهد " على قائمة إجراءات الاختيار ، والتي تعرض العمليات السابقة المتاحة للعملية المحددة حاليا، على سبيل المثال:
3. تحت قائمة اختيار الأفعال ، قم بتوسيع العملية السابقة الحالية، وهي HTTP في هذا المثال:
  
  افتراضيا، حالة "الركض بعد" مضبوطة على ناجحة. تعني هذه القيمة أن العملية السابقة يجب أن تنتهي بنجاح قبل تشغيل الإجراء الحالي.
لتغيير سلوك "run after" إلى الحالات التي تريدها، حدد هذه الحالات.

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

Note

قبل مسح الحالة الافتراضية، تأكد من تحديد حالة أخرى أولا. يجب أن يكون لديك دائما حالة واحدة على الأقل محددة.
لمطالبة تشغيل عمليات سابقة متعددة وإنهاءها، لكل منها حالات "تشغيل بعد" الخاصة بها، اتبع الخطوات التالية:
1. افتح قائمة اختيار الإجراءات ، واختر العمليات السابقة التي تريدها.
2. حدد حالات "run after" لكل عملية.
عند الانتهاء، أغلق جزء معلومات العملية.

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

على الشريط الجانبي للمورد، اتبع هذه الخطوات لفتح محرر عرض التعليمات البرمجية، استنادا إلى تطبيق المنطق الخاص بك:
- الاستهلاك: تحت أدوات التطوير، اختر عرض الكود لفتح سير العمل في محرر JSON.
- Standard
  1. تحت قسم سير العمل، اختر سير العمل.
  2. من صفحة سير العمل ، اختر سير العمل الخاص بك.
  3. تحت الأدوات، اختر عرض الكود لفتح سير العمل في محرر JSON.

في تعريف 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"
   ]
},
```

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

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

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

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

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

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

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

في بوابة Azure، افتح مورد وسير عمل تطبيق المنطق في المصمم.

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

تظهر القائمة التالية بعض الإجراءات النموذجية التي قد تدرجها داخل إجراء النطاق :
- الحصول على البيانات من واجهة برمجة التطبيقات.
- معالجة البيانات.
- احفظ البيانات في قاعدة بيانات.
الآن حدد قواعد "التشغيل بعد" لتشغيل الإجراءات في النطاق.
1. في المصمم، اختر عنوان Scope . عند فتح لوحة معلومات المنظار، اختر الإعدادات.
2. إذا كان لديك أكثر من إجراء سابق في سير العمل، من قائمة اختيار الإجراءات ، اختر الإجراء الذي تريد بعده تنفيذ الإجراءات المحددة بالمسار.
3. بالنسبة إلى الإجراء المحدد، حدد جميع حالات الإجراء التي يمكنها تشغيل الإجراءات المحددة النطاق.
  
  بمعنى آخر، تتسبب أي من الحالات المختارة الناتجة عن الإجراء المحدد في تشغيل الإجراءات في النطاق.
  
  في المثال التالي، تعمل الإجراءات المحددة بعد اكتمال إجراء HTTP بأي من الحالات المحددة:

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

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

Note

ترجع الدالة result() النتائج فقط من الإجراءات العليا وليس من الإجراءات المتداخلة الأعمق مثل إجراءات التبديل أو الشرط.

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

المثال التالي ل JSON يرسل طلب HTTP POST مع جسم الاستجابة لأي إجراءات فشلت ضمن إجراء النطاق المسمى 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"
      ]
   }
}

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

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

إذا فشل إجراء واحد في النطاق، يتم تشغيل الإجراءات في التكرار 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 مراقبة

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

على سبيل المثال، يوفر Azure Monitor طريقة مبسطة لإرسال جميع أحداث سير العمل، بما في ذلك جميع حالات التشغيل والإجراءات، إلى وجهة. يمكنك إعداد تنبيهات لمقاييس عتبات محددة في Azure Monitor. يمكنك أيضًا إرسال أحداث سير العمل إلى مساحة عمل Log Analytics أو حساب تخزين Azure. أو يمكنك دفق جميع الأحداث من خلال مراكز أحداث Azure إلى Azure Stream Analytics. في Stream Analytics، يمكنك كتابة استعلامات مباشرة استنادًا إلى أي حالات شاذة أو متوسطات أو فشل من سجلات التشخيص. يمكنك استخدام Stream Analytics لإرسال معلومات إلى مصادر بيانات أخرى، مثل قوائم الانتظار أو الموضوعات أو SQL أو Azure Cosmos DB أو Power BI.

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

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

الملاحظات

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

Last updated on 2026-07-10