企微消息推送-内部策略实战教程:从集成平台告警到企微触达

这个策略解决什么问题

在某零售企业的供应链集成项目里,聚水潭与金蝶云星空之间跑着几十条同步策略。一旦某条策略在凌晨执行失败,运维人员往往要等到第二天上班才会发现,这时业务数据已经断流数小时。我们用轻易云数据集成平台(Qeasy)做了一个「企微消息推送-内部」策略,把前一天所有错误或被跳过的策略集中捞出来,通过企业内部企微机器人推到运维群里,实现问题当日清。

数据流向与字段映射

整个链路分三段:集成平台源接口 → 中间组装层 → 企微机器人目标接口。

阶段	关键字段	来源 / 目标	说明
源:StrategyErrorDetail	recentSeconds	请求参数	查询多久之前的记录,单位秒
源:StrategyErrorDetail	ids	请求参数	需要监控的方案 ID 列表,逗号分隔
源:StrategyErrorDetail	status	请求参数	状态过滤,常用 3(错误)与 6(跳过调度)
源:StrategyErrorDetail	strategy_name	响应	策略名称,自动回填
源:StrategyErrorDetail	strategy_id	响应	策略 ID,自动回填
中间层	number / response_at	模板变量	单据编号与响应时间,自动注入
目标:WeChatRobotDetail	access_token	请求参数	企微机器人调用凭证
目标:WeChatRobotDetail	name / lessee_name / number / response_at / problem	请求参数	渲染消息正文的关键变量

编码映射上,我们常见的做法是把「方案 ID 列表」集中放在一个常量表里维护,新增监控对象时只改一处,避免散落在多个策略中。

在轻易云上如何配置

源接口元数据:API 选择 StrategyErrorDetail,类型 WebAPI,方法 POST,效果 QUERY。请求体配置 recentSeconds、ids、status 三个字段,响应字段开启 autoFillResponse,自动承接 strategy_name 与 strategy_id。
目标接口元数据:API 选择 WeChatRobotDetail,类型 WebAPI,方法 POST,效果 EXECUTE。access_token 通过轻易云的凭证管理托管,不在策略里明文存放。
请求体组装:在目标侧把 strategy_name、lessee.name、number、response_at、problem 等变量绑定到消息卡片模板,问题描述 problem 用脚本函数从源响应里拼接。
idCheck:两侧都开启,避免重复推送。
构建模型:关闭即可,本策略不依赖源数据构建目标实体。

实施步骤

我们通常按三阶段推进。

增量起点:上线第一天先在 ids 里只放两条核心策略(比如销售出库单同步、物料同步),验证从告警到推送的全链路是否打通。
全量触发:观察 3–5 天后,把其余策略逐步纳入 ids 列表,采用「先加错误状态 3,再加跳过状态 6」的分阶段方式,确保不被大量历史跳过记录淹没。
调度频率:源侧策略配置 crontab 为 3 4 * * *,每日凌晨 4:03 拉取前一天的数据;目标侧策略配置为 0 9 * * *,上午 9:00 整点推送,留出处理窗口。如果客户需要更早感知,可以把推送调整到 8 点。

踩坑复盘

方案 ID 列表漂移:客户新增策略后忘记同步到 ids,导致新策略静默失败。稳妥的做法是把 ids 维护成一个轻量映射文件,由单一负责人每周复核。
access_token 泄露:把 token 直接写在策略 value 里是典型错误。应该走轻易云的凭证托管,定时刷新,杜绝明文出现在配置快照中。
重复推送:idCheck 没启用时,同一告警会刷屏。我们曾见过一个群一早上收到 40 多条重复消息,体验很差。
状态值混用:status 不填默认是 3,如果只想看错误却忘了写,会把「等待」与「错误」混淆。建议显式写明 3,6,不要依赖默认值。
跳过调度 6 被忽略:很多人只监控错误,其实某些场景下上游无数据导致跳过,长期不看会形成暗坑。把 6 也纳入过滤,可以提前发现数据断流。

适用场景与不适用场景

适用:多策略并行、需要运维集中感知失败与跳过的场景;团队已使用企微机器人作为统一告警入口。不适用:对实时性要求极高(分钟级)的告警,以及没有企微机器人或不具备群发权限的环境,此时应改用短信或电话网关。