OneUptime ServiceNow 集成用 Workflow 自动创建与关闭 ServiceNow 事故工单【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本文以 OneUptime 官方文档中的 ServiceNow 集成为主线完整讲解如何利用 WorkflowIncident → On Create触发器 API 组件在 OneUptime 事故创建时自动向 ServiceNow 的 Table API 提交事故工单并可选地在事故解决时自动回写关闭状态。读完本文你将掌握凭据以 Base64 Basic-Auth 密钥存储的方式、API 组件的完整请求配置、correlation_id关联与sys_id回写的双向同步方案以及 401/403/400 等典型故障的排查路径并了解 OneUptime 工作流引擎在源码层面如何执行、校验和脱敏这一流程。集成架构与工作原理该集成是**出站outbound**模式由 OneUptime 主动调用 ServiceNow 的 Table API而不是由 ServiceNow 推送 Webhook 进来。整个链路为OneUptime Incident → On Create ──► API component (POST /api/now/table/incident) ──► ServiceNow incident也就是说OneUptime 侧只需要一条 Workflow包含两个组件Incident 触发器事件选择On Create—— 每当一个新的事故被创建即被触发API 组件—— 向https://your-instance.service-now.com/api/now/table/incident发起POST请求在 ServiceNow 中生成对应的 incident 记录。从源码结构看这两个组件都有对应的实现Incident 触发器基于通用 BaseModel 的 On Create/On Update 触发器OnCreateBaseModelAPI 组件则覆盖 Get/Post/Patch/Put/Delete 全部方法API 组件目录所有组件由 组件注册 API 统一初始化并按队列方式调度执行。前置条件开始之前需要准备一个 ServiceNow 实例地址形如https://your-instance.service-now.com一个拥有rest_api_explorer/itil角色或至少具备创建incident记录权限的 ServiceNow 用户。用该用户的凭据做 Basic-Auth 是最简单的起步方式生产环境建议使用 OAuth一个可以在其中创建 Workflow 的 OneUptime 项目。步骤 1 —— 将凭据存储为密钥ServiceNow 的 Table API 接受Basic-Auth认证。先将username:password做一次 Base64 编码printf %s integration_user:password | base64注意使用printf %s而不是echoecho会在字符串末尾追加换行符导致解码后的密码多出一个\n这是 401 报错的常见原因见文末排障章节。在 OneUptime 中进入Workflows → Global Variables → Create创建名为SERVICENOW_AUTH的变量粘贴 Base64 字符串并开启Is Secret开关。关于Is Secret开关源码中有明确的落点标记为 secret 的全局变量其明文内容会在写入 Workflow 运行日志时被替换为[REDACTED]避免凭据例如整个Authorization头的值泄漏到可检索的日志行中。相关实现见 密钥脱敏工具它按“长 secret 优先”的顺序构造替换表确保重叠的短密钥不会截断长密钥的替换。因此对于SERVICENOW_AUTH这类敏感变量开启 Is Secret 不只是界面约定而是有真实生效的日志脱敏逻辑支撑。步骤 2 —— 构建 Workflow打开Workflows → Create Workflow命名为Incidents → ServiceNow进入Builder。添加一个Incident触发器并设置为On Create将其重命名为Incident。添加一个与触发器相连的API块配置如下MethodPOSTURLhttps://your-instance.service-now.com/api/now/table/incidentHeadersAuthorization: Basic {{variable.SERVICENOW_AUTH}} Content-Type: application/json Accept: application/json{{variable.SERVICENOW_AUTH}}会在运行时被替换为全局变量的实际值即 Base64 后的username:password。Body{ short_description: OneUptime: {{Incident.title}}, description: {{Incident.description}}, urgency: 1, impact: 1, correlation_id: oneuptime-{{Incident._id}} }字段说明short_description是 ServiceNow incident 列表页的主展示字段这里统一加上OneUptime:前缀便于来源识别urgency与impact遵循 ServiceNow 的标准取值1高、2中、3低可按项目策略改为从事故严重级别映射correlation_id写入oneuptime-事故ID作为回指 OneUptime 事故的锚点是步骤 3 自动关闭工单的关键。保存、启用 Workflow然后创建一个测试事故。工作流日志中出现201 Created响应即表示成功响应体会返回新记录的sys_id和number例如INC0012345。源码视角API 组件实际做了什么理解response-body等返回值的来源有助于正确编写后续步骤的引用表达式。API Post 组件的执行逻辑见 ApiPost请求发出前ApiComponentUtils.sanitizeArgs 会先做参数规整若request-body或request-headers以 JSON 字符串形式传入Builder 的文本输入框常见会先解析为对象headers 若来自键值对网格而含有数字/布尔值会被统一压平为字符串避免非法的 header 值。URL 会经过SSRF 校验Utils.ts#L136-L169并且所有 API 组件统一设置doNotFollowRedirects: true防止请求被 302 重定向到云元数据等受保护地址——对指向service-now.com这类公网 API 的场景无感知但说明组件对目标 URL 是严格校验后再发请求的。响应无论 4xx/5xx 还是异常都会经由 getReturnValues 归一化为四个返回值response-status、response-body、response-headers和errorHTTP 错误如 401/403会被路由到组件的error出端口而不是 success 端口。这正是文档中{{CreateRecord.response-body.result.sys_id}}这类表达式的底层依据ServiceNow201响应体的result.sys_id位于response-body返回值之下可以直接被后续组件引用。同时如果 ServiceNow 返回 401/403组件会走 error 端口——你可以在 Builder 中把 error 端口接到通知组件Email/Slack 等见 组件总目录让认证失败也能被团队及时看到。步骤 3 —— 在 OneUptime 事故解决时同步关闭可选创建第二条Workflow使用Incident → On Update触发器并接一个Conditions块对应 IfElse 条件组件判断事故是否已进入 resolved 状态。要更新正确的 ServiceNow 记录必须拿到它的sys_id。两种方式任选其一推荐在步骤 2 的 Workflow 中读取{{CreateRecord.response-body.result.sys_id}}再用Update Incident组件基于 UpdateOneBaseModel 的模型更新组件把它写回 OneUptime 事故的某个 Label供第二条 Workflow 直接引用或者在关闭 Workflow 中先用GET /api/now/table/incident?sysparm_querycorrelation_idoneuptime-{{Incident._id}}按correlation_id查询记录从返回的result[0].sys_id取值——这就是correlation_id字段的价值所在。添加一个API块对应 ApiPatch 组件MethodPATCHURLhttps://your-instance.service-now.com/api/now/table/incident/sys_idBody{ state: 6, close_code: Resolved by monitoring, close_notes: Resolved in OneUptime }state取6是 ServiceNow 默认 ITIL 工作流中的 Resolved 状态close_code/close_notes可按实例的关闭原因清单调整。至此形成双向闭环OneUptime 事故创建 → ServiceNow 开单OneUptime 事故解决 → ServiceNow 工单关闭ITSM 与监控两侧保持一致。故障排查现象原因与处理401Basic-Auth 值编码错误。用printf %s重新编码username:password不要用echo它会追加换行符更新SERVICENOW_AUTH。403该用户没有写入incident表的权限为其添加itil角色。400字段名或字段值与实例的定制不符。到System Definition → Tables → incident中核对字段名。实例直接拒绝请求部分实例会限制 Table API 访问。确认 REST 已启用且 OneUptime 服务器出口 IP 未被 ACL 拦截。排查时可直接查看 Workflow 运行日志中 API 组件的response-status与response-body返回值见上文 getReturnValues 的归一化逻辑ServiceNow 的错误响应体会明确说明被拒绝的字段或权限项。关键文件与延伸阅读内容路径本文档德语版App/FeatureSet/Docs/Content/de/integrations/servicenow.md英文版同一文档App/FeatureSet/Docs/Content/en/integrations/servicenow.mdAPI Post 组件实现Common/Server/Types/Workflow/Components/API/Post.tsAPI 组件参数规整与 SSRF 校验Common/Server/Types/Workflow/Components/API/Utils.tsWorkflow 日志密钥脱敏App/FeatureSet/Workflow/Utils/SecretRedaction.tsWorkflow 组件注册与队列调度App/FeatureSet/Workflow/API/ComponentCode.ts集成概览文档App/FeatureSet/Docs/Content/de/integrations/index.mdJira 集成同一出站模式App/FeatureSet/Docs/Content/de/integrations/jira.mdServiceNow 集成本质上演示了 OneUptime 出站集成的通用范式——触发器 条件 API 组件——同一套模式同样适用于 Jira 等外部工单系统可直接迁移复用。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OneUptime ServiceNow 集成：用 Workflow 自动创建与关闭 ServiceNow 事故工单
OneUptime ServiceNow 集成用 Workflow 自动创建与关闭 ServiceNow 事故工单【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本文以 OneUptime 官方文档中的 ServiceNow 集成为主线完整讲解如何利用 WorkflowIncident → On Create触发器 API 组件在 OneUptime 事故创建时自动向 ServiceNow 的 Table API 提交事故工单并可选地在事故解决时自动回写关闭状态。读完本文你将掌握凭据以 Base64 Basic-Auth 密钥存储的方式、API 组件的完整请求配置、correlation_id关联与sys_id回写的双向同步方案以及 401/403/400 等典型故障的排查路径并了解 OneUptime 工作流引擎在源码层面如何执行、校验和脱敏这一流程。集成架构与工作原理该集成是**出站outbound**模式由 OneUptime 主动调用 ServiceNow 的 Table API而不是由 ServiceNow 推送 Webhook 进来。整个链路为OneUptime Incident → On Create ──► API component (POST /api/now/table/incident) ──► ServiceNow incident也就是说OneUptime 侧只需要一条 Workflow包含两个组件Incident 触发器事件选择On Create—— 每当一个新的事故被创建即被触发API 组件—— 向https://your-instance.service-now.com/api/now/table/incident发起POST请求在 ServiceNow 中生成对应的 incident 记录。从源码结构看这两个组件都有对应的实现Incident 触发器基于通用 BaseModel 的 On Create/On Update 触发器OnCreateBaseModelAPI 组件则覆盖 Get/Post/Patch/Put/Delete 全部方法API 组件目录所有组件由 组件注册 API 统一初始化并按队列方式调度执行。前置条件开始之前需要准备一个 ServiceNow 实例地址形如https://your-instance.service-now.com一个拥有rest_api_explorer/itil角色或至少具备创建incident记录权限的 ServiceNow 用户。用该用户的凭据做 Basic-Auth 是最简单的起步方式生产环境建议使用 OAuth一个可以在其中创建 Workflow 的 OneUptime 项目。步骤 1 —— 将凭据存储为密钥ServiceNow 的 Table API 接受Basic-Auth认证。先将username:password做一次 Base64 编码printf %s integration_user:password | base64注意使用printf %s而不是echoecho会在字符串末尾追加换行符导致解码后的密码多出一个\n这是 401 报错的常见原因见文末排障章节。在 OneUptime 中进入Workflows → Global Variables → Create创建名为SERVICENOW_AUTH的变量粘贴 Base64 字符串并开启Is Secret开关。关于Is Secret开关源码中有明确的落点标记为 secret 的全局变量其明文内容会在写入 Workflow 运行日志时被替换为[REDACTED]避免凭据例如整个Authorization头的值泄漏到可检索的日志行中。相关实现见 密钥脱敏工具它按“长 secret 优先”的顺序构造替换表确保重叠的短密钥不会截断长密钥的替换。因此对于SERVICENOW_AUTH这类敏感变量开启 Is Secret 不只是界面约定而是有真实生效的日志脱敏逻辑支撑。步骤 2 —— 构建 Workflow打开Workflows → Create Workflow命名为Incidents → ServiceNow进入Builder。添加一个Incident触发器并设置为On Create将其重命名为Incident。添加一个与触发器相连的API块配置如下MethodPOSTURLhttps://your-instance.service-now.com/api/now/table/incidentHeadersAuthorization: Basic {{variable.SERVICENOW_AUTH}} Content-Type: application/json Accept: application/json{{variable.SERVICENOW_AUTH}}会在运行时被替换为全局变量的实际值即 Base64 后的username:password。Body{ short_description: OneUptime: {{Incident.title}}, description: {{Incident.description}}, urgency: 1, impact: 1, correlation_id: oneuptime-{{Incident._id}} }字段说明short_description是 ServiceNow incident 列表页的主展示字段这里统一加上OneUptime:前缀便于来源识别urgency与impact遵循 ServiceNow 的标准取值1高、2中、3低可按项目策略改为从事故严重级别映射correlation_id写入oneuptime-事故ID作为回指 OneUptime 事故的锚点是步骤 3 自动关闭工单的关键。保存、启用 Workflow然后创建一个测试事故。工作流日志中出现201 Created响应即表示成功响应体会返回新记录的sys_id和number例如INC0012345。源码视角API 组件实际做了什么理解response-body等返回值的来源有助于正确编写后续步骤的引用表达式。API Post 组件的执行逻辑见 ApiPost请求发出前ApiComponentUtils.sanitizeArgs 会先做参数规整若request-body或request-headers以 JSON 字符串形式传入Builder 的文本输入框常见会先解析为对象headers 若来自键值对网格而含有数字/布尔值会被统一压平为字符串避免非法的 header 值。URL 会经过SSRF 校验Utils.ts#L136-L169并且所有 API 组件统一设置doNotFollowRedirects: true防止请求被 302 重定向到云元数据等受保护地址——对指向service-now.com这类公网 API 的场景无感知但说明组件对目标 URL 是严格校验后再发请求的。响应无论 4xx/5xx 还是异常都会经由 getReturnValues 归一化为四个返回值response-status、response-body、response-headers和errorHTTP 错误如 401/403会被路由到组件的error出端口而不是 success 端口。这正是文档中{{CreateRecord.response-body.result.sys_id}}这类表达式的底层依据ServiceNow201响应体的result.sys_id位于response-body返回值之下可以直接被后续组件引用。同时如果 ServiceNow 返回 401/403组件会走 error 端口——你可以在 Builder 中把 error 端口接到通知组件Email/Slack 等见 组件总目录让认证失败也能被团队及时看到。步骤 3 —— 在 OneUptime 事故解决时同步关闭可选创建第二条Workflow使用Incident → On Update触发器并接一个Conditions块对应 IfElse 条件组件判断事故是否已进入 resolved 状态。要更新正确的 ServiceNow 记录必须拿到它的sys_id。两种方式任选其一推荐在步骤 2 的 Workflow 中读取{{CreateRecord.response-body.result.sys_id}}再用Update Incident组件基于 UpdateOneBaseModel 的模型更新组件把它写回 OneUptime 事故的某个 Label供第二条 Workflow 直接引用或者在关闭 Workflow 中先用GET /api/now/table/incident?sysparm_querycorrelation_idoneuptime-{{Incident._id}}按correlation_id查询记录从返回的result[0].sys_id取值——这就是correlation_id字段的价值所在。添加一个API块对应 ApiPatch 组件MethodPATCHURLhttps://your-instance.service-now.com/api/now/table/incident/sys_idBody{ state: 6, close_code: Resolved by monitoring, close_notes: Resolved in OneUptime }state取6是 ServiceNow 默认 ITIL 工作流中的 Resolved 状态close_code/close_notes可按实例的关闭原因清单调整。至此形成双向闭环OneUptime 事故创建 → ServiceNow 开单OneUptime 事故解决 → ServiceNow 工单关闭ITSM 与监控两侧保持一致。故障排查现象原因与处理401Basic-Auth 值编码错误。用printf %s重新编码username:password不要用echo它会追加换行符更新SERVICENOW_AUTH。403该用户没有写入incident表的权限为其添加itil角色。400字段名或字段值与实例的定制不符。到System Definition → Tables → incident中核对字段名。实例直接拒绝请求部分实例会限制 Table API 访问。确认 REST 已启用且 OneUptime 服务器出口 IP 未被 ACL 拦截。排查时可直接查看 Workflow 运行日志中 API 组件的response-status与response-body返回值见上文 getReturnValues 的归一化逻辑ServiceNow 的错误响应体会明确说明被拒绝的字段或权限项。关键文件与延伸阅读内容路径本文档德语版App/FeatureSet/Docs/Content/de/integrations/servicenow.md英文版同一文档App/FeatureSet/Docs/Content/en/integrations/servicenow.mdAPI Post 组件实现Common/Server/Types/Workflow/Components/API/Post.tsAPI 组件参数规整与 SSRF 校验Common/Server/Types/Workflow/Components/API/Utils.tsWorkflow 日志密钥脱敏App/FeatureSet/Workflow/Utils/SecretRedaction.tsWorkflow 组件注册与队列调度App/FeatureSet/Workflow/API/ComponentCode.ts集成概览文档App/FeatureSet/Docs/Content/de/integrations/index.mdJira 集成同一出站模式App/FeatureSet/Docs/Content/de/integrations/jira.mdServiceNow 集成本质上演示了 OneUptime 出站集成的通用范式——触发器 条件 API 组件——同一套模式同样适用于 Jira 等外部工单系统可直接迁移复用。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考