أتمتة الأعمال باستخدام 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). إذا أُجِّل تصميم الرخص، قد يعمل السير في بيئة التحقّق ولا يعمل في الإنتاج.³⁴

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

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

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

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

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

• التدفّق السحابي آليّة تربط الخدمات السحابيّة ببعضها عبر الموصلات. يُقسَّم حسب نوع المشغِّل إلى تدفّق آليّ (عند وقوع حدث)، وتدفّق مجدوَل (تنفيذ دوريّ)، وتدفّق فوريّ (تشغيل يدويّ).
• تدفّق سطح المكتب هو RPA (أتمتة العمليّات الروبوتيّة) يتعامل مباشرةً مع تطبيقات وشاشات 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. فهم الرخص

تنقسم رخص Power Automate بشكل رئيسيّ إلى رخص بحسب المستخدم، ورخص بحسب سير العمل (العمليّة - process).³

ما يعقّد الأمر هنا هو أنّ مفهوم الرخصة يتحدّد بـ«كيفيّة التنفيذ» لا بـ«من أنشأه». يعمل التدفّق الآليّ والتدفّق المجدوَل ضمن سياق رخصة مالك سير العمل، بينما يعمل التدفّق الفوريّ الذي يُشغَّل بزرّ ضمن سياق رخصة المستخدم الذي استدعاه. إذا كان التصميم مبنيّاً على افتراض التنفيذ غير المراقَب، فإنّ عدم التحقّق من متطلّبات الرخصة في مرحلة التحقّق يؤدّي إلى التعثّر عشيّة الانتقال إلى الإنتاج. وتجدر الإشارة إلى أنّ «إضافة التنفيذ غير المراقَب (Unattended RPA add-on)» السابقة تُعامَل الآن كرخصة قديمة (legacy) واستُبدلت برخصة Power Automate Process. رُفعت إضافة التنفيذ غير المراقَب القائمة إلى معاملة معادِلة لرخصة Process، لكن عند التخصيص الجديد تُستخدَم رخصة Process.³⁸⁴

ما يجب الانتباه إليه هو أنّ رخصة Process/Hosted Process وحدها لا تحلّ محلّ رخصة المستخدم. فتخصيص رخصة Process لجهاز (اللازم للتنفيذ غير المراقَب) يفترض مسبقاً أن يكون ذلك الجهاز مسجَّلاً بواسطة مستخدم يملك رخصة Power Automate Premium. كذلك، عند استدعاء تدفّق سطح مكتب مراقَب أو غير مراقَب من تدفّق سحابي، يجب أن يملك مستخدم الاتّصال المستخدَم في التنفيذ رخصة Premium (أو رخصة أخرى تتضمّن حقّ تدفّق سطح المكتب). إغفال رخصة المستخدم اللازمة للتشغيل بمجرّد تأمين سعة Process يؤدّي إلى التعثّر في مرحلة اختبار الوظائف.³

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

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

ما نريد فعله

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

flowchart TD
    Start([بدء مجدوَل 06:30]) --> Block[[معالجة الأخطاء على مستوى الكتلة: معالجة التجميع]]
    Block --> List[الحصول على قائمة ملفّات CSV الخاصّة باليوم]
    List --> Check{هل توجد ملفّات مستهدَفة؟}
    Check -- لا --> NoticeEmpty[تسجيل عدم وجود ملفّات مستهدَفة والإنهاء]
    Check -- نعم --> Read[حلقة: القراءة من كلّ ملفّ CSV]
    Read --> Agg[تجميع القيم وإضافتها إلى متغيّر]
    Agg --> Excel[تشغيل Excel وفتح القالب]
    Excel --> Write[كتابة نتيجة التجميع في ورقة عمل Excel]
    Write --> Save[حفظ Excel وإغلاقه]
    Save --> Mail[إرسال التقرير بالبريد الإلكترونيّ إلى المسؤول]
    Mail --> Log[إضافة نتيجة التنفيذ إلى ملفّ السجلّ]
    Log --> End([انتهاء طبيعيّ])
    Block -. حدوث خطأ .-> Handler[معالج الأخطاء]
    Handler --> CloseExcel[إغلاق Excel إن بقي مفتوحاً]
    CloseExcel --> LogErr[تسجيل محتوى الخطأ في السجلّ]
    LogErr --> Notify[بريد إشعار فشل إلى المسؤول]
    Notify --> End2([تسجيل كانتهاء غير طبيعيّ])

الإجراءات الرئيسيّة وأدوارها كالتالي.

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

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

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

[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. تثبيت أتمتة واجهة المستخدم

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

• افتراضيّاً، يسجِّل مُلتقِط عناصر واجهة المستخدم عنصر الشاشة كـمُحدِّد (مزيج من الخصائص). فإذا تضمّن خصائص هشّة أمام تحديث التطبيق أو تغيّر المحتوى المعروض (كالفهارس المتسلسلة أو المعرِّفات الديناميكيّة)، ينكسر سير العمل حتّى مع بقاء المظهر كما هو.¹²
• تغيير الخصائص المتغيّرة القيمة من Equals إلى Contains أو تعبير نمطيّ، وتحويل القيم المعتمِدة على نتيجة الإجراء السابق إلى متغيّرات، يجعل المُحدِّد أكثر ديناميكيّة وأقلّ عرضة للانكسار.¹²
• ضبط عدّة مُحدِّدات يتيح الرجوع الاحتياطيّ التلقائيّ إلى المُحدِّد التالي عند فشل الأوّل. إعداد مُحدِّد احتياطيّ للعمليّات المهمّة يرفع الاستقرار.¹²
• عند انكسار المُحدِّد، يمكن توليد مرشّحات إصلاح تلقائيّاً عبر ميّزة Repair selector. يستحقّ التجربة أوّلاً قبل إعادة البناء يدويّاً من الصفر.¹²
• هناك فارق زمنيّ في انتقال الشاشات وبدء التطبيقات. لا تعتمد على Wait ثابت فقط، بل اجمع إجراءات الانتظار الشرطيّ مثل «انتظار النافذة» و«الانتظار حتّى العثور على عنصر واجهة المستخدم»، واضبط أيضاً إعادة المحاولة التلقائيّة عند عدم العثور على عنصر واجهة المستخدم.¹³
• بالنسبة للأهداف التي يستحيل تثبيت أتمتتها (كالشاشات المُفتَرَضة (virtualized) أو الشاشات التي يتغيّر تخطيطها كثيراً)، لا تتمسّك بالتعامل مع واجهة المستخدم، بل تحقّق أوّلاً من وجود طريقة تكامل أكثر استقراراً كـ 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» مرّةً واحدة في إعدادات المستأجر (tenant) في مركز إدارة Power Platform، وهذا الإعداد لا يمكن التراجع عنه لاحقاً. وحتّى بعد التفعيل، فإنّ الوحدات والإجراءات المصنَّفة صراحةً في السياسة فقط هي التي تصبح خاضعة للتحكّم، لذا انتبه إلى أنّ «إنشاء سياسة DLP» لا يعني بالضرورة «خضوع تدفّق سطح المكتب بأكمله للضبط».²
• أدِر أجهزة التنفيذ غير المراقَب مجمَّعةً كـمجموعات أجهزة، ووضِّح أيّ سير عمل يُنفَّذ على أيّ جهاز.
• يمكن الاطّلاع على سجلّ التنفيذ من شاشة إدارة Power Automate وسجلّ التنفيذ. إذا ضُمِّن تنبيه الفشل (إشعار Teams أو بريد إلكتروني) ضمن معالجة سير العمل نفسه، يمكن ملاحظة الخلل دون حاجة لأن يذهب أحد للتحقّق يدويّاً.
• إذا أردتَ التعامل من التدفّق السحابي مع موارد محليّة (on-premises) لا يمكن الوصول إليها مباشرةً من السحابة، مثل قواعد البيانات أو مشاركات الملفّات داخل الشبكة الداخليّة، استخدم بوّابة البيانات المحليّة (on-premises data gateway). لا تحتاج البوّابة إلى فتح منفذ استقبال من جانب السحابة، بل تنقل البيانات بأمان عبر اتّصال بالاتّجاه الصادر فقط.¹⁷
• فصل البيئات بين التحقّق والإنتاج، وفصل تدفّق سطح المكتب ومعلومات الاتّصال بحسب كلّ بيئة، يمنع تأثير التغييرات أثناء التحقّق على سير عمل الإنتاج.

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 وأسلوب القوالب

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

تتعامل شركة Komura Soft LLC مع استشارات الأتمتة والتحديث التدريجيّ مع الحفاظ على أصول الأعمال القائمة من 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 ثابت فقط، بل الجمع مع إجراءات الانتظار الشرطيّ. واستمرار عمل الفلو دون انكسار بعد ستّة أشهر يتحدّد تقريباً بالكامل بطريقة بناء المُحدِّدات.

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

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

غو كومورا

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

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