شركة كومورا سوفت ذ.م.م.
تواصل معنا
القائمة

تصميم تدفّقات التنفيذ الدوريّ في Power Automate ── الممارسة العمليّة لمعالجة نهاية الشهر وتحديد أيّام العمل والتذكيرات

· آخر تحديث: · · Power Automate, التدفقات السحابية, التنفيذ الدوري, أيام العمل, العطلات الرسمية, SharePoint, Microsoft 365, أتمتة الأعمال, الاستشارات التقنية

«عندما تقترب نهاية الشهر، يرسل موظّف المحاسبة إلى كلّ قسم بريداً يقول: موعد إغلاق تسوية النفقات هو اليوم كذا»، «كلّ صباح بعد بدء العمل، يفتح [الموظّف] قائمة الطلبات ويتحقّق بصريّاً من عدم وجود طلبات غير معالَجة متبقّية»، «تُتابَع المستندات المتجاوزة موعد التسليم مقابل السجلّ وتُستحَثّ واحدة تلو الأخرى». حتّى في الشركات التي أدخلت Microsoft 365، لا تزال أعمال «ينظر فيها الإنسان إلى التقويم والسجلّ ثمّ يتحرَّك» باقية بشكل يفوق التوقّع. حالة يؤدّي فيها النسيان إلى حادثة، لكنّ آليّة عدم النسيان لا تتجاوز ذاكرة الموظّف وجدول مواعيد Outlook.

باستخدام التنفيذ المجدوَل في Power Automate (مشغِّل Recurrence)، يمكن أتمتة هذا النوع من الأعمال الدوريّة. غير أنّه عند محاولة بنائه فعليّاً في أعمال يابانيّة، تصطدم فوراً بثلاثة حواجز: كون الوقت الافتراضيّ هو UTC (التوقيت العالميّ المنسَّق)، وعدم وجود مفهوم «يوم العمل» ضمن المدمَج، وضرورة كتابة تحديد «نهاية الشهر» أو «إغلاق اليوم 20» بصيغة (expression). في هذا المقال، نرتّب مواصفات مشغِّل Recurrence ومطبّاته، وصندوق أدوات حساب التواريخ، وتحديد يوم العمل عبر جدول مرجعيّ للعطلات، وتصميم التذكير دون الإفراط في الاستحثاث، ووصولاً إلى مخاطر التشغيل الخاصّة بتدفّق التنفيذ الدوريّ.

كذلك، شرحنا كيفيّة معالجة متطلّبات التاريخ اليابانيّة عبر الأنظمة عموماً - التقويم الوارِكيّ والعطلات الرسميّة وتاريخ الإغلاق - بالتفصيل في مقال منفصل بعنوان «معالجة التقويم الياباني والعطلات الرسمية وتاريخ الإغلاق في تطبيقات الأعمال ── تصميم مقاوم لتغيّر العصر، وJapaneseCalendar، وحساب أيام العمل في الممارسة العملية». هذا المقال هو النسخة العمليّة لتطبيق تلك الأفكار على تدفّقات Power Automate.

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

  • وقت مشغِّل Recurrence يُعامَل كـUTC إن لم تُحدَّد منطقة زمنيّة. حادثة «كانت النيّة كلّ صباح الساعة 9، وعملت فعليّاً الساعة 18 بتوقيت اليابان» تُمنَع باختيار «(UTC+09:00) أوساكا، سابورو، طوكيو» في حقل المنطقة الزمنيّة وتحديد وقت البدء صراحةً.12
  • يمكن إنشاء «التنفيذ في أيّام العمل فقط» عبر التكرار «أسبوع» + تحديد أيّام الأسبوع (الاثنين إلى الجمعة). لكن لا تُراعَى العطلات الرسميّة. أمّا يوم ثابت كـ«اليوم العشرين من كلّ شهر»، فيمكن إنشاؤه بتاريخ ووقت البدء + التكرار «شهر»، لكن التواريخ المتغيِّرة كـ«نهاية كلّ شهر» أو «تقديم اليوم العمل السابق إن كان يوم الإغلاق عطلة» لا يمكن تحديدها، لذا الحلّ العمليّ هو «التنفيذ يوميّاً والتحديد عبر صيغة».2
  • الدالّة utcNow() في الصيغ أيضاً دائماً UTC. حوِّل «اليوم» بتوقيت اليابان بواسطة convertTimeZone(utcNow(), ‘UTC’, ‘Tokyo Standard Time’) قبل استخدامه. إن نُسِي التحويل في تدفّق يعمل في حدود الساعة 8 صباحاً، يصبح «اليوم» هو اليوم السابق.34
  • لا توجد آليّة مدمَجة لتحديد العطلات الرسميّة اليابانيّة. لا توجد دالّة عطلات رسميّة أيضاً في قائمة دوالّ الصيغ5، والأسلوب المتّبَع هو الاحتفاظ بجدول مرجعيّ للعطلات (كقائمة SharePoint) خاصّ بك، وتحديد «هل اليوم يوم عمل» في بداية التدفّق ثمّ الإنهاء إن لم يكن كذلك. يمكن استخدام ملفّ CSV للعطلات الصادر عن مكتب مجلس الوزراء كمصدر أساسيّ للجدول المرجعيّ.6
  • اجعل التذكير رسالة واحدة مجمَّعة لكلّ مسؤول بدل «رسالة واحدة لكلّ عنصر». باستخدام إجراءات معالجة البيانات مثل Filter array وCreate HTML table، يمكن البناء بسهولة قراءة أكبر مع تجنّب تداخل Apply to each.7
  • يصعب الانتباه إلى «عدم عمل» تدفّق التنفيذ الدوريّ. على افتراض مواصفات التعطيل التلقائيّ بعد 14 يوماً من الفشل المتتالي، والتعطيل بعد 90 يوماً بلا مشغِّل، وسجلّ التنفيذ الافتراضيّ 28 يوماً، صمِّم إشعار الفشل وسجلّ التنفيذ منذ البداية.89

2. جرد «الأعمال التي يتحرّك فيها الإنسان بالنظر إلى التقويم»

أوّل ما ينبغي فعله ليس بناء التدفّق، بل حصر الأعمال «التي تعمل بالنظر إلى التقويم»، وتصنيفها حسب ملاءمتها للتنفيذ الدوريّ.

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

معيار التصنيف ثلاثة: هل يمكن التعبير عن شرط الحكم بالبيانات (لا يمكن أتمتة «حالة تبدو مريبة إلى حدّ ما»)، هل يمكن صياغة قاعدة يوم التنفيذ، هل يمكن التعافي في اليوم التالي عند الفشل (ما لا يمكن هو نطاق تطوير الفصل 8).

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

3. أساسيّات مشغِّل Recurrence ومطبّاته

يُنشَأ التدفّق السحابيّ للتنفيذ المجدوَل كـ«تدفّق سحابيّ مجدوَل»، وتُضبَط الوتيرة والفاصل عبر مشغِّل Recurrence (التكرار).1 يمكن اختيار الوتيرة من الثانية والدقيقة والساعة واليوم والأسبوع والشهر، وأقلّ فاصل 60 ثانية وأقصاه 500 يوم.8 المواصفات نفسها بسيطة، لكنّه مشغِّل مليء بالمطبّات أيضاً.

الفخّ 1: الافتراضيّ هو UTC ── «كانت النيّة 9، وعملت 18»

الحادثة الأكثر شيوعاً. إن لم تُحدَّد منطقة زمنيّة، يُفسَّر وقت بدء مشغِّل Recurrence بصيغة UTC مع Z في النهاية (YYYY-MM-DDThh:mm:ssZ). إن اختيرت اليابان في حقل المنطقة الزمنيّة، يُعامَل وقت البدء كوقت محليّ لتلك المنطقة (YYYY-MM-DDThh:mm:ss، بلا Z).12 لإنشاء «تدفّق يُخطِر كلّ صباح الساعة 9»، الصحيح هو ضبط المنطقة الزمنيّة على «(UTC+09:00) أوساكا، سابورو، طوكيو» وضبط وقت البدء على 9:00.

الفخّ 2: عدم تحديد وقت البدء يجعل التدفّق يعمل فور الحفظ

إن لم يُحدَّد تاريخ ووقت بدء، يُنفَّذ أوّل تنفيذ فوراً لحظة حفظ التدفّق.2 هذا مقبول أثناء الاختبار، لكن قد تحدث حادثة يُحفَظ فيها تدفّق مُدرَج فيه رسالة استحثاث مساءً، فتُرسَل الاستحثاثات فوراً إلى الجميع. حدِّد تاريخ البدء دائماً.

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

الفخّ 3: «أيّام العمل فقط» ممكن، لكن التحديد التفصيليّ الشهريّ محدود

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

مع ذلك، الشهريّ ذو التاريخ الثابت لا يحتاج إلى التشغيل يوميّاً. إن ضُبِط تاريخ ووقت البدء على اليوم المستهدَف (اليوم العشرين من الشهر القادم الساعة 9:00 مثلاً) وضُبِطت الوتيرة على «شهر»، يصبح التنفيذ كلّ شهر انطلاقاً من تاريخ ووقت البدء، فيمكن إنشاء «اليوم العشرين من كلّ شهر الساعة 9» بإعداد المشغِّل وحده.2 تشغيل تدفّق 365 مرّة يوميّاً واستبعاده بالتحديد بينما يكفيه 12 مرّة شهريّاً يُصعِّب قراءة سجلّ التنفيذ ويستهلك عدد الطلبات دون داعٍ، فتجنَّب ذلك.

أمّا تكوين «التنفيذ يوميّاً + التحديد بصيغة في بداية التدفّق حول كون اليوم مستهدَفاً» فيصبح ضروريّاً في الشهريّ ذي التاريخ المتغيِّر. التواريخ مثل «نهاية كلّ شهر» (تتراوح بين 28 و31 حسب الشهر)، أو «إن كان اليوم 20 عطلة نهاية أسبوع أو رسميّة، فاليوم العمل السابق»، أو «يوم العمل الرابع من كلّ شهر مثلاً» لا يمكن التعبير عنها بالمشغِّل. سنتناول صيغة هذا التحديد في الفصل التالي. علماً بأنّ التاريخ الثابت المضبوط بين 29 و31 يحتاج إلى التحقّق يدويّاً من سلوكه في الشهر الذي لا يحوي ذلك اليوم، لذا من الأسلم توجيه المعالجة قرب نهاية الشهر منذ البداية نحو أسلوب «التنفيذ يوميّاً + التحديد».

الفخّ 4: التوقيت الصيفيّ ── حذر خاصّ بالفروع الخارجيّة فقط

إن كُتِب الوقت بـUTC دون اختيار منطقة زمنيّة، في المناطق التي بها توقيت صيفيّ (DST)، ينزلق وقت التنفيذ ساعة واحدة عند كلّ تبديل. إن اخترتَ منطقة زمنيّة، يتبع الجدول تغيّر الفصول ويظلّ محافَظاً عليه.10 لا توجد ضرر فعليّ داخل اليابان لعدم وجود توقيت صيفيّ فيها، لكن إن كنتَ تتعامل مع إشعارات لفروع خارج البلاد في نفس التدفّق، فمن الضروريّ اختيار المنطقة الزمنيّة الخاصّة بذلك الفرع صراحةً.

الفخّ 5: الصيغة المكتوبة في المشغِّل تُثبَّت وقت الحفظ

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

الفخّ 6: لا يُنفَّذ لاحقاً ما فات أثناء الإيقاف

مشغِّل Recurrence لا يعالج دفعة واحدة عند إعادة التشغيل الجدولة التي فاتت أثناء إيقاف التدفّق، بل يستأنف من الدورة التالية.10 قد تحدث حادثة مثل «أوقِف تدفّق معالجة نهاية الشهر لأيّام بسبب تعديل، وصادف ذلك تخطّي يوم تنفيذ نهاية الشهر، فلم يعمل نصيب هذا الشهر». عند إيقاف تدفّق التنفيذ الدوريّ، اجعل التشغيل يتحقّق من موعد التنفيذ التالي المتوقَّع قبل الإيقاف.

4. صندوق أدوات حساب التواريخ ── تحديد نهاية الشهر وبدايته وموعد الإغلاق بالصيغ

حساب التواريخ داخل التدفّق يُكتَب بصيغ (دوالّ) مشتركة مع Logic Apps.5 الأساس هو أنّ utcNow() تُرجِع دائماً الوقت الحاليّ بتوقيت UTC.12 لذا فإنّ التكوين الذي يُنشئ «اليوم» بتوقيت اليابان في بداية التدفّق ويضعه في متغيِّر (أو Compose) ثمّ يستخدمه فيما بعد يجعل الصيغ أسهل قراءة.

convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd')

دالّة convertTimeZone(الطابع الزمنيّ، المصدر، الوجهة، الصيغة) هي دالّة تحويل المنطقة الزمنيّة13، وأسماء المناطق الزمنيّة تستخدم أسماء قائمة مناطق Windows الزمنيّة. اسم اليابان هو «Tokyo Standard Time».4 إن لم ترغب في كتابة صيغة، يوجد أيضاً إجراء «تحويل المنطقة الزمنيّة» الذي يؤدّي نفس الأمر.13

سبب لزوم التحويل هو وجود فرق 9 ساعات بين UTC وتوقيت اليابان. حتّى الساعة 9 صباحاً بتوقيت اليابان، لا يزال اليوم السابق بتوقيت UTC. إن كتبتَ في تدفّق يعمل الساعة 8 صباحاً formatDateTime(utcNow(), 'yyyy-MM-dd')، فإنّ «اليوم» المُرجَع سيكون تاريخ اليوم السابق. بما أنّ انزياح التاريخ يظهر أو لا يظهر حسب وقت التنفيذ، يصعب ملاحظته في الاختبار، ويُكتشَف في الإنتاج الفعليّ بشكل مثل «تشغيل معالجة كانت مفترَضة لبداية الشهر في آخر يوم من الشهر أيضاً».

بعد إنشاء «اليوم» بتوقيت اليابان (نسمّيه فيما يلي اليوم)، نرتّب أنماط التحديد.

ما تريد فعله مثال الصيغة ملاحظة
أخذ يوم الأسبوع dayOfWeek(اليوم) 0=الأحد، 1=الاثنين، …، 6=السبت.12
هل هو عطلة نهاية أسبوع or(equals(dayOfWeek(اليوم), 0), equals(dayOfWeek(اليوم), 6)) كتابة «إن كان أكبر من 5 فهو نهاية أسبوع» يفوِّت يوم الأحد (0)12
هل هو أوّل الشهر (اليوم 1) equals(formatDateTime(اليوم, 'dd'), '01') يمكن أيضاً أخذ تاريخ أوّل الشهر نفسه عبر startOfMonth()5
هل هو يوم الإغلاق (اليوم 20) equals(formatDateTime(اليوم, 'dd'), '20') لا تُثبِّت يوم الإغلاق في الكود، بل أخرِجه إلى متغيِّر بيئة أو قائمة إعدادات لإعادة الاستخدام
هل هو نهاية الشهر not(equals(formatDateTime(اليوم, 'MM'), formatDateTime(addDays(اليوم, 1), 'MM'))) «إن اختلف شهر اليوم عن شهر الغد، فاليوم نهاية الشهر». يعمل بشكل صحيح حتّى في فبراير والسنة الكبيسة
تاريخ نهاية الشهر الحاليّ addDays(startOfMonth(addToTime(اليوم, 1, 'Month')), -1, 'yyyy-MM-dd') يُشتَقّ كـ«اليوم السابق لبداية الشهر التالي». لا حاجة للاهتمام بعدد أيّام الشهر
N يوم قبل/بعد addDays(اليوم, -3) / addDays(اليوم, 7) جمع وطرح الأيّام التقويميّة. الأساس على يوم العمل في الفصل 5

الدوالّ addDays وaddToTime وstartOfMonth وformatDateTime وdayOfWeek كلّها معرَّفة في مرجع الصيغ المشترك بين Logic Apps وPower Automate.5 الصيغ المركَّبة في الجدول نفسها من نمط تنفيذ الكاتب، لذا عند الإدخال اختبرها بتواريخ تعبر نهاية الشهر وبدايته والسنة الكبيسة (29 فبراير) قبل وضعها في الإنتاج الفعليّ. شرحنا خطورة أخطاء التواريخ التي لا تظهر إلا في يوم معيّن، وكيفيّة اختيار التواريخ الواجب تجربتها مسبقاً، في الفصل 4 من مقال التقويم الياباني والعطلات الرسميّة وتاريخ الإغلاق.

5. تحديد يوم العمل ── احتفظ بالعطلات في جدول مرجعيّ

لا وجود لتحديد العطلات الرسميّة المدمَج

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

طريقة الاحتفاظ في Power Automate الأسهل هي إنشاء «جدول مرجعيّ للعطلات» (عمود التاريخ + عمود الاسم) في قائمة SharePoint. يمكن استخدام ملفّ CSV الذي ينشره مكتب مجلس الوزراء الياباني، ويحتوي على تواريخ العطلات الرسميّة وأسمائها من عام شووا 30 حتّى السنة التالية (تشمل أيضاً أيّام العطلة البديلة كصفوف) كمصدر أساسيّ.6 بما أنّ المنشور يقتصر على الجزء المؤكَّد فقط، فإنّ إدراج مهمّة استيراد عطلات السنة التالية إلى الجدول المرجعيّ مرّة سنويّاً في التقويم التشغيليّ جزء من التصميم أيضاً. نسيان التحديث يتحوّل مباشرةً إلى خلل تشغيليّ يتمثّل في وصول استحثاث في عطلة السنة التالية. كذلك، اجعل عطلات الشركة كالإجازة الصيفيّة أو ذكرى التأسيس في قائمة منفصلة، دون خلطها بجدول العطلات الرسميّة، لأنّ «تحديد موعد الحوالة المصرفيّة ينظر إلى العطلات الرسميّة فقط» بينما «الاستحثاث الداخليّ ينظر أيضاً إلى عطلات الشركة»، أي تختلف مجموعة العطلات المرجعيّة حسب الاستخدام.

«حارس يوم العمل» في بداية التدفّق

بالنسبة للتدفّقات المراد تشغيلها في أيّام العمل فقط، إلى جانب تحديد أيّام الأسبوع في Recurrence (الاثنين إلى الجمعة)، ضَع التحديد التالي في بداية التدفّق.

  1. أنشئ «اليوم» بتوقيت اليابان (الفصل 4)
  2. نفِّذ إجراء «الحصول على عدّة عناصر (Get items)» من SharePoint على الجدول المرجعيّ للعطلات، وابحث عن تاريخ اليوم عبر استعلام تصفية مثل HolidayDate eq 'اليوم'14
  3. نفِّذ البحث نفسه أيضاً على قائمة عطلات الشركة
  4. إن وُجد ولو تطابق واحد، أوقِف التنفيذ عبر إجراء «إنهاء (Terminate)»

Terminate إجراء يوقف تنفيذ التدفّق في تلك اللحظة وينهيه بالحالة المحدَّدة (نجاح/فشل/إلغاء) (لا يمكن وضعه داخل حلقة Apply to each أو Do until).15 إن ضبطتَ الحالة هنا إلى «ملغى»، يمكن التمييز بنظرة واحدة في سجلّ التنفيذ بين «اليوم الذي تُخُطِّي لأنّه ليس يوم عمل» و«اليوم الذي عملت فيه المعالجة فعليّاً». هذا أسهل للتحقيق لاحقاً من توحيد كلّ شيء تحت «نجاح».

«التقديم إلى يوم العمل السابق» و«N يوم عمل قبل»

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

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

6. تصميم التذكير والاستحثاث ── رسالة واحدة مجمَّعة لكلّ مسؤول

الافتراض: أن يكون السجلّ بيانات

لا يمكن أتمتة استحثاث تجاوز الموعد إلا إذا أمكن أخذ «ماذا، ومسؤول من، وموعد متى» كبيانات. إن كان السجلّ ملفّ Excel يدور في مجلّد مشترك عبر مرفقات البريد الإلكترونيّ، ففكِّر أوّلاً في استبداله بقائمة SharePoint (تناولناه في «استبدال سجلّ Excel بقائمة SharePoint»). ما يلي يفترض وجود أعمدة «الموعد» و«الحالة» و«المسؤول» في قائمة SharePoint.

ضيِّق الاستخراج عند الجلب

استخراج تجاوز الموعد يُضيَّق من جهة الخادم عبر استعلام تصفية (فلتر OData) في Get items، بدل جلب كامل القائمة والتفريع الشرطيّ داخل التدفّق.14

DueDate lt '2026-07-18' and Status ne 'مكتمل'

يُدرَج في جزء التاريخ صيغة «اليوم» بتوقيت اليابان التي أنشأناها في الفصل 4. انتبه إلى أنّ أسماء الأعمدة في استعلام التصفية يجب كتابتها بالاسم الداخليّ لـSharePoint لا اسم العرض في الشاشة، وأنّ الافتراضيّ يُرجِع 100 عنصر فقط، ما يستلزم في القوائم كثيرة العناصر تحديد الحدّ الأقصى للعدد (Top Count) أو إعداد تقسيم الصفحات.14

تجنّب جحيم Apply to each ── طريقة صنع «رسالة واحدة مجمَّعة»

إن دوَّرتَ نتيجة الاستخراج كما هي عبر Apply to each وأرسلت بريداً لكلّ عنصر، فإن كان لدى المسؤول أ 10 عناصر غير معالَجة، تصله 10 رسائل كلّ صباح. استمرار هذا لأسابيع يجعل الإشعار غير مقروء بالتأكيد، فتموت آليّة التذكير نفسها. المبدأ هو تجميع الإشعار في رسالة واحدة لكلّ مسؤول. باستخدام إجراءات معالجة البيانات، يمكن البناء بالتدفّق التالي.7

  1. أنشئ عبر Select مصفوفة عناوين بريد المسؤولين من نتيجة الاستخراج، وأنشئ عبر union() «قائمة المسؤولين الواجب إشعارهم اليوم» بعد إزالة التكرار5
  2. دوِّر قائمة المسؤولين عبر Apply to each، واستخدم Filter array داخلها لاستخراج «عناصر هذا المسؤول فقط»
  3. نسِّقها كجدول عبر Create HTML table يضمّ الموضوع والموعد والحالة، وضمِّنه في نصّ البريد (أو رسالة Teams) وأرسِل رسالة واحدة فقط (في حالة البريد، فعِّل عرض HTML7)

الصورة الكاملة تبدو كالتالي.

نعملالانعممشغِّل Recurrenceأيّام العمل الساعة 9:00 صباحاً، المنطقة الزمنيّة: أوساكا، سابورو، طوكيوإنشاء «اليوم» بتوقيت اليابانconvertTimeZoneهل «اليوم» موجود في الجدول المرجعيّ للعطلاتأو عطلات الشركة؟Terminate ملغىإنهاء لأنّه ليس يوم عملGet itemsاستخراج المتجاوز للموعد وغير المكتملهل توجد عناصر مستهدَفة؟إنهاء بلا إشعارإنشاء قائمة المسؤولين عبر Selectوإزالة التكرار عبر unionحلقة لكلّ مسؤولFilter arrayاستخراج عناصر هذا المسؤول فقطتنسيقها كجدول عبر Create HTML tableإرسال إشعار واحد فقط لكلّ مسؤولعبر Teams أو Outlookتسجيل نتيجة التنفيذ في قائمة السجلّ

التمييز بين Teams وOutlook

يُقسَّم مخرج الإشعار حسب الطبيعة.

المعيار Teams (المحادثة/القناة) Outlook (البريد الإلكترونيّ)
سهولة الانتباه عالية. لكن يسهل ضياعه وسط التدفّق لا يسبِّب إرهاق إشعارات، لكن يضيع وسط صندوق الوارد
قابليّة التسجيل ضعيفة. يصعب البحث عنه لاحقاً يبقى محفوظاً. يمكن استخدامه كدليل استحثاث
الوجهة داخل الشركة فقط يمكن الإرسال خارج الشركة أيضاً
الإشعار المناسب ملخّص يوميّ خفيف كملخّص غير المعالَج كلّ صباح الإعلان الرسميّ بالموعد، ما يحتاج دليل استحثاث، ما يُرسَل خارج الشركة

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

تصميم عدم الإفراط في الاستحثاث

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

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

7. ملاحظات التشغيل ── تدفّق التنفيذ الدوريّ «لا يمكن ملاحظة توقّفه»

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

  • يوجد شروط تُعطَّل بموجبها التدفّقات تلقائيّاً. تُعطَّل خلال 14 يوماً التدفّقات المستمرّ فشل المشغِّل أو الإجراء فيها، وكذلك تُعطَّل خلال 14 يوماً التدفّقات المستمرّ التقييد فيها. كذلك قد يُعطَّل التدفّق الذي لم يُشغَّل ولو مرّة خلال 90 يوماً (باستثناء صاحب ترخيص Premium أو ترخيص سعة كـProcess، ويصل إشعار إلى المالك والملّاك المشاركين قبل 30 يوماً من التعطيل، ويمكن الاستمرار بإعادة التفعيل).8 إن أنشأتَ «تدفّقاً يعمل مرّة كلّ ربع سنة فقط»، فانتبه إلى قاعدة الـ90 يوماً هذه.
  • لا يُعرَض سجلّ التنفيذ إلا لمدّة 28 يوماً افتراضيّاً.9 في التدفّق الشهريّ، هذا يعني إمكانيّة التحقّق من آخر مرّة فقط عمليّاً. أدرِج في نهاية التدفّق خطوة تُضيف سطراً بـ«وقت التنفيذ وعدد العناصر المعالَجة والنتيجة» إلى قائمة SharePoint مخصَّصة للسجلّ، بحيث يمكن التحقّق من «هل عمل الشهر الماضي جيّداً» بمعزل عن انتهاء صلاحيّة سجلّ التنفيذ. وضع تسجيل السجلّ في نهاية رسم الفصل 6 كان لهذا السبب.
  • اجعل التدفّق نفسه يملك آليّة للانتباه إلى الفشل. إن لم تُدرَج فرع الإشعار للمسؤول عند الفشل (إجراء يعمل عند «فشل» في تكوين شرط التنفيذ)، لن ينتبه أحد إلى الفشل طوال الأيّام الـ14 حتّى التعطيل. شرحنا طريقة بناء معالجة الأخطاء وإعادة المحاولة بالتفصيل في «معالجة الأخطاء وتصميم إعادة المحاولة في Power Automate».
  • توقّف الجدولة بأكملها باستقالة صاحبها أو انتقاله. تدفّق مشغِّل Recurrence يُنفَّذ باتّصال منشئ التدفّق.11 إن عُطِّل حساب صاحب التدفّق، ينقطع الاتّصال ويبدأ التدفّق بالفشل، ويُعطَّل في النهاية. أنجِز إعداد الملّاك المشاركين وجرد الاتّصالات منذ اليوم الأوّل للتشغيل.16 رتّبنا الممارسة العمليّة للتسليم في «تدابير مواجهة الارتباط الشخصيّ في Power Automate ── الملّاك والاتّصالات والتسليم».
  • لا يعمل نصيب فترة الإيقاف (الفخّ 6 في الفصل 3). عند إيقاف التدفّق للتعديل أو التعامل مع عطل، تحقّق من موعد التنفيذ التالي المتوقَّع، وإن حدث تخطٍّ لهذا الموعد، حدِّد مسبقاً عمليّة تعويضه بالتشغيل اليدويّ.10

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

التنفيذ الدوريّ مدخل ممتاز للأتمتة، لكن تحويل أيّ شيء «يعمل دوريّاً» إلى تدفّق أمر خطر. نذكر معياراً إرشاديّاً لحدّ الفصل.

الوضع القرار
فحص غير المعالَج كلّ صباح، تذكير الموعد، إشعار جماعيّ قبل يوم الإغلاق نطاق قوّة Power Automate. يكفي تكوين هذا المقال
الإشعار الذي يشمل تحديد يوم العمل والتقديم إلى يوم العمل السابق ممكن بـPower Automate + جدول مرجعيّ للعطلات. حدِّد أيضاً تشغيل تحديث الجدول المرجعيّ
حساب عدّة مئات × N يوم عمل، وتجميع يطابق عدّة قوائم حلقات التدفّق مرهقة. أخرِج المنطق خارجاً أو انتقل إلى نطاق التطوير
موعد إغلاق مختلف باختلاف الجهة المقابلة، مع قيود عكسيّة أو إعادة حساب تنفجر الفروع، ويلزم أيضاً التراجع عند الفشل. نطاق التطوير المتعاقَد عليه أو النظام المخصَّص
معالجة دفعيّة ليليّة عابرة لقاعدة بيانات النظام الأساسيّ نطاق تطوير. جوهر التصميم هو المعاملات وإعادة التنفيذ والاتّساق
خادم واحد، ومعالجة ملفّات/قاعدة بيانات دوريّة مكتملة داخل الشركة PowerShell + مجدوِل المهام خيار قويّ أيضاً. المقارنة في مقال منفصل

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

9. الخلاصة

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

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

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

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

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

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

  1. Microsoft Learn, Run a cloud flow on a schedule. حول خطوات إنشاء تدفّق سحابيّ مجدوَل، وتحديد المنطقة الزمنيّة التي يُعامَل بها وقت البدء في حقل المنطقة الزمنيّة لمشغِّل Recurrence، وصيغة وقت البدء (YYYY-MM-DDTHH:MM:SSZ). ↩ ↩2 ↩3

  2. Microsoft Learn, Schedule and run recurring workflows with the Recurrence trigger in Azure Logic Apps. حول تفسير وقت البدء كـUTC بإضافة Z في النهاية عند عدم اختيار منطقة زمنيّة، وتحديد الوتيرة والفاصل، وإتاحة تحديد أيّام الأسبوع (weekDays) عند الوتيرة «أسبوع» فقط وتحديد الوقت (hours/minutes) عند الوتيرة «يوم» أو «أسبوع» فقط، وتشغيل أوّل تنفيذ فوراً عند الحفظ إن لم يُحدَّد تاريخ ووقت البدء، وانزلاق وقت التنفيذ (drift) بالحساب النسبيّ من التنفيذ السابق عند عدم وجود تحديد دقيق للوقت. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  3. Microsoft Learn, Customize or format date and time values in a flow. حول استخدام Power Automate لـUTC افتراضيّاً، وطريقة التعامل مع الوقت المحليّ بدمج formatDateTime وconvertTimeZone. ↩

  4. Microsoft Learn, Default Time Zones. قائمة أسماء المناطق الزمنيّة في Windows. حول كون اسم المنطقة الزمنيّة لليابان (UTC+09:00 أوساكا، سابورو، طوكيو) هو «Tokyo Standard Time». ↩ ↩2

  5. Microsoft Learn, Reference guide to functions in expressions for workflows in Azure Logic Apps and Power Automate. حول دوالّ التاريخ المتاحة في الصيغ (utcNow، addDays، addToTime، startOfMonth، formatDateTime، dayOfWeek، convertTimeZone، إلخ) ودوالّ المجموعات (union، إلخ) وقوائمها وصياغتها. المصدر الذي أكَّدنا منه عدم وجود دالّة لتحديد العطلات الرسميّة. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  6. مكتب مجلس الوزراء الياباني, حول «العطلات الوطنيّة». حول قائمة العطلات المستندة إلى قانون العطلات الوطنيّة، وتحديد الاعتدال الربيعيّ والخريفيّ ونشره في السنة السابقة، وقاعدة العطلة البديلة، وتوفير ملفّ CSV لتواريخ العطلات وأسمائها من عام شووا 30 حتّى السنة التالية. ↩ ↩2

  7. Microsoft Learn, Use data operations. حول طريقة استخدام إجراءات معالجة البيانات مثل Select وFilter array وJoin وCreate HTML table، وتفعيل IsHtml عند إرسال جدول HTML بالبريد الإلكترونيّ. ↩ ↩2 ↩3

  8. Microsoft Learn, Limits of automated, scheduled, and instant flows. حول أقلّ فاصل تكرار 60 ثانية وأقصاه 500 يوم، وتعطيل التدفّق المستمرّ فشل المشغِّل أو الإجراء خلال 14 يوماً، وإمكانيّة تعطيل التدفّق الذي لم يُشغَّل خلال 90 يوماً (باستثناء صاحب ترخيص Premium أو ترخيص سعة، مع إشعار المالك والملّاك المشاركين قبل 30 يوماً)، وتعطيل التدفّق المستمرّ التقييد خلال 14 يوماً. ↩ ↩2 ↩3

  9. Microsoft Learn, Missing runs or triggers history for a flow. حول عدم حفظ سجلّ تنفيذ التدفّق إلا لمدّة 28 يوماً افتراضيّاً. ↩ ↩2

  10. Microsoft Learn, Schedules for recurring workflow triggers in Azure Logic Apps. حول انزلاق وقت التنفيذ ساعة واحدة عند تبديل التوقيت الصيفيّ إن لم تُختَر منطقة زمنيّة، وتتبّع الجدول لتغيّر الفصول عند اختيار منطقة زمنيّة، وعدم معالجة مشغِّل Recurrence للجدولة الفائتة أثناء التوقّف، بل استئنافه من الدورة التالية. ↩ ↩2 ↩3

  11. Microsoft Learn, Troubleshoot Power Automate trigger issues and errors. حول حساب الصيغة المكتوبة في مُدخَل المشغِّل (utcNow() وغيرها) وتثبيتها لحظة حفظ التدفّق، وعدم إعادة حسابها مع كلّ تنفيذ، وتنفيذ تدفّق مشغِّل Recurrence باتّصال منشئ التدفّق. ↩ ↩2

  12. Microsoft Learn, Expression cookbook for cloud flows. حول إرجاع utcNow() دائماً لـUTC، وكون القيمة المُرجَعة من dayOfWeek() هي 0=الأحد حتّى 6=السبت، وفوات يوم الأحد في تحديد «أكبر من 5». ↩ ↩2 ↩3

  13. Microsoft Learn, Convert a time zone. حول معاملات صيغة convertTimeZone (الطابع الزمنيّ، المصدر، الوجهة، الصيغة)، وإجراء «تحويل المنطقة الزمنيّة» ذي الوظيفة المكافئة. ↩ ↩2

  14. Microsoft Learn, In-depth analysis into Get items and Get files SharePoint actions. حول استعلام تصفية OData (eq/ne/lt/gt وغيرها، وتضمين الصيغ) في Get items، وكون عدد العناصر الافتراضيّ المُجلَب 100 عنصر وإمكانيّة تغييره عبر Top Count، وإعداد تقسيم الصفحات للقوائم التي تتجاوز 5000 عنصر. ↩ ↩2 ↩3

  15. Microsoft Learn, Schema reference guide for trigger and action types in Azure Logic Apps. حول إيقاف إجراء Terminate للتنفيذ وإرجاعه بالحالة المحدَّدة (Succeeded/Cancelled/Failed)، وعدم إمكانيّة وضعه داخل حلقات Foreach أو Until. ↩

  16. Microsoft Learn, Share a cloud flow. حول ما يمكن للملّاك المشاركين فعله (تعديل التدفّق، تحديث بيانات اعتماد الاتّصال، إلخ) وارتباط الاتّصال بالمستخدم الذي أنشأه. ↩

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

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

معالجة ملفّات PDF لطلبات الشراء والفواتير الواردة عبر البريد الإلكترونيّ آليّاً بواسطة Power Automate ── تصميم الحفظ والتصنيف والإشعار والقراءة

نستعرض تصميم أتمتة حفظ وتصنيف وإشعارات ملفّات PDF لطلبات الشراء والفواتير الواردة عبر البريد الإلكترونيّ باستخدام Power Automate. نشرح من...

قراءة المقالة

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

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

كيف أُشغِّل تدفّقاً مجدوَلاً في Power Automate كلّ صباح الساعة 9 بتوقيت اليابان؟
اختر في حقل المنطقة الزمنيّة لمشغِّل Recurrence «(UTC+09:00) أوساكا، سابورو، طوكيو» وحدِّد وقت البدء. إن لم تُحدَّد منطقة زمنيّة، يُعامَل وقت البدء كـUTC (التوقيت العالميّ المنسَّق) بإضافة Z في النهاية، فإن ضبطتَ «9:00» بنيّة توقيت اليابان، سيعمل فعليّاً الساعة 18:00 بتوقيت اليابان. كذلك، تُرجِع الدالّة utcNow() الموجودة في الصيغ (expressions) دائماً UTC، لذا عند استخدام «تاريخ اليوم» داخل التدفّق، حوِّله إلى توقيت اليابان أوّلاً بصيغة مثل convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd').
هل يملك Power Automate وظيفة لتحديد العطلات الرسميّة اليابانيّة؟
لا توجد وظيفة مدمَجة لذلك. يمكن عبر تحديد أيّام الأسبوع في مشغِّل Recurrence تنفيذ «أيّام العمل فقط»، لكن لا تُراعَى العطلات الرسميّة، ولا توجد أيضاً دالّة في قائمة الصيغ تُرجِع العطلات الرسميّة. في العمل الفعليّ، يُجهَّز جدول مرجعيّ (Master) خاصّ يحمل تواريخ العطلات (كقائمة SharePoint)، ويُبحَث في بداية التدفّق عن «هل اليوم موجود في الجدول المرجعيّ»، فإن لم يكن يوم عمل، يُنهى التدفّق. يمكن استخدام ملفّ CSV للعطلات الرسميّة الذي ينشره مكتب مجلس الوزراء الياباني كمصدر أساسيّ لتحديث الجدول المرجعيّ.
هل يمكن إنشاء تدفّق يُنفَّذ فقط في يوم العمل الأخير من كلّ شهر؟
إن كان يوماً ثابتاً كـ«اليوم العشرين من كلّ شهر»، يمكن إنشاء تنفيذ في نفس اليوم والوقت من كلّ شهر انطلاقاً من تاريخ ووقت البدء، بضبط تاريخ ووقت البدء على اليوم المستهدَف وضبط التكرار على «شهر». من ناحية أخرى، لا يوجد خيار لتحديد «نهاية كلّ شهر» مباشرةً في مشغِّل Recurrence، ولا يمكن التحديد التفصيليّ ليوم الأسبوع أو الوقت إلا عندما يكون التكرار «يوم» أو «أسبوع». المعالجة التي يتغيّر فيها التاريخ كنهاية الشهر تُنشأ كتدفّق يُنفَّذ يوميّاً (أو كلّ يوم عمل)، مع تحديد «هل اليوم نهاية الشهر» أو «هل اليوم يوم عمل» عبر صيغة في البداية، وإنهاء التدفّق في الأيّام غير المستوفية للشرط. يمكن كتابة تحديد نهاية الشهر بصيغة «إن اختلف شهر اليوم عن شهر الغد، فاليوم نهاية الشهر». ويمكن التعبير أيضاً عن «إن كانت نهاية الشهر عطلة نهاية أسبوع أو عطلة رسميّة، فنفِّذ في يوم العمل السابق» بإضافة تحديد الجدول المرجعيّ للعطلات إلى التكوين نفسه.
تعطَّل تدفّق التنفيذ الدوريّ دون علمي. لماذا؟
يملك Power Automate عدّة شروط تُعطَّل التدفّقات بموجبها تلقائيّاً. تُعطَّل خلال 14 يوماً التدفّقات التي استمرّ فيها فشل المشغِّل أو الإجراء، وكذلك تُعطَّل خلال 14 يوماً التدفّقات المستمرّ فيها التقييد (تجاوز الحدّ). كما قد يُعطَّل التدفّق الذي لم يُشغَّل ولو مرّة خلال 90 يوماً (باستثناء من يملك صاحبه ترخيص Premium أو ترخيص سعة، ويصل إشعار إلى المالك والملّاك المشاركين قبل 30 يوماً من التعطيل). بما أنّ تدفّق التنفيذ الدوريّ يصعب على أحد ملاحظة توقّفه، من المهمّ دمج الإشعار عند الفشل وسجلّ التنفيذ منذ البداية في التشغيل.

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

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

غو كومورا

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

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

تواصل معنا

روابط عامة

GitHub LinkedIn X COM_BLAS COM_BigDecimal
العودة إلى المدونة