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

«تجميع ملفّات CSV المتراكمة في مجلّد مشترك في ملفّ Excel كلّ صباح وإرسالها بالبريد إلى الرئيس المباشر» أو «نسخ القيم يدويّاً من عدّة أنظمة أعمال ولصقها للتجميع». نتلقّى مؤخّراً كثيراً من الاستشارات التي تريد أتمتة هذا النوع من الأعمال عبر Power Automate.

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

تكلفة تعلّم Power Automate منخفضة، ويمكن البدء به بلا كود أو بكود قليل (no-code/low-code). لكنّ هذه السهولة نفسها تجعله أداة يسهل معها تأجيل التصميم والانتقال إلى التشغيل الفعليّ كما هو. في هذا المقال، نكتب بالترتيب الذي يكثر التعثّر فيه في العمل الفعليّ: الفرق بين التدفّق السحابي وتدفّق سطح المكتب، وتقسيم الأدوار مع PowerShell وVBA، ومعالجة الأخطاء، وأفكار لتثبيت أتمتة واجهة المستخدم، والتعامل مع بيانات الاعتماد، والحوكمة والتشغيل، وأخيراً كيفيّة تحديد اللحظة التي يتجاوز فيها الأمر نطاق Power Automate.

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

• يضمّ Power Automate بشكل رئيسيّ نظامين: التدفّق السحابي (يربط الخدمات السحابيّة عبر الموصلات) وتدفّق سطح المكتب (RPA يؤتمت التعامل مع شاشات Windows وتطبيقات سطح المكتب). أوّل قرار تصميميّ هو تحديد أيّهما مطلوب.
• إذا أردتَ فقط أتمتة «عمل روتينيّ على الحاسوب»، فإنّ PowerShell كثيراً ما يكون مرشّحاً قبل Power Automate Desktop. فإذا لم يكن النقر أو الإدخال على الشاشة ضروريّاً، قد يكون PowerShell أسهل صيانةً وأسهل إخضاعاً لإدارة الإصدارات.
• قيمة اختيار Power Automate كبيرة عندما يلزم التعامل مع شاشة نظام قائم قليل التكامل عبر API، أو عندما تريد بناء سير إشعارات/موافقات بسرعة عبر موصلات Microsoft 365 (مثل Outlook وSharePoint وTeams).
• عند الانتقال إلى التشغيل الفعليّ، أدرِج منذ البداية في التصميم هذه النقاط الأربع: معالجة الأخطاء (On Block Error)، وتثبيت مُحدِّدات واجهة المستخدم، والإدارة الآمنة لبيانات الاعتماد، والحوكمة عبر سياسات DLP. إضافتها لاحقاً مصدر للحوادث.¹²
• يحتاج التنفيذ غير المراقَب (unattended) رخصةً وشروطاً مسبقة مختلفة عن التنفيذ المراقَب (attended). إذا أُجِّل تصميم الرخص، قد يعمل السير في بيئة التحقّق ولا يعمل في الإنتاج.³⁴

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

2. الصورة الشاملة لـ Power Automate

Power Automate ليس منتجاً واحداً بقدر ما هو منصّة تجمع عدّة وسائل للأتمتة.

flowchart TB
    PA[Power Automate]
    PA --> Cloud["التدفّق السحابي"]
    PA --> Desktop["تدفّق سطح المكتب / RPA"]
    PA --> Process["تنقيب العمليّات"]
    PA --> Builder[AI Builder]

    Cloud --> Auto["تدفّق آليّ (مشغِّل بحدث)"]
    Cloud --> Sched["تدفّق مجدوَل (تنفيذ دوريّ)"]
    Cloud --> Instant["تدفّق فوريّ (تشغيل يدويّ/بزرّ)"]
    Cloud --> Connectors["الموصلات (SharePoint / Outlook / Teams / SQL وغيرها)"]

    Desktop --> Attended["تنفيذ مراقَب (أمام المستخدم)"]
    Desktop --> Unattended["تنفيذ غير مراقَب (على خادم/جهاز مخصّص)"]
    Desktop --> UIAuto["أتمتة واجهة المستخدم (الشاشة والتكامل مع التطبيقات القائمة)"]

• التدفّق السحابي آليّة تربط الخدمات السحابيّة ببعضها عبر الموصلات. حسب نوع المشغِّل ينقسم إلى تدفّق آليّ (عند وقوع حدث)، وتدفّق مجدوَل (تنفيذ دوريّ)، وتدفّق فوريّ (تشغيل يدويّ).
• تدفّق سطح المكتب هو RPA (Robotic Process Automation) يتعامل مباشرةً مع التطبيقات والشاشات على Windows. يمكن استدعاؤه من تدفّق سحابي، كما يمكن تشغيله منفرداً.⁵
• ينقسم تدفّق سطح المكتب أيضاً إلى تنفيذ مراقَب (attended) يعمل والشخص أمام الشاشة، وتنفيذ غير مراقَب (unattended) يعمل على حاسوب أو خادم مخصّص بلا تدخّل بشريّ.⁴

«الجهاز المخصّص» في التنفيذ غير المراقَب لا يعني أن يكفي ألا يكون مقفولاً. في Windows 10/11 يفشل التنفيذ غير المراقَب إذا بقيت جلسة أيّ شخص في حالة قفل، بغضّ النظر عمّا إذا كان مستخدم الاتّصال أم لا. في Windows Server النطاق أضيق قليلاً: يفشل إذا بقيت جلسة مقفلة لنفس مستخدم الاتّصال. بعد أعمال الصيانة أو اتّصال RDP من مسؤول آخر يسهل الاكتفاء بـ«قفل» أو «قطع»، لكن يلزم تسجيل خروج الجميع يقيناً.⁶

عند تلقّي استشارة نبدأ بالفصل: «هل هذا ربط خدمات سحابيّة ببعضها، أم تعامل مع شاشة؟». هذا وحده يوضّح المسار كثيراً.

3. الفصل بين التدفّق السحابي وتدفّق سطح المكتب وPowerShell وVBA

حتى داخل «الأتمتة»، تختلف المجالات التي يجيدها كلّ منها اختلافاً كبيراً.

سوء الفهم الشائع في العمل هو التفكير بأن «أريد أتمتة = إذن Power Automate مباشرة». تشغيل نظام يملك API جاهزاً عبر واجهة المستخدم في Power Automate Desktop حالة يكون فيها استدعاء الـ API مباشرة من PowerShell أو .NET أكثر استقراراً. بالمقابل، إذا لزم التعامل مع شاشة نظام أعمال قديم بلا API أو تطبيق Win32، تصبح أتمتة واجهة المستخدم في تدفّق سطح المكتب خياراً واقعيّاً.

ملاحظة: قيود Excel وVBA، وفكرة الاستبدال، مرتَّبة أيضاً في مقال منفصل: «ما هو VBA: حدوده، آفاقه المستقبليّة، متى يجب استبداله، وأنماط الترحيل العمليّة». يتناول أيضاً نمط الجمع بين Office Scripts وPower Automate لتدفّقات الأعمال على Microsoft 365.⁷

4. الرخص ── ما يلزم للتنفيذ غير المراقَب فقط

الصورة الشاملة لنظام الرخص (نطاق الرخصة المضمَّنة في Microsoft 365، وحدود الموصلات القياسيّة والموصلات Premium، وأيهما أرخص عند العدّ Premium أم Process، وأرصدة AI Builder) جمعناها مع جداول قرار في مقال منفصل: «تراخيص Power Automate ── إلى أيّ حدّ يكفي Microsoft 365 مجّاناً، ومتى تحتاج Premium». هنا نثبت ثلاث نقاط لا غنى عنها لتشغيل التنفيذ غير المراقَب، وهو موضوع هذا المقال.³

إن لم ترد تجهيز جهاز مادّي بنفسك، يوجد خيار Power Automate Hosted Process الذي ينفّذ بلا مراقبة على أجهزة ومجموعات أجهزة تستضيفها Microsoft.⁸

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

5. تصميم تطبيقيّ ── تجميع CSV من مجلّد مشترك، وبناء تقرير Excel، وإرساله بالبريد

نتّخذ مثالاً عمليّاً شائعاً: «إنشاء تقرير يوميّ».

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

أسماء الإجراءات في هذا المقال مكتوبة باسم واجهة المستخدم الإنجليزيّة. للعمل بواجهة يابانيّة نورد التقابل الاسم الياباني / الاسم الإنجليزي في جدول الإجراءات أدناه وجدول متغيّرات 5.1.

ما نريد إنجازه

1. جمع ملفّات CSV لليوم من المجلّد المشترك
2. تجميع المحتوى وكتابته في قالب تقرير Excel
3. حفظ التقرير في المجلّد المحدَّد
4. إشعار المعنيّين بالبريد
5. عند الفشل إشعار المسؤول وتسجيل السبب في السجلّ

flowchart TD
    Start(["تشغيل مجدوَل 06:30"]) --> Block[["On Block Error: معالجة التجميع"]]
    Block --> List["Get files in folder (جلب CSV اليوم)"]
    List --> Check{"هل توجد ملفّات مستهدَفة؟"}
    Check -- لا --> NoticeEmpty["تسجيل عدم وجود مستهدَف والإنهاء"]
    Check -- نعم --> Read["Read from CSV file (حلقة ملفّاً ملفّاً)"]
    Read --> Agg["تجميع القيم والإضافة إلى المتغيّرات"]
    Agg --> Excel["Launch Excel (فتح القالب)"]
    Excel --> Write["Write to Excel worksheet (كتابة نتيجة التجميع)"]
    Write --> Save["حفظ Excel وإغلاقه"]
    Save --> Mail["Send an email (إرسال التقرير إلى المسؤول)"]
    Mail --> Log["إلحاق نتيجة التنفيذ بملفّ السجلّ"]
    Log --> End(["إنهاء طبيعيّ"])
    Block -. وقوع خطأ .-> Handler["معالج الخطأ"]
    Handler --> CloseExcel["إغلاق Excel إن بقي مفتوحاً"]
    CloseExcel --> LogErr["تسجيل محتوى الخطأ في السجلّ"]
    LogErr --> Notify["بريد إشعار فشل إلى المسؤول"]
    Notify --> End2(["تسجيل إنهاء غير طبيعيّ"])

الإجراءات الرئيسة وأدوارها كالتالي. نورد أيضاً الاسم في واجهة المستخدم اليابانيّة (صيغة مرجع الإجراءات في الوثائق الرسميّة اليابانيّة¹⁰).

الأسماء اليابانيّة ليست تقابلاً واحداً لواحد تماماً؛ فمثلاً Send an email (V2) في Office 365 Outlook يتذبذب في الوثائق اليابانيّة الرسميّة بين «電子メールの送信 (V2)» و«メールを送信する (V2)».¹² إذا لم تجده في الواجهة، البحث بالاسم الإنجليزي أوثق.

5.1 تصميم المتغيّرات ── أمثلة الاسم والنوع والقيمة

المتغيّرات تُقاس بـ«هل يستطيع من يقرأ التدفّق لاحقاً تتبّع المعنى من التدفّق وحده». في هذا المثال، قرِّر على الأقلّ التالي من البداية. اقرأ القيم وفق بيئتك.

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

5.2 التقسيم إلى تدفّقات فرعيّة

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

Main (التدفّق الرئيسيّ)
  ├─ التهيئة: ضبط متغيّرات 5.1
  ├─ بدء كتلة [On Block Error]
  │    ├─ تنفيذ «جمع CSV»          ← الخرج: lstFiles
  │    ├─ إن كان المستهدَف 0 سجِّل «لا مستهدَف» وأنهِ
  │    ├─ تنفيذ «التجميع»              ← الإدخال: lstFiles / الخرج: numTotal, numProcessed
  │    ├─ تنفيذ «الكتابة إلى Excel»        ← الإدخال: numTotal, txtTemplatePath / الخرج: txtReportPath
  │    ├─ تنفيذ «الإشعار»              ← الإدخال: txtReportPath, numProcessed
  │    └─ تنفيذ «كتابة السجلّ»            ← الإدخال: نتيجة التنفيذ (نجاح)
  └─ [معالج الخطأ]
       ├─ تنفيذ «تنظيف Excel» (إغلاق مثيل بقي مفتوحاً)
       ├─ تنفيذ «كتابة السجلّ»            ← الإدخال: نتيجة التنفيذ (فشل + محتوى الخطأ)
       └─ تنفيذ «الإشعار»              ← الإدخال: إشعار فشل إلى المسؤول

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

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

6. تصميم معالجة الأخطاء

في Power Automate Desktop يوجد إجراء On Block Error يضبط معالجة أخطاء مشتركة على مستوى الكتلة. بدلاً من ضبط «السلوك عند الخطأ» لكلّ إجراء على حدة، يمكن تطبيق معالجة مشتركة على كلّ الإجراءات داخل الكتلة.¹

[On Block Error] كتلة معالجة التجميع
  ├─ List files in folder
  ├─ Read from CSV file (حلقة)
  ├─ Launch Excel / Write to Excel worksheet
  └─ Save Excel / Close Excel

[معالج الخطأ]
  ├─ الحصول على محتوى الخطأ (الاسم، موضع الحدوث، الإجراء المعنيّ، الرسالة التفصيليّة) كمتغيّرات عبر إجراء Get last error
  ├─ إغلاق مثيل Excel إن بقي مفتوحاً (لا تحذف التنظيف عند الفشل)
  ├─ التسجيل في السجلّ عبر Write text to file (Append)
  ├─ إشعار المسؤول عبر Send an email (V2)
  └─ اختيار «الاستئناف من نهاية الكتلة» أو «إيقاف تنفيذ التدفّق»

هنا نقاط ينبغي تثبيتها.

• معالجة خطأ الإجراء الفرديّ تتقدّم على معالجة خطأ الكتلة، لذا غيّر السلوك بإعداد فرديّ لإجراء معيّن فقط، واجمع الباقي في On Block Error.¹
• باستخدام «Retry action if an error occurs» يمكن إعادة المحاولة تلقائيّاً بعدد وفاصل محدَّدين للأخطاء المؤقّتة (تأخير الشبكة أو قفل الملفّ وغيرها). جعل كلّ الأخطاء هدفاً لإعادة المحاولة يهدر الوقت، فافصل ما ينبغي إعادة محاولته عمّا لا ينبغي (مثل عدم اتّساق البيانات).¹
• إذا أردت الرجوع إلى محتوى الخطأ السابق داخل المعالج، ضع إجراء Get last error صراحة. هذا إجراء يعيد متغيّراً بستّ خصائص: اسم الخطأ، والمكان، والإجراء المعنيّ، والتدفّق الفرعيّ الذي ينتمي إليه، والتفاصيل، والرسالة؛ وليس متغيّراً ضمنيّاً يُعدّ تلقائيّاً. بعد الجلب امسحه بخيار «Clear error» حتى لا يُعاد استخدام قيمة الخطأ خطأً لاحقاً.¹
• لا تكتفِ في السجلّ بـ«نجاح/فشل»، بل أبقِ عدد المعالَج، واسم الملفّ المستهدَف، ورسالة الخطأ. الدليل الوحيد لاحقاً على «لماذا توقّف» هو السجلّ.
• كمعالجة لاحقة للكتلة، اختر صراحة «الاستئناف من نهاية الكتلة» أو «إيقاف تنفيذ التدفّق». التوقّف ومثيل Excel ما زال مفتوحاً يترك العمليّة للمرّة التالية، لذا التنظيف (إغلاق المثيل) أهمّ عند الخطأ.¹³

إن كنت معتاداً على try/catch/finally في PowerShell، فقرب «كتلة» On Block Error من try، ومعالج الخطأ من catch، وسلسلة التنظيف من finally، فيسهل التصميم.

7. تثبيت أتمتة واجهة المستخدم

أكبر سبب لعدم استقرار تدفّق سطح المكتب هو في معظم الحالات «طريقة تحديد عنصر واجهة المستخدم (المُحدِّد - Selector)».

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

تشغيل أتمتة واجهة المستخدم أوّل مرّة ليس صعباً. استمرار العمل بلا انكسار بعد ستّة أشهر يتحدّد تقريباً بالكامل بطريقة بناء المُحدِّدات.

8. التعامل الآمن مع بيانات الاعتماد

أكثر ما تقع فيه الحوادث في أتمتة الأعمال هو التعامل مع بيانات الاعتماد (كلمات المرور، ومفاتيح API، وسلاسل الاتّصال وغيرها).

• تجنّب كتابة كلمة المرور أو معلومات الاتّصال كما هي في متغيّر إدخال للتدفّق. باستخدام إجراء Get credential يمكن جلب بيانات الاعتماد بأمان من «بيانات اعتماد Power Automate» التي تتّخذ Azure Key Vault أو CyberArk قاموس أسرار في الخلف، وتُعلَّم القيمة كسرّ فلا تظهر في سجلّ تنفيذ التدفّق.¹⁶¹⁷
• عند استخدام Azure Key Vault لتخزين الأسرار، يمكن جمع معلومات الاتّصال إلى Key Vault في موضع واحد على جانب Power Automate، فلا تتشتّت بيانات الاعتماد بين التدفّقات.¹⁷
• جهّز حساباً مخصّصاً للتنفيذ غير المراقَب بأضيق نطاق لازم، ولا تشركه مع حساب يستخدمه شخص يوميّاً. كلّما اتّسعت صلاحيات الحساب اتّسع أثر عطل التدفّق أو خطأ الإعداد.
• المضيّ في التحقّق وكلمة المرور مكتوبة نصّاً واضحاً في متغيّر إدخال «مؤقّتاً للتشغيل» يتركها غالباً كما هي في الإنتاج. اعتد على Get credential من مرحلة التحقّق فهو أأمن.

9. الحوكمة والتشغيل

عندما تكثر التدفّقات التي صنعها أفراد أو فرق، يلزم ضبط على مستوى المنظّمة.

• سياسة منع فقدان البيانات (DLP) تصنّف الموصلات التي يجوز للتدفّق أو التطبيق استخدامها إلى «مخصّص لبيانات الأعمال» و«غير مسموح لبيانات الأعمال» و«محظور»، وتمنع الجمع في التدفّق نفسه بين موصل بيانات أعمال وموصل غير مسموح لبيانات الأعمال. هذه أوّل حوكمة ينبغي تجهيزها كي لا تتسرّب بيانات المنظّمة إلى خدمة خارجيّة دون قصد.¹⁸
• يمكن تصنيف إجراءات تدفّق سطح المكتب وحظرها بالإطار نفسه لسياسة DLP، لكنّ ذلك غير مفعَّل افتراضيّاً. يلزم تشغيل «Show desktop flow actions in DLP policies» مرّة في إعدادات المستأجر بمركز إدارة Power Platform، ولا يمكن إرجاع هذا الإعداد لاحقاً. حتى بعد التفعيل لا يخضع للضبط إلا الوحدات والإجراءات المصنَّفة صراحة في السياسة، لذا «صنعنا سياسة DLP = تدفّق سطح المكتب كلّه تحت السيطرة» ليس صحيحاً بالضرورة.²
• اجمع أجهزة التنفيذ غير المراقَب في مجموعة أجهزة (machine group)، ووضّح أيّ تدفّق يعمل على أيّ جهاز.
• قرِّر أين تُرى سجلّات التنفيذ. لتدفّق سحابي فرديّ، سجّل الدخول إلى Power Automate ثم «تدفّقاتي» ← التدفّق المستهدَف ← «سجلّ التنفيذ» في صفحة التفاصيل؛ اختيار تنفيذ فاشل يُظهر عند أيّ إجراء سقط وتفاصيل الخطأ. من قائمة أعلى الصفحة نفسها يعرض «Analytics» معدّل النجاح والفشل وسجلّ التنفيذ لآخر 30 يوماً. لرؤية إخفاقات المستأجر أو البيئة كلّها بلا تسريب، Monitor (المراقبة) في مركز إدارة Power Platform هو الأشمل.¹⁹²⁰ تظهر أيضاً إخفاقات متسلسلة (لاحقة تُعدّ فاشلة لأنّ إجراء سابقاً فشل)، فالمبدأ في سجلّ التنفيذ هو النظر إلى «أوّل إجراء فشل».¹⁹
• اعرف حدود إشعار الفشل القياسيّ ثم أضف إشعاراً خاصّاً. يرسل Power Automate نوعين من البريد عند فشل تدفّق سحابي. الأوّل تنبيه فشل لكلّ تنفيذ، ويُرسل إلى المالك والمالكين المشاركين فقط عندما يُحكم أنّ السبب له طريقة إصلاح معروفة مثل انقطاع الاتّصال أو الاختناق (throttling). ويلزم أن يكون مفعَّلاً في إعدادات التدفّق، وبعد إرسال واحد يدخل التدفّق نفسه فترة تهدئة 28 يوماً. الثاني ملخّص أسبوعيّ يشمل أيضاً الإخفاقات العامّة التي لم يصدر لها تنبيه.¹⁹ أي أنّ «في كلّ مرّة، فوراً، إلى المسؤول» لا تُلبّى بالميزات القياسيّة وحدها. ادمج من معالج أخطاء الفصل 6 إشعاراً بالبريد أو Teams كجزء من التدفّق نفسه.
• للموارد داخل الشبكة الداخليّة التي لا يصل إليها السحاب مباشرة، مثل قواعد البيانات أو مشاركات الملفّات، استخدم بوابة البيانات المحليّة. لا تحتاج البوابة فتح منفذ استقبال من السحاب، بل تجسر البيانات بأمان باتّصال في اتجاه الإرسال فقط.²¹
• افصل البيئات بين التحقّق والإنتاج، وافصل تدفّقات سطح المكتب ومعلومات الاتّصال لكلّ بيئة، حتى لا يؤثّر تغيير أثناء التحقّق في تدفّق الإنتاج.

10. حدود Power Automate ومعيار التصعيد

Power Automate قويّ لكنّه ليس لكلّ شيء. في الحالات التالية انظر في التحويل إلى PowerShell أو تطبيق .NET.

عندما تشعر أنّ «ما صُنع بـ Power Automate كبر وتعقّد أكثر من اللازم»، غالباً ما تكون الصيانة أسهل إن فصلت المعالجة الجوهريّة إلى .NET أو PowerShell، وتركت Power Automate للمشغِّلات والإشعارات بدل مواصلة توسيع التدفّق بالقوّة. مثال عمليّ لأتمتة التحقيق في السجلّات وأرشفتها بـ PowerShell معروض في مقال منفصل: «تطبيقات PowerShell المتقدّمة ── أتمتة آمنة لتحقيق السجلّات وأرشفتها وإصدار التقارير عنها».

11. الخلاصة

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

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

هذا مقدار الفرق التصميميّ بين «تدفّق يعمل مؤقّتاً» و«تدفّق يمكن الاطمئنان إليه». وكلّما ارتبطت الأتمتة بأنظمة أعمال قائمة أو أصول Excel / VBA، زاد تأثير قرار التصميم الأوّل على تكلفة الصيانة لاحقاً.

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

• ما هو VBA: حدوده، آفاقه المستقبليّة، متى يجب استبداله، وأنماط الترحيل العمليّة
• تطبيقات PowerShell المتقدّمة ── أتمتة آمنة لتحقيق السجلّات وأرشفتها وإصدار التقارير عنها
• كيف تبني إخراج تقارير Excel - COM وOpen XML والقوالب

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

تتعامل شركة كومورا سوفت ذ.م.م. مع استشارات الأتمتة والتحديث التدريجيّ مع الإبقاء على أصول الأعمال القائمة من Excel / VBA / Windows، ومع مراجعة تصميم بنية الأتمتة بما في ذلك Power Automate.

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

روابط مرجعية

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

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

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

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

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

كيف نفرّق بين استخدام التدفّق السحابي وتدفّق سطح المكتب؟

التدفّق السحابي آليّة تربط الخدمات السحابيّة ببعضها عبر الموصلات، وهو مناسب لسير الموافقات والإشعارات وتكامل SaaS وتدفّقات الأعمال المرتبطة بـ Microsoft 365. أمّا تدفّق سطح المكتب فهو RPA يتعامل مباشرةً مع تطبيقات وشاشات Windows، وهو خيار واقعيّ عندما يلزم التعامل مع شاشة نظام أعمال قديم بلا API أو تطبيق Win32. عند تلقّي استشارة، يصبح المسار أوضح إذا بدأنا بالفصل أوّلاً بين «هل الأمر يتعلّق بربط خدمات سحابيّة ببعضها، أم بالتعامل مع شاشة؟».

أيّهما ينبغي استخدامه، Power Automate أم PowerShell؟

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

ما الرخصة اللازمة للتنفيذ غير المراقَب (unattended) في Power Automate؟

يحتاج التنفيذ غير المراقَب رخصة مختلفة عن التنفيذ المراقَب (attended)، وهي رخصة Power Automate Process التي تُربَط بسير العمل أو بالجهاز. أمّا إضافة التنفيذ غير المراقَب السابقة فأصبحت تُعامَل كرخصة قديمة (legacy) واستُبدلت برخصة Process. كما أنّ رخصة Process وحدها لا تحلّ محلّ رخصة المستخدم، إذ يتطلّب تسجيل الجهاز مستخدماً يملك رخصة Power Automate Premium. وعلاوةً على ذلك، في Windows 10/11 يفشل التنفيذ غير المراقَب إذا بقيت جلسة أيّ مستخدم في حالة قفل، لذا يلزم تسجيل خروج الجميع.

ما سبب عدم استقرار أتمتة واجهة المستخدم في تدفّق سطح المكتب؟

السبب الأكبر غالباً هو طريقة تحديد عناصر واجهة المستخدم (المُحدِّدات - Selectors). فإذا تضمّنت خصائص هشّة أمام التغيير مثل الفهارس المتسلسلة أو المعرِّفات الديناميكيّة، ينكسر سير العمل حتّى مع بقاء المظهر كما هو. من إجراءات المعالجة: تحويل الخصائص المتغيّرة القيمة من Equals إلى Contains أو تعبير نمطيّ (regex)، وضبط عدّة مُحدِّدات للرجوع الاحتياطيّ عند الفشل، واستخدام ميّزة Repair selector لتوليد مرشّحات إصلاح عند الانكسار. من المهمّ أيضاً عدم الاعتماد على Wait ثابت فقط، بل الجمع مع إجراءات الانتظار الشرطيّ. واستمرار عمل الفلو دون انكسار بعد ستّة أشهر يتحدّد تقريباً بالكامل بطريقة بناء المُحدِّدات.

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

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

غو كومورا

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

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