前言

在本文涉及的現場中，資料擷取與 Database View 建立長期受到流程交接成本與權限差異影響，導致作業停滯。為此，我製作了以 GUI 支援原始資料匯出與 Database View 定義的 PowerShell Utility。

本文整理其背景、實作方針與導入成效。

背景1：可以匯出，但維運負擔沉重

ServiceNow 標準 UI 也能匯出資料，但在實務上常出現下列問題。

  1. 各部門所需格式不同（CSV/JSON/Excel）。
  2. 想固定欄位結構匯出，卻常受清單檢視變更影響。
  3. 若要求「全欄位＋內部名稱」的定型取得，流程說明成本會大幅上升。
  4. 有時還需補充說明或協調 CSV 匯出權限。

結果是維護端把時間耗在「怎麼取資料」，而不是「怎麼用資料」。因此我改變思路，準備了可透過 API 讓各部門自助輸出定型欄位的結構。

背景2：Database View 建立容易暴露 RDB 知識落差

Database View 很方便，但對非工程師或 RDB 經驗較少者門檻偏高。

  • sys_db_view 與 sys_db_view_table 的操作情境分離，畫面切換多。
  • 難以在同一畫面集中確認內部欄位名稱。
  • 在無 Admin 權限環境，常需到別環境調查內部名稱後再帶回。
  • 手打 WHERE/JOIN 定義，容易發生拼字或參照錯誤。

因此我判斷，需要可一邊看候選值一邊以 GUI 組裝的支援方式。

實作內容：PS1 SNOW Utilities

工具由 3 個分頁組成。

1. Export 分頁

  • 選擇目標資料表（或手動輸入）
  • 指定篩選（全量 / sys_updated_on 期間）
  • 選擇輸出格式（CSV / JSON / Excel）
  • 指定輸出資料夾並確認執行紀錄

目標是不中斷各部門資料利用，同時將擷取流程標準化。

2. Database View Editor 分頁

  • 輸入 View 內部名稱與標籤
  • 設定基底資料表與 Prefix
  • 新增 JOIN（左右欄位、Variable Prefix、LEFT JOIN）
  • 重新取得欄位候選並選擇顯示欄位
  • 建立 View 並顯示結果連結

目標是補上 ServiceNow 標準 UI 的操作斷裂，降低定義錯誤。

3. 設定分頁

  • Instance 名稱
  • 認證方式（使用者 ID+密碼 / API Key）
  • 語言設定

輸入值儲存於 settings.json，減少重複輸入。敏感值以 Windows DPAPI（CurrentUser）加密，只能在同一使用者同一裝置解密。

實作上的取捨

在企業環境中，安裝包發佈與常駐程式導入門檻偏高。因此此次優先採用最差情況下也能以文字複製貼上執行的 PowerShell 腳本發佈。

此取捨可在降低導入門檻的同時維持現場即效性。

導入成效

導入後最明顯的成效有三點。

  1. 維護詢問由「擷取步驟」轉向「資料應用諮詢」。
  2. Database View 建立時的遺漏與拼字錯誤減少。
  3. 部門間格式更一致，降低自動彙整前處理負擔。

尤其是維運部門用 Excel 做初步分析、整合團隊以 JSON 並行運作，實務價值很高。

限制與注意事項

  • 資料表清單依賴 sys_db_object，受 ACL 影響可能無法取得（可改手動輸入）。
  • 在部分環境，WHERE/JOIN 定義自動儲存受限，可能需在 ServiceNow 端手動補齊。
  • 本工具與 ServiceNow 公司無關，不受其核可、保固或支援。

總結

PS1 SNOW Utilities 的目的，是降低資料擷取與 Database View 定義中的實務卡點。

就我個人而言，雖然早就知道 PowerShell 能做 GUI，但此前沒有自行著手的想法。藉由生成式 AI 協助，我以接近無程式碼的指令方式完成這個工具，強烈體感到 AI 的演進速度。同時我也認為，傳統 low-code／no-code 工具正面臨必須重定義優勢、且難以避免同質化壓力的階段。