引言
在 ServiceNow 运维中，Database View 的创建方式很容易依赖个人的 RDB 基础而产生属人化。另一方面，即使想通过 GUI 活用数据，也会遇到数据量过大导致导出上限、列表显示状态影响导出字段、附件分散在各记录中难以回收等问题。为此，我制作了一个用 GUI 支持原始数据导出和 Database View 定义的 PowerShell Utility。
本文基于公开仓库中的实现，整理其背景、实现方针、设计要点与运维效果。
- 工具名：PS1 SNOW Utilities
- 仓库：https://github.com/arimagml-collab/PS1SOWUtilities
- 实现形态：PowerShell 5.1 + WinForms（Windows 本地运行）
- 参考：README、主脚本、设计备忘（
docs/）
背景1：能导出，但运维负担重
ServiceNow 标准 UI 可以导出数据，但在实务中会持续累积以下问题。
- 想每次导出相同字段时，容易受到列表视图变更影响。
- 一旦要求“全字段 + 内部名称”的固定导出，流程说明成本会急剧上升。
- 大数据量下 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 是一个把 ServiceNow 运维高频作业集中到单一 GUI 的 PowerShell 工具。主要标签页如下。
1. Export 标签
- 选择目标表（或手工输入）
- 设置过滤条件（全量 /
sys_updated_on时间段） - 选择输出格式（CSV / JSON / Excel）
- 面向大数据量的 CSV 分割导出
- 指定输出目录并查看执行日志
其目标是把抽取步骤标准化，减少人员间操作差异。
2. Database View Editor 标签
- 输入 View 内部名与标签
- 设置基表与 Prefix
- 追加 JOIN（左右字段、Variable Prefix、LEFT JOIN）
- 重新获取字段候选并选择显示字段
- 创建 View 并显示结果链接
可在查看候选的同时组装定义，从而降低在 ServiceNow 多页面往返手输 WHERE/JOIN 的负担。
3. Attachment Harvester 标签
- 按更新时间段批量收集相关附件
- 文件重名时通过编号规避冲突
- 记录收集处理日志
用于将审计与调查中常见的附件回收流程化、可复现化。
4. Truncate 标签
- 面向开发用途的整表删除
- 确认码输入、目标信息显示、重试设置
这是高风险操作，不建议在生产环境使用，前提是验证环境中的数据重灌测试。
5. 设置标签
- 实例名
- 认证方式（用户ID+密码 / API Key）
- 语言设置（日语/英语）
- 主题设置（Dark / Light）
- 自定义域名连接设置（
instanceDomain）
输入值保存到 settings.json，敏感信息使用 Windows DPAPI（CurrentUser）加密保存。
设计要点
本实现最重视的是：降低运维阶段的维护负担。
-
将通信处理收敛到公共函数
以Invoke-SnowRequest为核心封装 GET/POST/PATCH/DELETE/附件获取，避免认证、异常处理、日志输出分散。 -
分离 UI 构建与显示控制
使用Build-*系列构建 UI，用Apply-*Language与Set-Theme负责显示切换。 -
稳定设置保存行为
通过Load-Settings/Save-Settings与Request-SaveSettings，抑制漏存与过度保存。 -
危险操作多重确认
Truncate 流程加入确认码与目标信息展示，降低误操作风险。 -
以日志可追溯为前提
通过 Logs 标签和ConvertTo-LogCompactJson，便于事后追踪执行结果。
实现上的取舍
在企业环境里，安装包分发和常驻应用导入门槛较高。因此本次优先采用仅靠文本分发也可运行的 PowerShell 脚本形态。
这一取舍在压低导入门槛的同时，缩短了现场开始使用的时间。
导入效果
导入后确认到以下四点效果。
- Export 流程在界面上固定化，降低了每次抽取请求的说明成本。
- Database View 创建时，在 ServiceNow UI 手工录入 WHERE 的场景减少。
- 可按时间条件批量回收附件，缩短调查时的重复作业。
- 通过设置保存，减少了实例名与认证信息的重复输入。
效果并不花哨，但能稳定压缩运维人员的重复作业时间，具有实务价值。
限制与注意事项
- 表清单依赖
sys_db_object，受 ACL 影响可能获取失败（可手工输入规避）。 - 某些环境下 WHERE/JOIN 自动保存受限，可能仍需在 ServiceNow 侧手工补全。
- 本工具与 ServiceNow 公司无关，不获得其批准、担保或支持。
总结
PS1 SNOW Utilities 的目标，是减少数据抽取与 Database View 定义中的实际堵点。
就我个人而言，我以前就知道 PowerShell 可以做 GUI，但并没有真正“自己动手做”的想法。借助生成式 AI，用接近 no-code 的指令式方式把工具做到可用形态，这段经历让我强烈感受到 AI 的进化速度。同时我也认为，传统 low-code / no-code 工具正在进入必须重定义优势、并承受同质化压力的阶段。