أتمتة الترحيل إلى الأنظمة الأساسيّة باستخدام Power Automate for desktop ── استبدال الإدخال اليدويّ من Excel والورق بأتمتة واجهة المستخدم

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

تعديل النظام يمثّل حلّاً جذريّاً، لكنّ الإدخال اليدويّ يستمرّ في حالات ليست نادرة، لأسباب مثل عدم وجود المورِّد بعد الآن، أو عدم وجود الشيفرة المصدريّة، أو أنّ تكلفة التعديل لا تستحقّ العناء. الأداة الواقعيّة لسدّ هذه الفجوة هي أتمتة واجهة المستخدم عبر Power Automate for desktop (PAD). بما أنّها تعيد إنتاج إدخال لوحة المفاتيح وحركات الفأرة التي يقوم بها الإنسان بالضبط، يمكنها الأتمتة دون المساس بنظام وجهة الترحيل. وفي Windows 11 توجد ميزة سهولة تجربتها دون الحاجة لتثبيت إضافيّ.

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

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

• أتمتة واجهة المستخدم هي الملاذ الأخير. ابحث أوّلاً عمّا إذا كانت وجهة الترحيل تملك منفذ استيراد CSV، أو إدخالاً مباشراً في قاعدة البيانات، أو API، أو تكامل ملفّات. إن وُجد أيّ منها، فهو أكثر استقراراً بالتأكيد.
• PAD مضمَّن افتراضيّاً في Windows 11، ويمكن تثبيته مجّاناً على Windows 10 أيضاً. باستخدام المسجِّل وأكثر من 400 إجراء، يمكن بناء سير ترحيل يقرأ Excel ويدخله في الشاشة بلا كود.¹²
• إنشاء سير العمل وتشغيله يدويّاً (تنفيذ مراقَب) فقط لا يتطلّب تكلفة إضافيّة، سواء بحساب العمل/المدرسة أو بحساب Microsoft. في المقابل، يتطلّب التشغيل التلقائيّ من التدفّق السحابي، والتنفيذ المجدوَل، ومشاركة سير العمل، رخصة Power Automate Premium.³⁴
• يتطلّب التنفيذ غير المراقَب (unattended) كالدفعات الليليّة، إضافةً إلى ذلك، تسجيل الجهاز ورخصة Power Automate Process. وهناك شروط مسبقة خاصّة من الناحية التقنيّة أيضاً، مثل «تسجيل خروج جميع المستخدمين».⁵⁶
• مفتاح التشغيل المستقرّ ثلاث نقاط: طريقة بناء المُحدِّدات، وانتظار العناصر، ومعالجة الاستثناءات لكلّ حالة على حدة. سير العمل الذي يصفّ Wait ثابتاً سينكسر يوماً ما حتماً.⁷⁸⁹
• لتعرف عند الفشل «إلى أين وصل الإدخال»، أدرِج منذ البداية تصميماً يعطي ملفّ Excel المصدر عمود حالة وعمود رقم تسجيل، ويكتب الحالة بعد كلّ حالة. بهذا لا يحدث إدخال مزدوج حتّى عند إعادة التنفيذ.
• بما أنّ مصير الانكسار عند تغيّر الشاشة لا يزول، فإنّ الأعمال ذات العدد الكبير، أو التي لا يمكن إيقافها، أو التي يتحدَّث فيها التطبيق المستهدَف كثيراً، تدخل ضمن نطاق تطوير تكامل البيانات أو تعديل النظام الأساسي. نرتّب الخطّ الفاصل في الفصل 8.

2. ما مشكلة أعمال الترحيل؟

الترحيل من Excel أو الورق إلى النظام الأساسي يحمل مشكلة أكبر من «استهلاك الوقت في عمل بسيط». الأمور المشتركة التي نسمعها في الاستشارات هي هذه الثلاثة:

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

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

إذا كان مصدر الترحيل ورقاً أو فاكساً، فإنّ خطوة «القراءة» ضروريّة قبل ذلك. تناولنا التعرّف الضوئيّ (OCR) على طلبات الفاكس في مقال آخر نُشر في الوقت نفسه بعنوان «قراءة طلبات الفاكس عبر AI Builder ومعالجتها بواسطة Power Automate»، لذا نمضي في هذا المقال على افتراض أنّ مصدر الترحيل «بيانات جاهزة كملفّ Excel وما شابه».

3. خيارات وسائل الأتمتة ── أتمتة واجهة المستخدم هي الملاذ الأخير

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

خيار آخر هو اتّجاه «إلغاء» الترحيل نفسه، أي تعديل النظام الأساسي أو إعادة بنائه. رتّبنا القرارات المتعلّقة بإضافة ميّزة استيراد إلى تطبيق VB6، أو إعادة بنائه بتحويله إلى الويب بدءاً من مدخل الطلبات، في «نقل تطبيق VB6 إلى .NET ── دليل عمليّ للاستقصاء المسبق والتوافق والانتقال المرحليّ» و«الحكم على ضرورة نقل تطبيق Windows إلى الويب ── معايير القرار وأنماط الانتقال الواقعيّة». بما أنّ التعديل يتطلّب تكلفة تطوير، فمن الواقعيّ أيضاً ترتيب البدء بالأتمتة عبر PAD أوّلاً لكسب الوقت، ثمّ الاستثمار في التعديل عندما يزداد حجم العمل ويظهر الحدّ الأقصى.

4. أساسيّات Power Automate for desktop

حاجز التبنّي منخفض

PAD مضمَّن افتراضيّاً في Windows 11. يمكن العثور على التطبيق بالبحث عن «Power Automate» في قائمة ابدأ، ويُنزَّل تلقائيّاً عند أوّل تشغيل ويصبح جاهزاً للاستخدام.² وله حقّ استخدام في Windows 10 وWindows Server 2016 أيضاً، ويمكن تثبيته مجّاناً من مركز التنزيل.² توجد طريقتان للتثبيت: نسخة Microsoft Store ونسخة مثبِّت MSI، وإذا كنتَ تستشرف التكامل السحابي (تسجيل الجهاز) الموضَّح لاحقاً، اختر نسخة MSI التي تتيح تثبيت تطبيق وقت تشغيل الجهاز معها.¹⁰

بناء الهيكل عبر المسجِّل

يمتلك PAD مسجِّلاً يسجِّل العمليّات ويحوِّلها إلى سلسلة إجراءات. يسجِّل عمليّات الفأرة ولوحة المفاتيح بعلاقتها بعناصر واجهة المستخدم، لذا فهو عمليّ بما يكفي لبناء هيكل سير الترحيل. ما يفيد أعمال الترحيل هنا هو إمكانيّة اختيار طريقة تسجيل من نوعين: UIA (UI Automation) وMSAA (Microsoft Active Accessibility). طريقة UIA هي الطريقة الموصى بها للتطبيقات الأحدث نسبيّاً مثل WPF وWinForms، وطريقة MSAA مخصّصة للتطبيقات القديمة التي لا يمكن التقاط عناصرها عبر UIA مثل VB6 وWin32 الكلاسيكيّ. عندما يصعب التقاط العناصر في شاشة نظام أساسي قديم، فإنّ التبديل إلى وضع تسجيل MSAA قد يحلّ المشكلة.¹¹

لكنّ المسجِّل مخصّص للهيكل فقط. لا يمكنه تسجيل التفرّعات الشرطيّة أو الحلقات، لذا يُفترَض التحرير في المصمِّم (designer) بعد التسجيل للانتهاء.¹¹

عناصر واجهة المستخدم والمُحدِّدات

يحفظ PAD الأزرار وصناديق النصّ الموجودة على الشاشة كـ«عناصر واجهة مستخدم». وجوهرها هو مُحدِّد يحدِّد العنصر بمزيج من التسلسل الهرميّ للنوافذ والخصائص. يتحدَّد عمر سير الترحيل تقريباً بالكامل بطريقة بناء هذا المُحدِّد. فإذا تضمّن فهارس متسلسلة أو معرِّفات تتغيّر ديناميكيّاً، قد يصبح من المستحيل التقاطه فجأة يوماً ما حتّى مع بقاء الشاشة كما هي في المظهر. تحويل الخصائص المتغيّرة القيمة من Equals إلى Contains أو تعبير نمطيّ، وضبط مُحدِّدات احتياطيّة للعمليّات المهمّة للرجوع الاحتياطيّ، وتوليد مرشّحات إصلاح عبر ميّزة Repair selector عند الانكسار - هذه الأساسيّات كتبناها كما هي في الدليل الشامل.⁷

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

البنية الأساسيّة للترحيل: القراءة من Excel والكتابة إلى الشاشة

الشكل الأساسيّ لسير الترحيل هو «القراءة عبر إجراء Excel ← الكتابة حالة بحالة عبر التعامل مع واجهة المستخدم داخل حلقة». افتح الملفّ بـ Launch Excel، واقرأ النطاق بـ Read from Excel worksheet فتصبح متغيّر جدول بيانات (data table). إذا أضفتَ خيار «استخدام الصفّ الأوّل كأسماء أعمدة»، يمكن في الحلقة اللاحقة الرجوع إلى القيمة باسم العمود مثل CurrentItem['رمز العميل']، ما يجعلها أكثر مقاومةً لإعادة ترتيب الأعمدة.¹³ استخدم Write to Excel worksheet لكتابة النتيجة مرّة أخرى. وإذا أردتَ الإضافة في نهاية الصفوف، يمكن البحث عن صفّ فارغ عبر Get first free row on column.¹³

5. النطاق المجّانيّ للاستخدام والحدّ الفاصل مع الرخصة

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

الإنشاء والتنفيذ اليدويّ بلا تكلفة إضافيّة بأيّ حساب.³⁴ في حالة حساب Microsoft، يُحفَظ سير العمل في OneDrive، وفي حالة حساب العمل/المدرسة، يُحفَظ في Dataverse بالبيئة الافتراضيّة. إذا كان الاستخدام في شركة، فالأساس أن تبدأ بحساب العمل مراعاةً للإدارة لاحقاً.⁴

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

1. تسجيل الجهاز: تسجيل الحاسوب الذي سيُنفَّذ عليه في سحابة Power Automate. يتمّ التسجيل بتسجيل الدخول عبر تطبيق وقت تشغيل الجهاز المُضمَّن في نسخة MSI. ملاحظة: لا تدعم إصدارات Windows 10/11 Home هذا الاتّصال المباشر.¹⁰
2. اتّصال تدفّق سطح المكتب: إنشاء اتّصال (بيانات اعتماد حساب Windows) يتيح للتدفّق السحابي تسجيل الدخول إلى ذلك الجهاز.¹⁴
3. الرخصة: يجب أن يملك المستخدم الذي ينشئ الاتّصال رخصةً تناسب شكل التنفيذ.¹⁴ إذا كان تنفيذاً مراقَباً (attended) يعمل على حاسوب مسجَّل الدخول عليه من شخص، يلزم Power Automate Premium (رخصة مستخدم تتضمّن حقّ attended RPA).¹⁰⁶
4. يحتاج التنفيذ غير المراقَب (unattended) إضافةً إلى ذلك تخصيص رخصة Power Automate Process للجهاز. رخصة Process رخصة تُمنَح للجهاز (أو لسير العمل) لا للمستخدم، وتمنح فتحة تنفيذ غير مراقَب واحدة (بوت غير مراقَب) لكلّ جهاز. نقطة يجب الانتباه إليها: يُفترَض مسبقاً أن يكون الجهاز الذي تُخصَّص له رخصة Process مسجَّلاً بواسطة مستخدم يملك رخصة Premium. بعبارة أخرى، لا يمكن التكوين بشراء Process وحدها دون وجود مستخدم Premium.⁵⁶

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

6. تصميم للتشغيل المستقرّ

«انتظار العنصر» بدل Wait ثابت

في النظام الأساسي القديم، يتذبذب زمن استجابة البحث أو التسجيل بشدّة تبعاً للحمل. سير العمل المضبوط بـ Wait ثابت مثل «انتظر 3 ثوانٍ» سينكسر حتماً في اليوم الذي يبطئ فيه النظام. الأساس هو استخدام إجراء Wait for window content لجعل الانتظار «حتّى ظهور (أو اختفاء) عنصر واجهة مستخدم أو نصّ محدَّد».⁸ يمكن أيضاً ضبط مهلة زمنيّة عند الحصول على النافذة (Get window)، مع الاختيار بين «الفشل بعد ثوانٍ محدَّدة إن لم توجد» أو «الانتظار حتّى الظهور».⁸ طريقة الانتظار «حتّى ظهور رسالة اكتمال التسجيل ثمّ الانتقال إلى الصفّ التالي» مهمّة بشكل خاصّ في سير الترحيل. فإذا بدأ الإدخال التالي دون انتظار، تتغيّر الشاشة قبل انتهاء تسجيل الصفّ السابق، فتختلط البيانات.

بناء معالجة الاستثناءات «لكلّ حالة على حدة»

الأسلوب المعتمَد في معالجة استثناءات سير الترحيل هو إحاطة حالة واحدة داخل الحلقة بـ On Block Error، لا سير العمل بأكمله. عند وقوع خطأ، يُسجَّل محتوى فشل ذلك الصفّ، وتُعاد الشاشة إلى حالتها الأوّليّة (إغلاق شاشة الإدخال والعودة إلى القائمة مثلاً)، وينتقل إلى الصفّ التالي. بهذا، حتّى لو كان رمز منتج واحد فقط خاطئاً من بين 100 حالة، ينتهي إدخال 99 حالة، ويبقى فقط الحالة الفاشلة الواحدة بين يدي الإنسان. يمكن أيضاً استخدام إعداد إعادة المحاولة على مستوى الإجراء بالتزامن للأخطاء المؤقّتة (كتأخّر الاستجابة).⁹ نترك التفاصيل الدقيقة لمعالجة الأخطاء (استخراج محتوى الخطأ عبر Get last error، وتصميم التنظيف) للدليل الشامل، ولمقال آخر نُشر في الوقت نفسه بعنوان «معالجة الأخطاء وتصميم إعادة المحاولة في Power Automate».

جعل «مدى الإدخال» معروفاً حتّى عند الفشل

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

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

يصبح عمود الحالة هذا سجلّ تنفيذ بحدّ ذاته. يمكن معرفة «هل انتهى ترحيل الأمس بالكامل؟» بفتح Excel فقط دون الحاجة لمشاهدة سجلّ تنفيذ سير العمل. شكل سهل الشرح للميدان.

فخّ بيئة التنفيذ غير المراقَب

استشارات كثيرة جدّاً عن سير عمل كان يعمل في التنفيذ المراقَب لكنّه توقّف بمجرّد جعله غير مراقَب. السبب غالباً يكمن في اختلاف البيئة.

• افتراضات الجلسة: في التنفيذ غير المراقَب، ينشئ Power Automate جلسة سطح مكتب بعيد (RDP) جديدة على الجهاز المستهدَف، ويسجِّل الخروج بعد التنفيذ. أثناء التنفيذ، تبقى شاشة الجهاز المستهدَف مقفلة. الافتراض المسبَق هو أنّ جميع مستخدمي الجهاز يجب أن يكونوا قد سجّلوا الخروج، وفي Windows 10/11، يفشل التنفيذ إذا بقيت جلسة أيّ شخص (حتّى ولو مقفلة). أمّا في Windows Server، فيحدث الخطأ إذا بقيت جلسة مقفلة لنفس مستخدم الاتّصال. إذا كانت العادة بعد أعمال الصيانة هي مغادرة المكان بـ«القفل» أو «قطع الاتّصال»، سيتوقّف سير العمل الليليّ. تسجيل الخروج دائماً هي كلمة السرّ.⁵
• الصلاحيّات: يجب أن يستطيع المستخدم المستخدَم في الاتّصال إنشاء جلسة RDP على ذلك الجهاز (عادةً بالانتماء إلى مجموعة Remote Desktop Users). كما أنّ التنفيذ غير المراقَب لا يدعم العمليّات التي تتضمّن الترقية إلى صلاحيّات المسؤول.⁵
• دقّة الشاشة: قد تختلف دقّة جلسة RDP الافتراضيّة عن الشاشة التي بُني عليها سير العمل. عندما تنخفض الدقّة، يمكن أن يختفي عنصر واجهة مستخدم كان ظاهراً وقت الإنشاء خارج حدود الشاشة فيفشل بـ«لم يُعثَر على العنصر»، أو أن تنقر عمليّة تعتمد على الإحداثيّات مكاناً آخر.⁵ كإجراء معالجة، يمكن تثبيت «دقّة الشاشة عند التنفيذ غير المراقَب» في خصائص سير العمل على نفس القيمة وقت الإنشاء.¹⁵ كما أنّ اختلاف تحجيم DPI سبب فشل من النوع نفسه، لذا الأسلم توحيده على 100% وقت الإنشاء والتنفيذ.¹⁶

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

7. مثال عمليّ لتصميم سير الترحيل

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

flowchart TD
    Start([البدء: تشغيل يدويّ أو من التدفّق السحابي]) --> ReadX[قراءة قائمة الطلبات من Excel، مع اعتبار الصفّ الأوّل أسماء أعمدة]
    ReadX --> Filter{هل توجد صفوف بحالة «غير معالَج»؟}
    Filter -- لا --> Report[تجميع نتيجة المعالجة وتسجيلها في السجلّ والإشعار] --> End([الانتهاء])
    Filter -- نعم --> Launch[تشغيل النظام الأساسي وتسجيل الدخول<br/>تأكيد ظهور شاشة القائمة بانتظار العنصر]
    Launch --> Loop[حلقة على الصفوف غير المعالَجة حالة بحالة<br/>إحاطة داخل الحلقة بمعالجة الأخطاء على مستوى الكتلة]
    Loop --> Mark[تحديث عمود الحالة إلى «قيد المعالجة»]
    Mark --> Entry[فتح شاشة إدخال الطلب وإدخال البنود<br/>انتظار محتوى النافذة عند كلّ انتقال شاشة]
    Entry --> Confirm[زرّ التسجيل ← انتظار رسالة الاكتمال<br/>الحصول على رقم التسجيل الممنوح من الشاشة]
    Confirm --> WriteBack[تحديث عمود الحالة إلى «مكتمل» وكتابة رقم التسجيل]
    WriteBack --> Loop
    Loop -. حدوث خطأ في حالة واحدة .-> Handler[تسجيل محتوى الخطأ في الصفّ<br/>الفشل قبل التسجيل «خطأ» / الفشل بعد التسجيل يبقى «قيد المعالجة»<br/>إعادة الشاشة إلى القائمة والانتقال إلى الصفّ التالي]
    Handler --> Loop
    Loop -- معالجة جميع الحالات --> Close[تسجيل الخروج من النظام الأساسي وإغلاقه] --> Report

نضيف نقاط التصميم التالية.

• تحقّق من قيم الإدخال قبل التعامل مع واجهة المستخدم. عدد أرقام رمز المنتج، وعدم وجود أحرف في حقل رقميّ، وغياب حقل إلزاميّ. تحقّق من جانب سير العمل مباشرةً بعد قراءة Excel، واجعل الصفّ غير الصحيح «خطأ» قبل المساس بالنظام الأساسي. صدّ الخطأ مسبقاً أكثر استقراراً بأضعاف من التعامل مع مربّع حوار خطأ النظام الأساسي عبر واجهة المستخدم.
• الحالة التي يجوز فيها اعتبار الصفّ «خطأ» هي فقط الفشل قبل الضغط على زرّ التسجيل. إذا استُبدلت حالة عمود الحالة بـ«خطأ» بشكل موحَّد في معالجة الأخطاء، فإنّ الصفّ الذي فشل بعد نجاح عمليّة زرّ التسجيل (أثناء انتظار رسالة الاكتمال أو أثناء كتابة النتيجة) يصبح هو أيضاً «خطأ»، ما قد يؤدّي إلى قيام الموظّف بإعادة تنفيذ ذلك الصفّ فيسبِّب تسجيلاً مزدوجاً في النظام الأساسي. اجعل الممارسة أن يبقى عمود الحالة «قيد المعالجة» للفشل الواقع بعد عمليّة التسجيل، وألّا تكون الصفوف المنتهية بحالة «قيد المعالجة» هدفاً لإعادة التنفيذ، بل يتحقّق شخص من وجود التسجيل في النظام الأساسي أوّلاً ثمّ يعيدها إلى «مكتمل» أو «غير معالَج». محور هذا التصميم ليس إزالة الغموض، بل إحالة الحالة الغامضة إلى تحقّق بشريّ كما هي.
• ضع في الحسبان مربّعات حوار الخطأ في الشاشة. رغم كلّ شيء، تحدث أخطاء وقت الإدخال (نقص المخزون، خطأ ائتمان العميل، وغيرها). التقط مربّعات الحوار المتوقَّعة بفرع شرطيّ من نوع «هل تحتوي النافذة على…» وسجِّلها في محتوى خطأ الصفّ، واترك غير المتوقَّعة لـ On Block Error.⁹
• احتفظ بمعيار تقديريّ للعدد والوقت. ليس نادراً أن تستغرق أتمتة واجهة المستخدم عشرات الثواني لكلّ حالة. إذا كانت 100 حالة تستغرق ساعة، يتّسع ذلك جيّداً ضمن التنفيذ غير المراقَب الليليّ، لكن إذا كانت هناك آلاف الحالات يوميّاً فتلك إشارة لإعادة النظر في وسيلة أتمتة واجهة المستخدم نفسها (الفصل التالي).
• أنجِز تطبيع المصدر مسبقاً. تناولنا فخاخ CSV/Excel مثل اختلاف ترميز الأحرف وصيغة التاريخ، واختلاط الأحرف العريضة والضيّقة، في «دليل عمليّ لمعالجة ملفّات CSV ── منع تشويه الترميز وضياع الأصفار وتلف التواريخ».

8. إلى أيّ حدّ ننجز الأمر عبر PAD

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

كمعيار حدسيّ للقرار، ننظر إلى «هل يستمرّ العمل إذا بقي هذا الفلو منكسراً لأسبوع وعُدنا إلى الإدخال اليدويّ؟». إذا استمرّ، فقيمة أتمتته عبر PAD كافية. وإذا لم يستمرّ، فذلك الترحيل لم يعد متطلّب «أتمتة»، بل متطلّب «تكامل نظام»، وهذه مرحلة النظر في إضافة ميّزة استيراد، أو تكامل قاعدة بيانات، أو رقمنة الطلب والتوريد نفسه (EDI أو نقل طلبات الفاكس إلى الويب).

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

9. الخلاصة

يمكن أتمتة الترحيل إلى نظام أساسي لا يملك API ولا استيراد CSV «دون المساس بالنظام» عبر أتمتة واجهة المستخدم في PAD. يمكن البدء باستخدامه افتراضيّاً في Windows 11، ولا تكلفة إضافيّة إذا اكتُفي بالإنشاء والتشغيل اليدويّ. مجرّد تحرير الموظّف من ساعة ترحيل يوميّة، وزوال تحقيق أخطاء الترحيل وتصحيحها، يكفي وحده لاسترداد جهد التبنّي.

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

نتلقّى في شركتنا استشارات متّصلة تمتدّ من مراجعة تصميم أتمتة الترحيل عبر PAD، إلى ما بعدها من تطوير إضافة ميّزة استيراد وتكامل بين الأنظمة بالتعاقد، ونقل التطبيقات القديمة. تواصلوا معنا بلا تردّد حتّى من مرحلة «هل هذا ممكن مع نظامنا الأساسي أيضاً؟».

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

• أتمتة الأعمال باستخدام Power Automate ── الفصل بين التدفّق السحابي وتدفّق سطح المكتب وتصميم معالجة الأخطاء
• نقل تطبيق VB6 إلى .NET ── دليل عمليّ للاستقصاء المسبق والتوافق والانتقال المرحليّ
• الحكم على ضرورة نقل تطبيق Windows إلى الويب ── معايير القرار وأنماط الانتقال الواقعيّة
• معالجة الأخطاء وتصميم إعادة المحاولة في Power Automate
• دليل عمليّ لمعالجة ملفّات CSV ── منع تشويه الترميز وضياع الأصفار وتلف التواريخ

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

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

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

المراجع

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

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

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

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

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

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

هل يمكن استخدام Power Automate for desktop مجّاناً؟

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

ما اللازم لتشغيل سير الترحيل ليلاً أو في الصباح الباكر دون وجود أحد؟

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

سمعنا أنّ أتمتة واجهة المستخدم عرضة للانكسار، فهل هي عمليّة فعلاً؟

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

إذا فشل سير الترحيل في المنتصف، ألن نفقد معرفة إلى أين وصل الإدخال؟

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

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

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

غو كومورا

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

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