مقدمة

مع استمرار تشغيل وصيانة ServiceNow، تصبح طريقة إنشاء Database View معتمدة على الأفراد لأنها تتطلب معرفة أساسية بقواعد البيانات العلائقية. وحتى عند محاولة الاستفادة من البيانات عبر الواجهة الرسومية، تظهر مشكلات عملية مثل تجاوز حدود التصدير عند كِبر البيانات، وتغيّر الأعمدة المختارة بحسب حالة عرض القائمة، وتشتت المرفقات عبر السجلات وصعوبة جمعها. لذلك طوّرت أداة PowerShell بواجهة GUI تدعم تصدير البيانات الخام وتعريف Database View.

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

  • اسم الأداة: PS1 SNOW Utilities
  • المستودع: https://github.com/arimagml-collab/PS1SOWUtilities
  • التنفيذ: PowerShell 5.1 + WinForms (تشغيل محلي على Windows)
  • المراجع: README والسكربت الرئيسي ومذكرة التصميم (docs/)

الخلفية 1: التصدير ممكن لكن التشغيل مرهق

تدعم واجهة ServiceNow القياسية تصدير البيانات، لكن في التشغيل الفعلي تتكرر المشكلات التالية:

  1. الفرق تحتاج نفس ترتيب الأعمدة دائمًا، لكن تغييرات عرض القائمة تؤثر في المخرجات.
  2. عند الحاجة إلى تصدير ثابت بكل الأعمدة وأسمائها الداخلية ترتفع كلفة التوثيق والتسليم.
  3. مع كِبر البيانات يصبح التصدير عبر GUI ثقيلًا ويصعب ضبط إعادة التنفيذ.

نتيجةً لذلك يُستنزف وقت فريق الصيانة في شرح “كيف نُخرج البيانات” بدل “كيف نستخدمها”. لذلك غيّرت النهج إلى بنية تمكّن كل قسم من تشغيل تصدير موحّد بنفسه عبر API.

الخلفية 2: إنشاء Database View يكشف فجوات معرفة RDB

Database View مفيد، لكنه عالي العتبة لغير المهندسين أو لمن لديهم خبرة RDB محدودة.

  • التعامل مع sys_db_view وsys_db_view_table يتم في سياقات منفصلة ويتطلب تنقلًا كثيرًا.
  • من الصعب مراجعة أسماء الأعمدة الداخلية في مكان واحد.
  • في بيئات بلا صلاحية Admin قد يلزم جمع الأسماء الداخلية يدويًا من شاشات أخرى.
  • كتابة WHERE/JOIN يدويًا عُرضة للأخطاء الإملائية وأخطاء الإشارة.

لهذه الأسباب خلصت إلى أن المستخدمين يحتاجون دعم GUI يسمح ببناء التعريفات أثناء معاينة المرشحين.

ما الذي بنيته: PS1 SNOW Utilities

PS1 SNOW Utilities أداة PowerShell تجمع المهام التشغيلية المتكررة في ServiceNow داخل واجهة واحدة. البنية الرئيسية للتبويبات كالتالي:

1. تبويب Export

  • اختيار الجدول الهدف (أو إدخاله يدويًا)
  • تحديد شرط التصفية (كل السجلات / فترة sys_updated_on)
  • اختيار صيغة الإخراج (CSV / JSON / Excel)
  • تقسيم CSV عند السجلات الضخمة
  • اختيار مجلد الإخراج ومراجعة سجلات التنفيذ

الهدف التشغيلي هو توحيد خطوات الاستخراج وتقليل الفروقات بين المنفذين.

2. تبويب Database View Editor

  • إدخال الاسم الداخلي والعنوان
  • تحديد الجدول الأساسي والبادئة
  • إضافة JOIN (عمود يسار/يمين، بادئة متغير، خيار LEFT JOIN)
  • تحديث قائمة الأعمدة واختيار أعمدة العرض
  • إنشاء View وإظهار رابط النتيجة

هذا الأسلوب يقلل عبء إدخال WHERE وJOIN يدويًا مع التنقل المستمر داخل ServiceNow.

3. تبويب Attachment Harvester

  • جمع المرفقات المرتبطة دفعة واحدة حسب فترة التحديث
  • منع تعارض أسماء الملفات بإضافة أرقام تسلسلية
  • تسجيل خطوات الاسترجاع في السجل

يساعد ذلك على تنفيذ جمع مرفقات التدقيق والتحقيق بإجراءات قابلة لإعادة التنفيذ.

4. تبويب Truncate

  • حذف كامل جدول للاستخدام التطويري
  • إدخال رمز تأكيد وعرض معلومات الهدف وإعدادات إعادة المحاولة

لأنها عملية خطرة، لا يوصى بها في الإنتاج، وهي مخصصة لاختبارات إعادة تحميل البيانات في بيئات التحقق.

5. تبويب Settings

  • اسم الـ Instance
  • طريقة المصادقة (معرّف مستخدم + كلمة مرور / API key)
  • إعداد اللغة (اليابانية/الإنجليزية)
  • إعداد المظهر (داكن / فاتح)
  • إعداد الاتصال بنطاق مخصص (instanceDomain)

تُحفظ المدخلات في settings.json، وتُشفَّر القيم الحساسة باستخدام Windows DPAPI (CurrentUser).

نقاط التصميم الأساسية

في هذا التنفيذ ركزت على تصميم يقلل عبء الصيانة أثناء التشغيل.

  1. تجميع معالجة الاتصال في دوال مشتركة
    بُنيت حول Invoke-SnowRequest لتوحيد GET/POST/PATCH/DELETE وجلب المرفقات، ومنع تشتت المصادقة ومعالجة الاستثناءات والتسجيل.

  2. فصل بناء UI عن التحكم في العرض
    العناصر تُبنى عبر Build-*، بينما تبديل العرض يتم عبر Apply-*Language وSet-Theme.

  3. تثبيت آلية حفظ الإعدادات
    باستخدام Load-Settings وSave-Settings وRequest-SaveSettings لتقليل فقد الحفظ والحفظ المفرط.

  4. تأكيدات متعددة للعمليات الخطرة
    تضم عملية Truncate رموز تأكيد وعرض الهدف لخفض مخاطر التشغيل الخاطئ.

  5. تصميم يركز على تتبع السجلات
    عبر تبويب Logs وConvertTo-LogCompactJson يمكن تتبع نتائج التنفيذ لاحقًا.

مقايضات عملية في التنفيذ

في البيئات المؤسسية قد يكون توزيع المثبتات أو إدخال تطبيقات مقيمة صعبًا. لذلك فضّلت نموذج توزيع سكربت PowerShell القابل للتشغيل كنص مباشر.

هذه المقايضة خفّضت عوائق التبنّي وقلّصت الزمن حتى أول استخدام ميداني.

الأثر بعد الإدخال

تم تأكيد أربع نتائج رئيسية بعد الإدخال:

  1. ثبات خطوات التصدير على الشاشة وتقليل عبء الشرح لكل طلب استخراج.
  2. تقليل الإدخال اليدوي لبنود WHERE أثناء إنشاء Database View في واجهة ServiceNow.
  3. تنفيذ جمع المرفقات بالجملة عبر شروط الفترة وتقليل وقت الأعمال التحقيقية المتكررة.
  4. تخزين الإعدادات قلّل إعادة إدخال اسم الـ Instance وبيانات الاعتماد.

الأثر ليس استعراضيًا، لكنه قيمة عملية في تقليص زمن الأعمال المتكررة باستمرار.

القيود والتنبيهات

  • تعتمد قائمة الجداول على sys_db_object؛ وقد يفشل الجلب بحسب إعدادات ACL (الإدخال اليدوي حل بديل).
  • في بعض البيئات توجد قيود على الحفظ التلقائي لتعريفات WHERE/JOIN، ما يستلزم إكمالًا يدويًا داخل ServiceNow.
  • هذه الأداة مستقلة عن ServiceNow, Inc. ولا تتلقى اعتمادًا أو ضمانًا أو دعمًا رسميًا منها.

الخلاصة

طُوّرت PS1 SNOW Utilities لتخفيف الاختناقات العملية في استخراج البيانات وتعريف Database View.

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