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

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

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

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

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

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

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

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

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

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

1. في مدخل Microsoft Azure، افتح سير عمل التطبيق المنطقي في المصمم.

2. استنادًا إلى ما إذا كنت تعمل على سير عمل Consumption أو Standard، افتح المشغل أو إعدادات الإجراء.

   • الاستهلاك: في شكل الإجراء، افتح قائمة علامات الحذف (...)، وحدد الإعدادات.

   • قياسي: على المصمم، حدد الإجراء. في جزء التفاصيل، حدد الإعدادات.

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": {}
   

   مطلوب

   الخاصية	القيمة	النوع	‏‏الوصف
   type	< retry-policy-type>	السلسلة‬	نوع نهج إعادة المحاولة لاستخدامه: defaultأوnoneأوfixedأوexponential
   count	< retry-attempts>	رقم صحيح	بالنسبة إلى نوعي النهج fixed وexponential، عدد محاولات إعادة المحاولة، وهي قيمة من 1 إلى 90. لمزيد من المعلومات، راجع الفاصل الزمني الثابت والفاصل الأسي.
   interval	< retry-interval>	السلسلة‬	بالنسبة إلى نوعي النهج fixed وexponential، قيمة الفاصل الزمني لإعادة المحاولة بتنسيق ISO 8601. بالنسبة إلى النهج exponential، يمكنك أيضًا تحديد الفواصل الزمنية القصوى والدنيا الاختيارية. لمزيد من المعلومات، راجع الفاصل الزمني الثابت والفاصل الأسي. الاستهلاك: من 5 ثوانٍ (PT5S) إلى يوم واحد (P1D). قياسي: بالنسبة إلى مهام سير العمل ذات الحالة، من 5 ثوانٍ (PT5S) إلى يوم واحد (P1D). بالنسبة إلى مهام سير العمل عديمة الحالة، من ثانية واحدة (PT1S) إلى دقيقة واحدة (PT1M).

   اختياري

   الخاصية	القيمة	النوع	‏‏الوصف
   maximumInterval	< maximum-interval>	السلسلة‬	بالنسبة إلى النهج exponential، أكبر فاصل زمني للفاصل الزمني المحدد عشوائيًا بتنسيق ISO 8601. القيمة الافتراضية هي يوم واحد (P1D). لمزيد من المعلومات، راجع الفاصل الزمني الأسي.
   minimumInterval	< minimum-interval>	السلسلة‬	بالنسبة إلى النهج exponential، أصغر فاصل زمني للفاصل الزمني المحدد عشوائيًا بتنسيق ISO 8601. القيمة الافتراضية هي 5 ثوانٍ (PT5S). لمزيد من المعلومات، راجع الفاصل الزمني الأسي.

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

تستخدم عمليات الموصل التي تدعم نهج إعادة المحاولة النهج الافتراضي ما لم تحدد نهج إعادة محاولة مختلف. بالنسبة لمعظم العمليات، نهج إعادة المحاولة الافتراضي هو نهج فاصل زمني أسي يرسل ما يصل إلى 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": {}
}

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

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

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

لتحديد أن الإجراء أو المشغل ينتظر الفاصل الزمني المحدد قبل إرسال الطلب التالي، قم بتعيين <retry-policy-type> إلى fixed.

مثال

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

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

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

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

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

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

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

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

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

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

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

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

1. في مدخل Microsoft Azure، افتح سير عمل التطبيق المنطقي في المُصمم.

2. على المصمم، حدد شكل الإجراء. في جزء التفاصيل، حدد الإعدادات.

   يعرض قسم Run After في جزء Settings الإجراء السابق للإجراء المحدد حاليا.

   

3. قم بتوسيع الإجراء السابق لعرض جميع حالات السابقة المحتملة.

   بشكل افتراضي، يتم تعيين حالة "run after" إلى Is successful. لذلك، يجب أن ينتهي الإجراء السابق بنجاح قبل تشغيل الإجراء المحدد حاليا.

   

4. لتغيير سلوك "run after" إلى الحالات التي تريدها، حدد هذه الحالات. تأكد من تحديد خيار أولاً قبل مسح الخيار الافتراضي. يجب أن يكون لديك دائمًا خيار واحد على الأقل محدد.

   يحدد المثال التالي فشل.

   

5. لتحديد أن الإجراء الحالي يتم تشغيله عند اكتمال الإجراء السابق بحالة Failed أو Skipped أو TimedOut ، حدد هذه الحالات.

   

6. لمطالبة تشغيل أكثر من إجراء سابق، كل إجراء له حالات "تشغيل بعد" الخاصة به، قم بتوسيع قائمة Select actions. حدد الإجراءات السابقة التي تريدها، وحدد حالات "التشغيل بعد" المطلوبة.

   

7. عندما تكون جاهزًا، حدد تم.

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

1. في مدخل Azure، افتح سير عمل تطبيق المنطق في محرر عرض التعليمات البرمجية.

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

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

3. على سبيل المثال، قم بتغيير الخاصية 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"
   }
   

4. لتحديد تشغيل الإجراء سواء تم وضع علامة على الإجراء السابق على أنه Failedأو SkippedTimedOut، أضف الحالات الأخرى:

   "runAfter": {
      "Add_a_row_into_a_table": [
         "Failed", "Skipped", "TimedOut"
      ]
   },
   

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

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

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

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

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

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

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

1. في مدخل Microsoft Azure، افتح سير عمل التطبيق المنطقي في المصمم.

   يجب أن يحتوي سير العمل الخاص بك بالفعل على مشغل يبدأ سير العمل.

2. على المصمم، اتبع هذه الخطوات العامة لإضافة إجراء Control يسمى Scope إلى سير العمل الخاص بك.

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

   

   تعرض القائمة التالية بعض الأمثلة على الإجراءات التي قد تقوم بتضمينها داخل إجراء Scope :

   • الحصول على البيانات من واجهة برمجة التطبيقات.
   • معالجة البيانات.
   • احفظ البيانات في قاعدة بيانات.

4. الآن حدد قواعد "التشغيل بعد" لتشغيل الإجراءات في النطاق.

   1. على المصمم، حدد عنوان النطاق . عند فتح جزء معلومات النطاق، حدد الإعدادات.

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

   3. بالنسبة إلى الإجراء المحدد، حدد جميع حالات الإجراء التي يمكنها تشغيل الإجراءات المحددة النطاق.

      بمعنى آخر، تتسبب أي من الحالات المختارة الناتجة عن الإجراء المحدد في تشغيل الإجراءات في النطاق.

      في المثال التالي، يتم تشغيل الإجراءات المحددة النطاق بعد اكتمال إجراء HTTP بأي من الحالات المحددة:

      

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

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

للحصول على سياق حول الإجراءات التي فشلت في نطاق، يمكنك استخدام @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"
      ]
   }
}

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

1. للحصول على النتيجة من جميع الإجراءات داخل My_Scope، يستخدم إجراء صفيف التصفية تعبير عامل التصفية هذا: @result('My_Scope')

2. شرط صفيف التصفية هو أي @result() عنصر له حالة مساوية لـ Failed. يقوم هذا الشرط بتصفية الصفيف الذي يحتوي على جميع نتائج الإجراء من My_Scope لأسفل إلى صفيف مع نتائج الإجراء الفاشلة فقط.

3. تنفيذ For_each إجراء حلقي على مخرجات الصفيف التي تمت تصفيتها. تنفذ هذه الخطوة إجراء لكل نتيجة إجراء فاشل تمت تصفيتها مسبقًا.

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

4. إرسال HTTP POST على نص استجابة For_each العنصر، وهو @item()['outputs']['body'] التعبير.

   @result() شكل العنصر هو نفسه @actions() الشكل ويمكن تحليله بنفس الطريقة.

5. قم بتضمين عنوانين مخصصين باسم الإجراء الفاشل (@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 Event Hubs إلى Azure Stream Analytics. في Stream Analytics، يمكنك كتابة استعلامات مباشرة استنادًا إلى أي حالات شاذة أو متوسطات أو فشل من سجلات التشخيص. يمكنك استخدام Stream Analytics لإرسال معلومات إلى مصادر بيانات أخرى، مثل قوائم الانتظار أو الموضوعات أو SQL أو Azure Cosmos DB أو Power BI.

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

الخطوات التالية

• تعرف على المزيد حول أمثلة وسيناريوهات Azure Logic Apps