引言

在本文涉及的现场，数据抽取与 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. 设置标签

  • 实例名
  • 认证方式（用户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 的进化速度。同时我也认为，传统低代码/无代码工具正进入必须重定义优势、并承受同质化压力的阶段。