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

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

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

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

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

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

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

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

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

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

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

بمعنى آخر، حتّى مع تعريف التدفّق نفسه، تختلف «صلابة التحمّل أمام العطل المؤقّت» باختلاف ترخيص صاحبه. لا يؤثِّر ملف الأداء في عدد إعادة المحاولة فقط، بل يؤثِّر أيضاً في الحدّ الأقصى لعدد الطلبات يوميّاً، لذا يمكن الرجوع إلى فكرة طبقة الترخيص في «الحدّ الفاصل بين ترخيص Power Automate والموصِّلات القياسيّة/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') مصفوفة بنتائج (الحالة والمُدخَلات والمُخرَجات ونصّ الخطأ) الإجراءات مباشرةً تحت النطاق، فإذا ضيَّقتَ عبر «معالجة تصفية المصفوفة» إلى ما تكون حالته Failed أو TimedOut، يمكنك وضع اسم الإجراء الفاشل ونصّ رسالة الخطأ في الإشعار.³⁴ إن ضيّقتَ بـFailed فقط، يصبح ناتج الاستخراج فارغاً عند الدخول إلى Catch عبر انتهاء المهلة، وتسقط من الإشعار الخطوة الفاشلة الأهمّ. مع ذلك، استخرِج معرِّف التنفيذ من دالّة workflow() وابنِ عنوان URL مباشراً إلى سجلّ التنفيذ، فهذا يجعل التحقيق أسهل بكثير.⁴
• اختر لشرط تنفيذ نطاق Finally الحالات الأربع جميعها. ضَع هنا التنظيف الذي تريد تنفيذه دائماً سواء نجح أم فشل (حذف الملفّات المؤقّتة، تحديث عمود حالة السجلّ، إلخ).
• أنهِ التنفيذ الفاشل في النهاية عبر إجراء Terminate كـ«فشل». هذه أسهل نقطة يُنسى ضبطها. عندما يكتمل Catch بنجاح، يُعَدّ آخر إجراء في التنفيذ ككلّ ناجحاً، فيُسجَّل في سجلّ التنفيذ كـ«ناجح». بمعنى آخر، إن اكتفيت بالإشعار فقط ثمّ انتهيت، يختفي الفشل من سجلّ التنفيذ، ويفلت من المراقبة والتجميع اللاحق. أنهِ التنفيذ عبر Terminate بضبط الحالة Failed ورسالة الخطأ، ليُسجَّل التنفيذ في السجلّ كفاشل أيضاً.⁴³ لكن لا تضع Terminate مباشرةً في نهاية نطاق Catch. لأنّ Terminate ينهي التنفيذ بأكمله فوراً عند تلك النقطة، فلا يُنفَّذ نطاق Finally التالي، ويُتخطّى التنظيف اللازم بالذات في وقت الخطأ. كما في الرسم، ارفع علامة فشل (متغيِّر) في Catch واكتفِ بالإشعار حتّى ذلك الحدّ، ثمّ بعد اجتياز تنظيف Finally احكم على العلامة، وأنهِ عبر Terminate عند الفشل فقط، بهذا الترتيب.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

لهذا، أدرِج منذ البداية تصميماً متكافئاً (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 يوماً، والاعتماد عليها في التشغيل يسبِّب حتماً إفلاتاً.

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

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

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

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

تتعامل شركة Komura Soft المحدودة مع مراجعة معالجة الأخطاء وتصميم التشغيل لتدفّقات 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 يوماً افتراضيّاً) في التشغيل.

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

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

غو كومورا

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

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