معالجة الأخطاء وتصميم إعادة المحاولة في Power Automate ── منع «توقّف تدفّق كان يعمل دون أن يلاحظ أحد»

«التدفّق التجميعيّ الذي كان يعمل كلّ صباح توقّف فعليّاً منذ الأسبوع الماضي»، «تدفّق تسجيل الطلبات يعالج البيانات نفسها مرّتين فظهر تكرار في السجلّ». نتلقّى كثيراً هذا النوع من الاستشارات من شركات بدأت بناء تدفّقات Power Automate وتشغيلها. البناء كان سهلاً، لكن لم يلاحظ أحد التوقّف. هذا هو النمط.

تعمل تدفّقات Power Automate في غضون ساعات قليلة إذا اقتصرنا على المسار الطبيعيّ فقط. لكن الخدمات المتّصلة تتوقّف مؤقّتاً، وتنتهي صلاحيّة المصادقة، وتصل حتماً بيانات غير متوقّعة. التدفّق الذي لم يُصمَّم لـ«ماذا يحدث عند الفشل» يراكم الفشل بصمت، وفي أسوأ الحالات يُعطَّل تلقائيّاً خلال 14 يوماً¹. في هذا المقال نرتّب أنماط تصميم معالجة الأخطاء التي تتحمّل التشغيل الإنتاجيّ: تصنيف فشل التدفّق، والمواصفات الدقيقة لإعادة المحاولة القياسيّة، ونمط Try-Catch-Finally باستخدام النطاقات (Scope)، وآليّة الانتباه إلى الفشل، وإعادة التنفيذ والتصميم المتكافئ. أمّا التمييز بين استخدامات Power Automate ككلّ، ومعالجة الأخطاء في جانب أتمتة الواجهة (تدفّق سطح المكتب)، فمشروحة في «أتمتة الأعمال باستخدام Power Automate ── الفصل بين التدفّق السحابي وتدفّق سطح المكتب وتصميم معالجة الأخطاء»، لذا يقتصر هذا المقال على التعمّق في التدفّق السحابي.

1. الخلاصة أوّلاً

• نفكّر في الفشل بتقسيمه إلى أربعة أنواع: «عطل مؤقّت»، و«فشل ناتج عن البيانات»، و«انتهاء الصلاحيّات أو المصادقة»، و«تغيير المواصفات». إعادة المحاولة القياسيّة تحلّ الأوّل فقط، أمّا الثلاثة الباقية فتحتاج آليّة كشف وإصلاح².
• تعمل سياسة إعادة المحاولة القياسيّة فقط عندما ينتهي الطلب بالمهلة الزمنيّة أو يفشل باستجابة 408 أو 429 أو 5xx. الافتراضيّ هو تراجع أُسّيّ (exponential backoff)، والعدد أقصى مرّتين أو 12 مرّة حسب طبقة الترخيص (ملف الأداء)³¹.
• الشكل الأساسيّ لمعالجة الأخطاء هو Try-Catch-Finally عبر النطاق (Scope) و«تكوين شرط التنفيذ». يُختار شرط التنفيذ من أربع حالات: «نجح، فشل، تُخطِّي، انتهت مهلته»³⁴. علماً أنّ اسم العرض في واجهة المستخدم اليابانيّة هو «実行条件の構成»، وفي الواجهة الإنكليزيّة والوثائق «run after». نوحّد في ما يلي على اسم تكوين شرط التنفيذ.
• بعد معالجة الفشل في Catch، سجِّل التنفيذ في النهاية كـ«فشل» عبر إجراء Terminate. إن أُغفل ذلك، يبدو التنفيذ في السجلّ ناجحاً، ويُطمس الفشل⁴³.
• رسالة إشعار الفشل الافتراضيّة محدودة بـ«فشل له طريقة إصلاح معروفة» فقط، ومصحوبة بفترة تهدئة 28 يوماً، وهي آليّة فيها ثغرات كثيرة إن اعتُمد عليها كليّاً. اعتبر الإشعار الذاتيّ من كتلة Catch أمراً إلزاميّاً⁵.
• لا يُعرض سجلّ التنفيذ إلا لمدّة 28 يوماً افتراضيّاً. تُعطَّل التدفّقات المستمرّة الفشل تلقائيّاً خلال 14 يوماً. «الانتباه إلى التوقّف بعد شهر» ممكن حسب المواصفات⁶¹.
• استعداداً لإعادة التنفيذ (إعادة الإرسال) والتشغيل المزدوج، أدرج منذ البداية تصميماً متكافئاً (idempotent) آمناً حتّى مع التنفيذ المزدوج (علامة معالَج، upsert بدل الإنشاء، شروط المشغِّل)⁷⁸.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 22، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. كيف يفشل التدفّق ── أربعة تصنيفات للفشل

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

من بين هذه، الأكثر إزعاجاً في العمل الفعليّ هو انتهاء الصلاحيّات أو المصادقة. لأنّه لا يفشل فيه إجراء التدفّق فقط، بل يفشل المشغِّل نفسه. من الأمثلة النموذجيّة لفشل المشغِّل بخطأ من النوع 4xx، تُذكر في استكشاف الأخطاء الرسميّ حالة تغيير كلمة المرور المستخدمة في الاتّصال (انتهاء الصلاحيّة). عند فشل المشغِّل لا يبدأ التدفّق أصلاً، فلا يبقى حتّى سطر «فشل» في سجلّ التنفيذ، ما يؤخّر الانتباه أكثر⁹. بما أنّ الاتّصال يرتبط بالمستخدم الفرديّ الذي أنشأه، تحدث حوادث انقطاع جماعيّ عند استقالة الموظّف أو انتقاله. رتّبنا التدابير التنظيميّة لهذا الجانب بالتفصيل في «معالجة الاعتماد على شخص واحد في Power Automate ── كي لا يتوقّف التدفّق إذا استقال من أنشأه».

نقطة أخرى يجب معرفتها هي أنّ إهمال الفشل يقود إلى إيقاف التدفّق نفسه. تُعطَّل تلقائيّاً خلال 14 يوماً التدفّقات التي يستمرّ فشل المشغِّل أو الإجراء فيها، وكذلك التدفّقات المستمرّ تقييدها تُعطَّل خلال 14 يوماً. كما قد يُعطَّل التدفّق الذي لم يُشغَّل خلال 90 يوماً (إن لم يكن صاحبه مالكاً لترخيص Premium أو ترخيص سعة)¹. كذلك، بسبب مخالفة سياسة DLP (Data Loss Prevention: منع فقدان البيانات. حاجز يقيّد به المسؤول إتاحة الموصلات وتركيباتها كي لا تخرج بيانات المؤسّسة إلى الخارج دون قصد. الاسم الرسميّ الحاليّ هو «سياسات البيانات»)¹⁰ أو بسبب الفشل المتكرّر، قد يكون التدفّق في حالة «معلَّق (suspended)»¹¹. تغيير سياسة DLP يسري فوراً ويوقف التدفّقات بلا إنذار، لذا عندما تتعطّل عدّة تدفّقات في الوقت نفسه، فالأسلوب الثابت هو الاشتباه أوّلاً في تغيير السياسة¹¹. بعض حالات «التدفّق الذي كان يعمل توقّف» ليست عطلاً، بل ناتجة عن هذه المواصفات نفسها.

3. فهم إعادة المحاولة القياسيّة

تحمل إجراءات Power Automate (المبنيّ على Azure Logic Apps) سياسة إعادة محاولة مدمَجة منذ البداية. معرفة هذه المواصفات بدقّة أوّلاً تتيح الحكم على «هل يجب إضافة إعداد إعادة محاولة؟» أو «هل لا تحلّها إعادة المحاولة؟».

ما الذي يُعاد محاولته ومتى؟

تعمل سياسة إعادة المحاولة عندما ينتهي طلب الإجراء (أو المشغِّل) بالمهلة الزمنيّة، أو يفشل باستجابة 408 (انتهاء مهلة الطلب) أو 429 (طلبات زائدة = تقييد) أو 5xx (خطأ خادم)³. السياسة الافتراضيّة هي تراجع أُسّيّ (إعادة المحاولة مع إطالة الفاصل أُسّيّاً)، ويختلف العدد والفاصل الافتراضيّان في Power Automate باختلاف ملف أداء التدفّق (وهو عمليّاً طبقة الترخيص)¹.

بمعنى آخر، حتّى مع تعريف التدفّق نفسه، تختلف «صلابة التحمّل أمام العطل المؤقّت» باختلاف ترخيص صاحبه. لا يؤثّر ملف الأداء في عدد إعادة المحاولة فقط، بل يؤثّر أيضاً في الحدّ الأقصى لعدد الطلبات يوميّاً، لذا يمكن الرجوع إلى فكرة طبقة الترخيص في «تراخيص Power Automate ── إلى أيّ حدّ يكفي Microsoft 365 مجّاناً، ومتى تحتاج Premium».

يمكن تغيير سياسة إعادة المحاولة من إعداد الإجراء. الأنواع أربعة: الافتراضيّ، بلا، فاصل ثابت، فاصل أُسّيّ، ويمكن تحديد العدد والفاصل صراحة. حدّ الإعداد هو 90 مرّة كأقصى عدد، وأقلّ فاصل 5 ثوانٍ، وأقصى تأخير يوم واحد³¹. توصي إرشادات Microsoft للترميز بالفاصل الأُسّيّ بدل الفاصل الثابت للتعافي من العطل المؤقّت، لتجنّب إعاقة تعافي الطرف الآخر بالضغط المتكرّر خلال فترات قصيرة⁴.

ما تحلّه إعادة المحاولة وما لا تحلّه

نقطة يجب الانتباه إليها هي أنّ إعادة المحاولة أيضاً تستهلك عدد الطلبات (طلبات Power Platform). يُحتسب تنفيذ الإجراء ضمن عدد الطلبات سواء نجح أم فشل، وكذلك طلبات إعادة المحاولة وتقسيم الصفحات (pagination)¹. تعديل زيادة العدد استجابةً لـ 429 قد يزيد التقييد سوءاً، لذا فكّر أوّلاً في «هل يمكن تقليل عدد مرّات الاستدعاء نفسها» قبل تكثيف إعادة المحاولة.

4. نمط Try-Catch-Finally ── النطاق (Scope) وتكوين شرط التنفيذ

الفشل الذي لا تحلّه إعادة المحاولة يُلتقط ويُعالج داخل التدفّق. لا يملك Power Automate صياغة try-catch، لكن يمكن بناء البنية نفسها بدمج النطاق (Scope) مع «تكوين شرط التنفيذ» (في الواجهة الإنكليزيّة: run after). هذا أسلوب موصى به أيضاً في إرشادات Microsoft للترميز⁴.

الأساس الذي يقوم عليه هذا التكوين هو تكوين شرط التنفيذ. يحمل كلّ إجراء عند اكتماله إحدى الحالات نجح (Succeeded)، فشل (Failed)، تُخطِّي (Skipped)، انتهت مهلته (TimedOut)، وتُنفَّذ الإجراءات التالية افتراضيّاً فقط «إن نجح الإجراء السابق». يمكن تغيير هذا الشرط لكلّ إجراء، ما يتيح بناء فرع يُنفَّذ عند «الفشل» أو «انتهاء المهلة»³.

مكان الإعداد يصعب إيجاده في المرّة الأولى. في المصمّم، افتح قائمة «…» (ثلاث نقاط) للإجراء أو النطاق المستهدف، واختر «تكوين شرط التنفيذ»، فتظهر لوحة فيها مربّعات اختيار للحالات الأربع لكلّ إجراء سابق¹¹. ضع علامة على الحالات اللازمة. نقطة حذر واحدة: يجب أن تبقى حالة واحدة على الأقلّ محدَّدة، لذا لا تُزل «عند النجاح» الافتراضيّ إلا بعد وضع علامة على حالة أخرى³. كذلك لا يقتصر تكوين شرط التنفيذ على «الإجراء السابق مباشرة»؛ يمكن تحديد عدّة إجراءات سابقة وتعيين حالة لكلّ منها³.

عند تطبيق ذلك على النطاق ينتج Try-Catch-Finally. يحمل النطاق نتيجة كلّ الإجراءات التي يحويها مجمَّعة كحالة واحدة، لذا فإنّ بنية «إن فشل أيّ مكان داخل نطاق Try، نفِّذ نطاق Catch» أسهل صيانة بكثير من ضبط الشرط على مستوى كلّ إجراء منفرد³⁴.

flowchart TD
    Trigger[المشغِّل] --> Try[[نطاق Try<br/>تجميع المعالجة الأساسيّة هنا]]
    Try -- نجاح --> Fin
    Try -- فشل / انتهاء المهلة --> Catch[[نطاق Catch<br/>تكوين شرط التنفيذ: عند الفشل أو انتهاء المهلة]]
    Catch --> Extract[استخراج الإجراء الفاشل وسببه<br/>بدالّة result ومعالجة تصفية المصفوفة]
    Extract --> Notify[إشعار المسؤول عبر Teams أو البريد<br/>اسم التدفّق، الخطوة الفاشلة، تفاصيل الخطأ، رابط التنفيذ]
    Notify --> Fin[[نطاق Finally<br/>تكوين شرط التنفيذ: النجاح والفشل والتخطّي وانتهاء المهلة جميعاً]]
    Fin --> Cleanup[التنظيف وتحديث عمود الحالة في السجلّ]
    Cleanup --> Judge{هل مرّ عبر Catch؟}
    Judge -- نعم --> Term[Terminate<br/>الحالة: Failed لإنهاء التنفيذ]
    Judge -- لا --> Done([انتهاء طبيعيّ])

نقاط البناء أربع:

• اختر لشرط تنفيذ نطاق Catch كلاً من «عند الفشل» و«عند انتهاء المهلة». أزل «عند النجاح» الافتراضيّ. فإن اخترت الفشل فقط، يفلت انتهاء مهلة إجراءات الانتظار أو التأخير مثل انتظار الموافقة³.
• استخرج داخل Catch محتوى الفشل. تُرجع دالّة result('اسم نطاق Try') مصفوفة بنتائج (الحالة والمدخلات والمخرجات ونصّ الخطأ) الإجراءات مباشرة تحت النطاق، فإذا ضيّقت عبر «معالجة تصفية المصفوفة» (Filter array) إلى ما تكون حالته Failed أو TimedOut، يمكنك وضع اسم الإجراء الفاشل ونصّ رسالة الخطأ في الإشعار³⁴. إن ضيّقت بـ Failed فقط، يصبح ناتج الاستخراج فارغاً عند الدخول إلى Catch عبر انتهاء المهلة، وتسقط من الإشعار الخطوة الفاشلة الأهمّ. ومع ذلك استخرج معرِّف التنفيذ من دالّة workflow() وابنِ عنوان URL مباشراً إلى سجلّ التنفيذ، فهذا يجعل التحقيق أسهل بكثير (التعبير في البند التالي)⁴.
• اختر لشرط تنفيذ نطاق Finally الحالات الأربع جميعها. ضع هنا التنظيف الذي تريد تنفيذه دائماً سواء نجح أم فشل (حذف الملفّات المؤقّتة، تحديث عمود حالة السجلّ، وغيرها).
• أنهِ التنفيذ الفاشل في النهاية عبر إجراء Terminate كـ«فشل». هذه أسهل نقطة يُنسى ضبطها. عندما يكتمل Catch بنجاح، يُعدّ آخر إجراء في التنفيذ ككلّ ناجحاً، فيُسجَّل في سجلّ التنفيذ كـ«ناجح». بمعنى آخر، إن اكتفيت بالإشعار فقط ثمّ انتهيت، يختفي الفشل من سجلّ التنفيذ، ويفلت من المراقبة والتجميع اللاحق. أنهِ التنفيذ عبر Terminate بضبط الحالة Failed ورسالة الخطأ، ليُسجَّل التنفيذ في السجلّ كفاشل أيضاً⁴³. لكن لا تضع Terminate مباشرة في نهاية نطاق Catch. لأنّ Terminate ينهي التنفيذ بأكمله فوراً عند تلك النقطة، فلا يُنفَّذ نطاق Finally التالي، ويُتخطّى التنظيف اللازم بالذات في وقت الخطأ. كما في الرسم، ارفع علامة فشل (متغيّر) في Catch واكتفِ بالإشعار حتّى ذلك الحدّ، ثمّ بعد اجتياز تنظيف Finally احكم على العلامة، وأنهِ عبر Terminate عند الفشل فقط، بهذا الترتيب.

كذلك يُعدّ تكوين شرط التنفيذ مكوّناً محوريّاً أيضاً في تفريع انتهاء مهلة تدفّق الموافقة (التذكير والتصعيد). شرحنا طريقة البناء التفصيليّة في «بناء سير موافقات باستخدام Power Automate ── رقمنة مستندات الاعتماد الداخلي والطلبات الورقيّة والبريديّة».

محتوى Catch ── استخراج الإجراء الفاشل ورابط التنفيذ بتعبير

هنا لبّ التنفيذ، لذا نكتب التعبير أيضاً. إذا كان اسم نطاق Try هو Try، يكون إعداد «معالجة تصفية المصفوفة» (Filter array) كالتالي. الشرط يُكتب مباشرة بعد التبديل إلى «التحرير في الوضع المتقدّم»³⁴.

البداية (From):  @result('Try')
الشرط (الوضع المتقدّم): @or(equals(item()['status'], 'Failed'), equals(item()['status'], 'TimedOut'))

من كلّ عنصر ترجعه result() يمكن استخراج القيم التالية. إن رتّبت هذه الأربع في نصّ الإشعار، يتّضح الاتجاه قبل فتح سجلّ التنفيذ³.

الرابط المباشر إلى سجلّ التنفيذ يُبنى من دالّة workflow(). تُرجع هذه الدالّة كائناً يحمل معرِّف التدفّق (name)، واسم البيئة (tags.environmentName)، والاسم المنطقيّ للتدفّق (tags.logicAppName)، ومعرِّف التنفيذ (run.name) وغيرها، فيأخذ عنوان URL الشكل التالي⁴.

concat('https://make.powerautomate.com/environments/', workflow()?['tags']?['environmentName'],
       '/flows/', workflow()?['tags']?['logicAppName'],
       '/runs/', workflow()?['run']?['name'])

تشرح الوثائق الرسميّة الإجراء كتحليل مخرجات workflow() بـ «تحليل JSON» (Parse JSON) ثمّ تجميع عنوان URL بإجراء «إنشاء» (Compose)⁴. النتيجة واحدة في الحالتين، لكن عنوان بوّابة المنتج قد يتغيّر، لذا بعد البناء مباشرة انقر الرابط المتولِّد مرّة وتأكّد أنّ سجلّ التنفيذ المقصود يُفتح. كذلك تحذّر الوثيقة نفسها من أنّ الإكثار من مخرجات السجلّ الذاتيّة ينفخ عدد الإجراءات ووقت التنفيذ فيأتي بنتيجة عكسيّة⁴. عمليّاً اكتفِ بأربع نقاط: «اسم التدفّق، الإجراء الفاشل، الخطأ، رابط التنفيذ».

5. آليّة الانتباه إلى الفشل ── الإشعار والإظهار المرئيّ

حتّى مع بناء معالجة الأخطاء، لا معنى لها إن لم ينتبه أحد إلى الفشل. صمّم «آليّة الانتباه» بطبقات متعدّدة، دون الاعتماد على الإشعار الافتراضيّ.

فهم رسالة إشعار الفشل الافتراضيّة بشكل صحيح

يملك Power Automate آليّة لإرسال إشعار بالبريد عند الفشل، لكنّها مليئة بالثغرات إن اعتُمد عليها دون معرفة مواصفاتها. الإشعار نوعان⁵.

• تنبيه فشل على مستوى التنفيذ: يُرسل فور فشل التنفيذ، لكنّه يُرسل فقط عند تصنيف الفشل كـ«فشل له طريقة إصلاح معروفة» مثل انقطاع الاتّصال أو التقييد أو أخطاء الموصل المعروفة. لا يُرسل عند فشل الإجراءات العامّة. الوجهة هي المالك والملّاك المشاركون (لا يشمل مستخدم التشغيل فقط، ولا يصل إلى المسؤول). علاوة على ذلك، بعد إرسالها مرّة توجد فترة تهدئة 28 يوماً لنفس التدفّق، لا تصل خلالها تنبيهات إضافيّة عن حالات فشل أخرى. تنبيهات مستوى التنفيذ ليست مفعَّلة افتراضيّاً في كلّ التدفّقات أيضاً، وتحتاج إلى التحقّق في إعداد التدفّق⁵.
• ملخّص فشل أسبوعيّ: يُرسل مرّة أسبوعيّاً ملخّص للفشل عبر البيئات. يشمل هذا أيضاً حالات الفشل العامّة التي لا تُرسل عنها تنبيهات مستوى التنفيذ⁵.

إضافة إلى ذلك، تُرسل بالنسبة لأخطاء معيّنة رسالة «تلميحات الإصلاح» المصحوبة بخطوات الإصلاح إلى المالك (يمكن تعطيلها لكلّ تدفّق)⁷. خلاصة القول، الإشعار الافتراضيّ آليّة «تنتبه إلى انقطاع الاتّصال الأوّل، لكن الفشل الناتج عن بيانات العمل أو الفشل الثاني فما فوق يسهل إفلاته». في التدفّقات المهمّة، اعتبر الإشعار الذاتيّ من كتلة Catch في الفصل 4 إلزاميّاً.

تصميم الإشعار من Catch ── حالة فشل تدفّق الإشعار نفسه

للإشعار الذاتيّ نقاط تصميم أيضاً.

• لا تجعل الوجهة فرداً. إن كانت الوجهة موظّفاً فرداً، لن تصل إلى أحد عند غيابه أو استقالته. توصي الوثائق الرسميّة نفسها بالإرسال إلى صندوق بريد مشترك أو قناة Teams¹¹.
• افصل مسار الإشعار عن المعالجة الأساسيّة. حادثة شائعة هي «انقطع اتّصال Outlook ففشل التدفّق، وبما أنّ إشعار الفشل يستخدم اتّصال Outlook نفسه تعذّر إرساله أيضاً»: انهيار مزدوج. في الفشل الناتج عن انتهاء صلاحيّة المصادقة، يفشل معه أيضاً إجراء الإشعار الذي يستخدم الاتّصال نفسه. اجعل الإشعار عبر موصل واتّصال مختلفين عن المعالجة الأساسيّة، كمنشور Teams مثلاً، أو افصله إلى تدفّق صغير مخصَّص للإشعار يُستدعى منه، فهذا يقلّل خطر الانهيار المزدوج. مع ذلك لا يمكن بناء «إشعار عن الإشعار» بلا نهاية، لذا نضع كخطّ دفاع أخير المراجعة الدوريّة التالية.
• ضع في الإشعار كلّ المعلومات اللازمة للتحقيق. اسم التدفّق، اسم الإجراء الفاشل، رسالة الخطأ، الرابط المباشر إلى سجلّ التنفيذ. بدون هذا، حتّى مع وصول الإشعار، لا يُعرف أكثر من «فشل شيء ما»، ويسهل إهماله⁴.

الإظهار المرئيّ والمراجعة الدوريّة

• مدقّق التدفّق (Flow checker): يكشف عن أخطاء وتحذيرات تعريف التدفّق قبل الحفظ. اجعل مراجعته مرّة واحدة عادة بعد الانتهاء من البناء¹².
• المراجعة الدوريّة لسجلّ التنفيذ: لا يُعرض سجلّ تنفيذ التدفّق إلا لمدّة 28 يوماً افتراضيّاً⁶. يمكن للتدفّقات المضمَّنة في حلّ (Solution) الاحتفاظ ببيانات وصفيّة لسجلّ التنفيذ في Dataverse، لكنّ الاحتفاظ الافتراضيّ هناك أيضاً 28 يوماً، والتمديد إعداد من جهة المسؤول¹³. بالنسبة للتدفّقات في الإنتاج، يُنصح بعمليّة مراجعة أسبوعيّة تقريباً تشمل ليس فقط الفشل، بل أيضاً «التنفيذ في حالة الإلغاء» (قد يكون سببه ضبط التزامن) و«الانخفاض المفاجئ في عدد التنفيذات» (مؤشّر على عدم عمل المشغِّل)¹¹.
• المراقبة المركزيّة للمسؤول: لرؤية كلّ حالات الفشل شاملة تلك التي لا تُرسل عنها رسالة تنبيه على مستوى التنفيذ، فإنّ Monitor (المراقبة) في مركز إدارة Power Platform هو الأكثر شمولاً. يمكن التحقّق من عدد حالات الفشل وتفاصيل الخطأ على مستوى التدفّق والبيئة⁵.

في حالة التدفّقات ذات التنفيذ الدوريّ، تلزم أيضاً مراقبة «هل بدأ التشغيل أصلاً». شرحنا تصميم التنفيذ الدوريّ الذي يشمل تحديد يوم العمل ومعالجة نهاية الشهر في «تصميم تدفّقات التنفيذ الدوريّ في Power Automate ── الممارسة العمليّة لمعالجة نهاية الشهر وتحديد أيّام العمل والتذكيرات».

6. إعادة التنفيذ والتصميم المتكافئ ── بناء «لا ينهار حتّى مع التنفيذ المزدوج»

المواجهة مع الفشل لا تنتهي بالكشف. تحتاج معاً إلى عمليّة «إعادة تنفيذ الجزء الفاشل»، وتصميم «لا ينهار حتّى مع إعادة التنفيذ».

مواصفات إعادة الإرسال (resubmit)

يمكن إعادة تنفيذ التنفيذ الفاشل من سجلّ التنفيذ عبر إعادة الإرسال (Resubmit). عمليّة تعيد التنفيذ بنفس بيانات المشغِّل: إن كان السبب عطلاً مؤقّتاً (500/502 مثلاً) يمكن إعادة الإرسال كما هي، وإن كان السبب خطأً في تعريف التدفّق يُعاد التنفيذ بالتعريف المُصلح بعد الإصلاح والحفظ ثمّ إعادة الإرسال⁷. من قائمة سجلّ التنفيذ يمكن إعادة إرسال حتّى 20 تنفيذاً دفعة واحدة، ما يفيد في التعافي عند الفشل الجماعيّ. بالنسبة للتدفّقات ذات المشغِّل اليدويّ (Instant Trigger)، يمكن إعادة إرسال تنفيذاتك الخاصّة في أيّ وقت، لكن إعادة إرسال تنفيذ بدأه مستخدم آخر تتطلّب أن يسمح المسؤول بذلك عبر إعداد المستأجر (tenant)¹⁴.

المهمّ هنا هو أنّ إعادة الإرسال تعيد تنفيذ التدفّق من البداية. إن أعدت إرسال تنفيذ فشل في الخطوة الثامنة من عشر خطوات، تُنفَّذ الخطوات الناجحة من الأولى إلى السابعة مرّة أخرى أيضاً. من هنا تحدث حوادث مثل «كان إرسال البريد قد تمّ، وأُرسل مرّة أخرى» أو «تكوّن سطران متطابقان في السجلّ».

التصميم المتكافئ ── تصميم آمن حتّى مع التنفيذ المزدوج

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

• الاحتفاظ بعلامة معالَج. اجعل للسجلّ مثل قائمة SharePoint عمود «الحالة» (غير معالَج / قيد المعالجة / معالَج)، وتحقّق من الحالة في بداية التدفّق: إن كانت معالَجة فأنهِ هناك، وحدّث الحالة عند انتهاء المعالجة. بهذا لا تصبح معالجة مزدوجة حتّى مع إعادة الإرسال. لكن العلامة لا تعمل إلا إذا حدّدت ترتيب التحديث أيضاً. الآثار الجانبيّة الخارجيّة مثل إرسال البريد أو التسجيل في نظام أساسيّ: حدّث الحالة إلى «قيد المعالجة» مباشرة قبل التنفيذ، ثمّ عيّنها إلى «معالَج» بعد الاكتمال. التنفيذ الذي يفشل بعد الأثر الجانبيّ وقبل تحديث العلامة يبقى في حالة «قيد المعالجة»، وهي حالة لا يُعرف فيها هل تمّ الأثر الجانبيّ أم لا. إعادة إرسال هذا السطر آليّاً قد تسبّب إرسالاً مزدوجاً، لذا استبعد السطور «قيد المعالجة» من الإعادة الآليّة، وأعد إنسان تعيينها إلى «معالَج» أو «غير معالَج» بعد مطابقة نتيجة الإرسال أو التسجيل الفعليّة. السطور الآمنة لإعادة التنفيذ بثقة هي «غير معالَج» فقط، أي السطور المتوقّفة فيها.
• اجعله «إن وُجد فحدّث، وإلا فأنشئ» (upsert) بدل «إنشاء». ابحث عن السطر الموجود عبر مفتاح فريد (رقم الطلب، معرِّف الطلب، وغيرها)، وفرّع بحيث تُحدَّث إن وُجد، وتُنشأ إن لم توجد. «إنشاء عنصر» غير المشروط يراكم سطوراً مكرَّرة مع كلّ إعادة تنفيذ. بعبارة أخرى، البيانات بلا مفتاح فريد لا يمكن جعلها متكافئة، لذا تحديد عمود المفتاح منذ مرحلة تصميم السجلّ شرط مسبق.
• أوقف التشغيل غير الضروريّ عبر شروط المشغِّل. التشغيل المتعدّد، كأن يعيد تدفّق مشغِّل «عند إنشاء عنصر أو تعديله» تشغيل نفسه عبر كتابته الخاصّة، يُوقف عبر شروط المشغِّل (trigger conditions)، لا عبر التفريع الشرطيّ اللاحق. لا يحدث التنفيذ أصلاً بالنسبة للأحداث التي لا تستوفي شرط المشغِّل، فلا يُستهلك عدد مرّات التنفيذ ولا عدد الطلبات⁸.

نقطة حذر واحدة: طريقة «التحقّق ثمّ الكتابة» مثل علامة المعالَج أو upsert فعّالة مع إعادة التنفيذ المتسلسلة كإعادة الإرسال، لكنّها ليست حماية ذرّيّة بمفردها. عند بدء حدثي مشغِّل مكرَّرين تقريباً في اللحظة نفسها، قد يقع تعارض يقرأ فيه كلا التنفيذين حالة «غير معالَج»، ثمّ يتقدّم كلاهما في المعالجة. لمنع التكرار بثقة في التدفّقات التي يُحتمل فيها التشغيل المتوازي، استخدم ضبط التزامن لجعل درجة التوازي 1 وتسلسل المعالجة في البند التالي، أو استخدم إلى جانب ذلك آليّة يمكنها فرض قيد مفتاح فريد على جهة الحفظ (كقيد فريد في قاعدة البيانات)، بحيث يفشل إنشاء التكرار عند لحظة الكتابة نفسها.

ضبط التزامن (concurrency control) والمفاضلة مع الترتيب

إلى جانب التنفيذ المزدوج، تظهر مشكلة «التزامن» و«الترتيب». افتراضيّاً، عندما تحدث أحداث كثيرة مستوفية لشرط المشغِّل في وقت واحد، يعمل التدفّق بالتوازي بأيّ عدد¹. عندما تقرأ وتكتب عدّة تنفيذات السطر نفسه في السجلّ في وقت واحد، قد يحدث تضارب (قراءة قذرة - dirty read) تكتب فوق قيمة قديمة¹⁵.

عند تفعيل ضبط التزامن (Concurrency Control) في إعداد المشغِّل، يمكن تحديد عدد التنفيذ المتوازي (درجة التوازي) بين 1 و100. جعل درجة التوازي 1 يجعل التنفيذ واحداً في كلّ مرّة، فيقترب من المعالجة المرتَّبة¹¹⁵. لكن هذا المفتاح يحمل ملاحظات حذر ثقيلة.

• بمجرّد التفعيل، لا يمكن التراجع. لإعادته إلى التعطيل، لا سبيل سوى حذف المشغِّل وإعادة إنشائه¹. بما أنّ ضبط التزامن لا رجعة فيه، يُوصى بتطبيقه فقط على تدفّقات ذات عدد إجراءات قليل (استخراجها إلى تدفّق فرعيّ عند الحاجة)¹⁵.
• ينشأ خطر الإفلات. عند تفعيل ضبط التزامن، عدد التنفيذات القادرة على الانتظار محدود بـ«10 + درجة التوازي»، والمشغِّلات التي تصل خلال بلوغ هذا الحدّ تُعاد محاولتها من جهة الموصل، لكن إن استمرّ التجاوز طويلاً فقد لا تصل إلى التنفيذ. بالنسبة للتدفّقات التي تريد ضمان وصول كلّ مشغِّل إلى التنفيذ بثقة، تنصّ الوثائق الرسميّة صراحة على إبقاء ضبط التزامن معطَّلاً¹. إن كان سجلّ التنفيذ مليئاً بحالات الإلغاء، قد يكون هذا الإعداد هو السبب¹¹.

بمعنى آخر، «الحفاظ على الترتيب» و«عدم الإفلات» مفاضلة. تسلسل درجة التوازي 1 فعّال في المعالجة قليلة التدفّق والمهمّة الترتيب (كترقيم السجلّ المتسلسل)، لكن لا يجب استخدامه بلا تروٍّ في المعالجة التي تصلها أحداث كثيرة وقت الذروة. إن لزم الترتيب والشمول الكامل معاً بدقّة، فالأمر يدخل في نطاق ينبغي تصميمه خارج Power Automate كما سيُذكر في الفصل 8.

7. قائمة تحقّق التصميم قبل الإطلاق الإنتاجيّ

قبل وضع تدفّق جديد في الإنتاج، تحقّق على الأقلّ من النقاط التالية. المثاليّ أن تكتمل كلّها في اليوم الأوّل، لكن لخفض عتبة الإدخال قسّمناها إلى درجتين: «الحدّ الأدنى» (بدونه يبقى الحادث غير مرئيّ) و«إن توفّر متّسع» (تُملأ خلال شهر بعد دخول التشغيل).

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

8. إلى أيّ حدّ تُنفَّذ المهمّة عبر Power Automate

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

بحسب الإحساس العمليّ: «طالما يمكن شرح إجراء التعافي عند الفشل شفهيّاً فهو نطاق Power Automate، وعندما يتعذّر شرحه دون رسم مخطّط فهو نطاق التطوير». الأعمال التي تحتاج بالذات إلى معاملة تعويضيّة (سُجّل في نظام الشركة A، وفشل في نظام الشركة B، فهل نُلغي A؟) أكثر تعقيداً ممّا يبدو عليه شكل التدفّق، ولا يكفيها Terminate والإشعار. رتّبنا القرار بما يشمل التمييز عن مجدوِل المهام وPowerShell في «التمييز بين استخدام Power Automate وPowerShell ومجدوِل المهام».

9. الخلاصة

«التدفّق الذي كان يعمل توقّف» ليس سوء حظّ، بل هو تقريباً مشكلة تصميميّة. التدفّق يفشل حتماً. من بين التصنيفات الأربعة للفشل، إعادة المحاولة تتكفّل بالعطل المؤقّت فقط، أمّا الفشل الناتج عن البيانات وانتهاء المصادقة وتغيير المواصفات فلا سبيل لالتقاطها سوى بآليّة متعدّدة الطبقات: الالتقاط عبر Try-Catch، والتسجيل عبر Terminate، والإشعار الذاتيّ، والمراجعة الأسبوعيّة لسجلّ التنفيذ. رسالة إشعار الفشل الافتراضيّة آليّة محدودة، مشروطة، ومصحوبة بفترة تهدئة 28 يوماً، والاعتماد عليها في التشغيل يسبّب حتماً إفلاتاً.

والحصن الرئيسيّ للاستعداد للفشل هو التصميم المتكافئ أكثر من الإشعار. إذا صمّمت الأمر بحيث «لا ينهار حتّى مع التنفيذ المزدوج» عبر علامة معالَج وupsert، لن تخشى بعد الآن إعادة الإرسال ولا التشغيل المكرَّر للمشغِّل، ويكفي التعافي بـ«اختيار الجزء الفاشل وإعادة إرساله». وبالمقابل، الأعمال التي تحتاج معاملة تعويضيّة أو ضمان ترتيب صارم، من الأرخص على المدى الطويل عدم بنائها بالقوّة داخل Power Automate، بل فصلها إلى نطاق التطوير. في اليوم نفسه الذي يبدأ فيه التشغيل، جرّب مراجعة هذه القائمة مرّة واحدة.

مقالات ذات صلة

• أتمتة الأعمال باستخدام Power Automate ── الفصل بين التدفّق السحابي وتدفّق سطح المكتب وتصميم معالجة الأخطاء
• تصميم تدفّقات التنفيذ الدوريّ في Power Automate ── الممارسة العمليّة لمعالجة نهاية الشهر وتحديد أيّام العمل والتذكيرات
• بناء سير موافقات باستخدام Power Automate ── رقمنة مستندات الاعتماد الداخلي والطلبات الورقيّة والبريديّة
• معالجة الاعتماد على شخص واحد في Power Automate ── كي لا يتوقّف التدفّق إذا استقال من أنشأه
• التمييز بين استخدام Power Automate وPowerShell ومجدوِل المهام

مجالات الاستشارة ذات الصلة

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

• الاستشارة التقنيّة ومراجعة التصميم
• تطوير تطبيقات Windows
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

إذا فشل تدفّق Power Automate، هل تصل رسالة إشعار تلقائيّاً؟

تصل بشكل محدود فقط. رسالة تنبيه الفشل على مستوى التنفيذ تُرسَل إلى المالك والملّاك المشاركين عندما يُصنَّف الفشل كـ«فشل له طريقة إصلاح معروفة» مثل انقطاع الاتّصال أو التقييد (throttling)، ولا تُرسَل عند فشل الإجراءات العامّة. علاوة على ذلك، بعد إرسالها مرّة توجد فترة تهدئة مدّتها 28 يوماً لنفس التدفّق، لا تصل خلالها تنبيهات إضافيّة. كما أنّ تنبيهات الفشل على مستوى التنفيذ ليست مفعَّلة افتراضيّاً في كلّ التدفّقات. للتأكّد من الانتباه إلى الفشل، يُنصَح بدمج تصميم يُرسل إشعاراً ذاتيّاً إلى Teams أو البريد من كتلة Catch.

كم مرّة، وبأيّ فاصل زمنيّ، تُجرى إعادة المحاولة القياسيّة في Power Automate؟

عندما يتجاوز طلب الإجراء المهلة الزمنيّة أو يفشل باستجابة من نوع 408 أو 429 أو 5xx، تُعاد المحاولة آليّاً افتراضيّاً مع إطالة الفاصل أُسّيّاً. يختلف العدد باختلاف ملف أداء التدفّق (وهو عمليّاً طبقة الترخيص): أقصى مرّتين في الملفّات المنخفضة كترخيص Microsoft 365، وأقصى 12 مرّة في الملفّات المتوسّطة والعالية كـ Power Automate Premium أو ترخيص Process. يمكن تغيير سياسة إعادة المحاولة في إعداد الإجراء إلى «بلا / فاصل ثابت / فاصل أُسّيّ»، ويمكن ضبط العدد حتّى 90 مرّة كحدّ أقصى. الأخطاء الناتجة عن البيانات أو الإعدادات مثل 400 أو 404 ليست هدفاً لإعادة المحاولة.

كيف يمكن إعادة تنفيذ (إعادة إرسال) تنفيذ تدفّق فشل؟

افتح التنفيذ الفاشل من سجلّ التنفيذ، واختر «إعادة الإرسال» لإعادة التنفيذ بنفس بيانات المشغِّل. إذا كان السبب خطأً في تعريف التدفّق، فإصلاح التدفّق وحفظه ثمّ إعادة الإرسال يعيد التنفيذ بالمحتوى المُصلَح. من قائمة سجلّ التنفيذ يمكن إعادة إرسال حتّى 20 تنفيذاً دفعة واحدة. نقطة الحذر أنّ إعادة الإرسال تعيد تنفيذ التدفّق من البداية، لذا في التنفيذ الذي نجح جزئيّاً تُنفَّذ المعالجة الناجحة مرّة أخرى. يلزم تصميم متكافئ (idempotent) لا ينهار حتّى مع التنفيذ المزدوج (علامة معالَج، والكتابة بالتحديث لا بالإنشاء).

هل يمكن أن يُعطَّل التدفّق دون علم صاحبه؟

نعم. تُعطَّل تلقائيّاً خلال 14 يوماً التدفّقات التي يستمرّ فشل المشغِّل أو الإجراء فيها. كذلك تُعطَّل خلال 14 يوماً التدفّقات التي يستمرّ فيها التقييد (تجاوز الحدّ). وقد يُعطَّل التدفّق الذي لم يُشغَّل ولو مرّة خلال 90 يوماً إن لم يكن صاحبه يملك ترخيص Premium أو ترخيص سعة. بما أنّ إهمال الفشل يقود مباشرة إلى توقّف التدفّق، من المهمّ دمج آليّة للانتباه إلى الفشل والمراجعة الدوريّة لسجلّ التنفيذ (28 يوماً افتراضيّاً) في التشغيل.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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