מבוא

ככל שתפעול ותחזוקת ServiceNow נמשכים, אופן יצירת Database View נוטה להפוך תלוי-אדם, משום שהוא נשען על ידע בסיסי ב-RDB. גם כאשר מנסים לנצל נתונים דרך ה-GUI, נפח נתונים גדול עלול לעבור את מגבלות הייצוא, עמודות נבחרות עלולות להשתנות לפי מצב תצוגת הרשימה, וקבצים מצורפים מפוזרים בין רשומות וקשה לאסוף אותם. כדי לפתור זאת בניתי כלי 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 תכופות ב-GUI אחד. מבנה הלשוניות הראשי הוא:

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
  • שיטת אימות (user ID + password / API key)
  • הגדרת שפה (יפנית/אנגלית)
  • הגדרת ערכת נושא (כהה / בהיר)
  • הגדרת דומיין מותאם (instanceDomain)

הקלט נשמר ב-settings.json, וערכים רגישים מוצפנים באמצעות Windows DPAPI (CurrentUser).

נקודות תכנון מרכזיות

במימוש הזה נתתי עדיפות לתכנון שמפחית עומס תחזוקה במהלך תפעול.

  1. ריכוז עיבוד התקשורת בפונקציות משותפות
    המבנה מבוסס על Invoke-SnowRequest, שעוטף GET/POST/PATCH/DELETE/איסוף קבצים כדי שאימות, טיפול בשגיאות ולוגים לא יתפזרו.

  2. הפרדה בין בניית UI לשליטה בתצוגה
    רכיבי 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 ב-UI של ServiceNow.
  3. איסוף קבצים מצורפים לפי תקופה התאפשר בצורה מרוכזת וקיצר עבודת חקירה חוזרת.
  4. שמירת ההגדרות צמצמה הקלדה חוזרת של שם Instance ופרטי התחברות.

ההשפעה אינה ראוותנית, אך יש כאן ערך מעשי ברור בצמצום שיטתי של זמן עבודה חוזר.

מגבלות והערות

  • רשימת הטבלאות מסתמכת על sys_db_object; בהתאם ל-ACL, שליפה עלולה להיכשל (הזנה ידנית היא מעקף).
  • בחלק מהסביבות קיימות מגבלות על שמירה אוטומטית של הגדרות WHERE/JOIN, ונדרש להשלים ידנית ב-ServiceNow.
  • הכלי עצמאי מ-ServiceNow, Inc. ואינו נתמך/מאושר/מובטח על ידה.

סיכום

PS1 SNOW Utilities נבנה כדי לצמצם חסמים מעשיים בחילוץ נתונים ובהגדרת Database View.

ברמה האישית ידעתי ש-PowerShell יכול לבנות GUI, אבל לא ציפיתי להוביל זאת בעצמי. בעזרת generative AI הצלחתי לעצב את הכלי בגישת הנחיות כמעט no-code. החוויה הזו הדגישה עד כמה AI מתקדם במהירות. במקביל, נראה שכלי low-code/no-code קלאסיים נכנסים לשלב שבו הם חייבים להגדיר מחדש את יתרונם מול לחץ הקומודיטיזציה.