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

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

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

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

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

• وقت مشغِّل Recurrence يُعامَل كـ UTC إن لم تُحدَّد منطقة زمنيّة. حادث «كلّ صباح الساعة 9» الذي يعمل الساعة 18 بتوقيت اليابان يُمنَع باختيار «(UTC+09:00) أوساكا، سابورو، طوكيو» في حقل المنطقة الزمنيّة، وتوضيح وقت البدء.¹²
• «التنفيذ في أيّام العمل فقط» يُبنى بتكرار «أسبوع» + تحديد أيّام الأسبوع (الاثنين إلى الجمعة). غير أنّ العطلات الرسمية لا تُراعَى. اليوم الثابت مثل «اليوم العشرين من كلّ شهر» يُبنى بتاريخ البدء + تكرار «شهر»، أمّا التاريخ المتغيّر مثل «نهاية كلّ شهر» و«إن كان تاريخ الإغلاق عطلة فيوم العمل السابق» فلا يمكن تحديده، لذا الحلّ العمليّ «التنفيذ يومياً والحكم بالصيغة».²
• utcNow() في الصيغ أيضاً UTC دائماً. «اليوم» بتوقيت اليابان يُستخدَم بعد التحويل بـ convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time'). إن نُسي التحويل في تدفّق يعمل في الثامنة صباحاً يصير «اليوم» أمس.³⁴
• لا توجد آليّة مدمجة لتحديد العطلات الرسمية اليابانية. قائمة دوال الصيغ لا تتضمّن دالة عطلات⁵، والقاعدة الثابتة حمل جدول عطلات (قائمة SharePoint ونحوها) بنفسك، والحكم في بداية التدفّق على «هل اليوم يوم عمل»، والإنهاء إن لم يكن كذلك. المصدر الأوّليّ للجدول يمكن أن يكون CSV العطلات من مكتب مجلس الوزراء.⁶
• التذكير ليس «رسالة لكلّ عنصر» بل رسالة واحدة مجمَّعة لكلّ مسؤول. باستخدام إجراءات تشغيل البيانات مثل Filter array وCreate HTML table يمكن البناء بوضوح مع تجنّب تداخل Apply to each.⁷
• تدفّق التنفيذ الدوريّ يصعب الانتباه إلى «عدم عمله». على افتراض مواصفات الإيقاف بعد 14 يوماً من الفشل المتواصل، والإيقاف بعد 90 يوماً بلا مشغِّل، وسجلّ التنفيذ 28 يوماً افتراضياً، صمِّم إشعار الفشل وسجلّ التنفيذ منذ البداية.⁸⁹

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

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

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

معايير الفرز ثلاثة. هل يمكن التعبير عن شرط الحكم ببيانات («القضايا الغريبة نوعاً ما» لا تُؤتمَت)، وهل يمكن صياغة قاعدة يوم التنفيذ لغوياً، وهل يمكن الاسترداد في اليوم التالي حتى عند الفشل (ما لا يمكن مجال تطوير الفصل 8).

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

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

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

نضع أوّلاً صورة شاملة في جدول سريع. رتّبناها بترتيب سهولة الوقوع في تدفّقات الأعمال الموجَّهة محلياً (6 حديث يخصّ وجود فروع خارجية فقط).

المطبّ 1: الافتراض UTC ── «يفترض أن تكون 9 فتصير 18»

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

المطبّ 2: بلا تحديد وقت البدء، يعمل مرّة في لحظة الحفظ

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

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

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

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

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

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

المطبّ 4: الصيغة المكتوبة في المشغِّل تُثبَّت عند الحفظ

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

المطبّ 5: ما فات أثناء التوقّف لا يُنفَّذ لاحقاً

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

المطبّ 6: التوقيت الصيفيّ ── انتبه فقط للفروع الخارجية

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

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

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

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

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

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

أين تُكتَب هذه الصيغة ── المتغيّرات وCompose، ثمّ علامة تبويب الصيغة

هذا موضع حيرة في مرحلة بدء التعامل مع Power Automate، فنقرّره أوّلاً.

• تهيئة متغيّر (Initialize variable): إجراء داخل «متغيّرات» عند «إضافة إجراء». يُنشَأ بتعيين الاسم والنوع (سلسلة وغيرها) والقيمة، ويُرجَع إليه بعد ذلك مثل variables('today'). ما تتغيّر قيمته داخل حلقة، أو ما تريد الكتابة فوقه لاحقاً بـ «تعيين متغيّر»، هنا.
• إنشاء (Compose): إجراء يظهر تحت «تشغيل البيانات» عند البحث عن compose في «إضافة إجراء»، ويحتفظ بنتيجة الصيغة المكتوبة في «الإدخال» كما هي. إجراء لإنهاء الأمر دون كتابة المحتوى نفسه مراراً⁷، لذا يناسب قيماً لا تتغيّر بعد حسابها مرّة مثل «اليوم بتوقيت اليابان». الرجوع يتمّ باسم الإجراء مثل outputs('Today').
• موضع كتابة الصيغة نفسها: في كلا الإجراءين، عند اختيار حقل إدخال القيمة تُفتَح لوحة اختيار المحتوى الديناميكيّ والصيغة، فالصق convertTimeZone(...) أعلاه في علامة تبويب «صيغة» (أيقونة fx العلامة) وثبِّت. المظهر يتغيّر حسب إصدار المصمِّم، لكنّ ترتيب «النقر على حقل الإدخال ثمّ علامة تبويب الصيغة» واحد.
• أسماء الإجراءات والمتغيّرات تُرجَع إليها من الصيغة، لذا تسميتها بأحرف إنجليزية وأرقام أسلم (الفراغات في الاسم تُستبدَل بشرطة سفلية).

فيما يلي في هذا المقال نرمز لـ «اليوم بتوقيت اليابان» المنشأ بهذه الصيغة بـ اليوم. في التدفّق الفعليّ استبدله بـ variables('today') أو outputs('Today'). نجمع أنماط الحكم بعد الإنشاء.

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

5. تحديد أيّام العمل ── العطلات تُحمَل في جدول

لا يوجد تحديد عطلات مدمج

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

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

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

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

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

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

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

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

هذا أصعب جزء في المقال للنقل، فنكتب حتى الصيغة وتكوين الإجراءات. الافتراض عبور حارس يوم العمل (الفقرة السابقة) ── أي ثبوت أنّ اليوم يوم عمل.

flowchart TD
    Start[عبور حارس يوم العمل<br/>ثبوت أنّ اليوم يوم عمل] --> Hol[إنشاء قائمة عطلات هذا الشهر<br/>Get items لجدول العطلات وأيّام إغلاق الشركة]
    Hol --> Days[حساب الأيّام المتبقّية<br/>طرح يوم اليوم من يوم نهاية الشهر]
    Days --> Zero{هل الأيّام المتبقّية 0}
    Zero -- نعم --> Run[اليوم آخر يوم عمل<br/>تنفيذ معالجة نهاية الشهر والتذكير]
    Zero -- لا --> Range[إنشاء مصفوفة تواريخ من الغد حتى نهاية الشهر<br/>range و addDays]
    Range --> Filter[استبعاد السبت والأحد والعطلات بـ Filter array]
    Filter --> Len{هل العدد المتبقّي 0}
    Len -- 0 عناصر --> Run
    Len -- عنصر فأكثر --> Skip[Terminate ملغى<br/>اليوم ليس يوم تقديم]

المحتوى الملموس كالتالي.

1. أنشئ قائمة عطلات هذا الشهر. اجلب حصّة هذا الشهر فقط من جدول العطلات وقائمة أيّام إغلاق الشركة بـ Get items، واجعلها بـ «اختيار» (Select) مصفوفة سلاسل بتنسيق yyyy-MM-dd فقط، واجمعها في واحدة بـ union().¹⁴⁵ اسم هذا الإجراء Holidays.

2. أخرج تاريخ نهاية الشهر والأيّام المتبقّية. استخدم صيغة الفصل 4 كما هي.

   نهاية الشهر:     addDays(startOfMonth(addToTime(اليوم, 1, 'Month')), -1, 'yyyy-MM-dd')
   الأيّام المتبقّية: sub(int(formatDateTime(نهاية الشهر, 'dd')), int(formatDateTime(اليوم, 'dd')))
   

3. إن كانت الأيّام المتبقّية 0، فاليوم نهاية الشهر. بما أنّ حارس يوم العمل عُبر، فاليوم آخر يوم عمل. امضِ إلى المعالجة كما هي.
4. إن كانت الأيّام المتبقّية 1 فما فوق، فأنشئ مصفوفة تواريخ من الغد حتى نهاية الشهر. عيِّن في بداية إجراء «اختيار» (Select) range(1, الأيّام المتبقّية)، وفي الخريطة addDays(اليوم, item(), 'yyyy-MM-dd'). الوسيط الثاني لـ range() يجب أن يكون عدداً صحيحاً موجباً⁵، لذا ضع تفريع الخطوة 3 حتماً أوّلاً (إن أُغفل هذا يسقط التدفّق بخطأ في يوم نهاية الشهر فقط).

5. استبعد السبت والأحد والعطلات. مرِّر مخرجات الخطوة 4 إلى «تصفية المصفوفة» (Filter array)، واجعل الشرط وضعاً متقدّماً واكتب الصيغة التالية.⁷ createArray(0, 6) أرقام يومَي الأحد والسبت¹²، وbody('Holidays') قائمة العطلات المنشأة في الخطوة 1.

   @and(not(contains(createArray(0, 6), dayOfWeek(item()))),
        not(contains(body('Holidays'), item())))
   

6. احكم بالعدد المتبقّي. إن كان اسم إجراء الخطوة 5 Filter array، يمكن الرجوع إلى مخرجاته بـ body('Filter_array') (فراغات الاسم تُستبدَل بشرطة سفلية). إن كان length(body('Filter_array')) 0 فـ «لا يوم عمل بعد اليوم» = اليوم آخر يوم عمل هذا الشهر فنفِّذ المعالجة، وإن كان 1 فما فوق فاليوم ليس يوم تقديم فأنهِ بـ Terminate (ملغى).⁵¹⁵

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

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

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

الافتراض: صيرورة السجلّ بيانات

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

ضيِّق عند الجلب

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

DueDate lt '2026-07-18' and Status ne '完了'

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

تجنّب جحيم Apply to each ── كيفيّة بناء رسالة واحدة مجمَّعة

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

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

الصورة الكاملة تصير هكذا.

flowchart TD
    Rec[مشغِّل Recurrence<br/>أيّام العمل 9:00 صباحاً المنطقة الزمنيّة: أوساكا، سابورو، طوكيو] --> Today[إنشاء اليوم بتوقيت اليابان<br/>convertTimeZone]
    Today --> Hol{هل يوجد اليوم في<br/>جدول العطلات وأيّام إغلاق الشركة}
    Hol -- يوجد --> Term[Terminate ملغى<br/>الإنهاء لأنّه ليس يوم عمل]
    Hol -- لا يوجد --> Get[Get items<br/>استخراج تجاوز الأجل وغير المكتمل]
    Get --> Any{هل يوجد مستهدَف؟}
    Any -- لا --> End([إنهاء بلا إشعار])
    Any -- نعم --> Sel[إنشاء قائمة المسؤولين بـ Select<br/>إزالة التكرار بـ union]
    Sel --> Each[حلقة لكلّ مسؤول]
    Each --> Filter[Filter array<br/>استخراج عناصر هذا المسؤول فقط]
    Filter --> Table[تنسيق جدول بـ Create HTML table]
    Table --> Send[إشعار المسؤول برسالة واحدة فقط<br/>Teams أو Outlook]
    Send --> Log[تسجيل نتيجة التنفيذ في قائمة السجلّ]

الفصل بين Teams وOutlook

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

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

تصميم لا يفرط في المتابعة

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

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

7. ملاحظات التشغيل ── تدفّق التنفيذ الدوريّ «لا يُنتبَه إلى توقّفه»

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

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

8. إلى أيّ حدّ نستخدم Power Automate؟

التنفيذ الدوريّ مدخل ممتاز للأتمتة، لكن جعل «ما يعمل دورياً» كلّه تدفّقاً خطر. نذكر مؤشّرات الخطّ الفاصل.

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

9. الخلاصة

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

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

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

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

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

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

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

روابط مرجعية

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

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

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

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

كيف أشغّل تدفّقاً مجدوَلاً في Power Automate كلّ صباح الساعة 9 بتوقيت اليابان؟

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

هل يملك Power Automate وظيفة لتحديد العطلات الرسمية اليابانية؟

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

هل يمكن إنشاء تدفّق يُنفَّذ فقط في يوم العمل الأخير من كلّ شهر؟

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

تعطّل تدفّق التنفيذ الدوريّ دون علمي. لماذا؟

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

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

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

غو كومورا

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

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