企业微信推送策略实战:把集成方案异常点准时推送到群

这个策略解决什么问题(场景与价值)

某零售企业的供应链集成里同时跑着十几条同步策略:销售订单、采购入库、库存调拨……任意一条出错,业务侧最怕的不是报警本身,而是「没人知道」。客户现场运维同学白天盯监控屏,晚上靠值班同事扫日志,体验很差。我们用轻易云数据集成平台做了一个轻量策略:每天上午 9:30 自动拉取指定策略近 24 小时内「错误」「跳过调度」两类运行记录,清洗后通过企业微信机器人一次性推送给运维群。十几秒后,群里出现「昨日集成异常清单」,谁负责哪条一目了然。

数据流向与字段映射

整体走向是「轻易云内置查询接口 → 轻易云执行器 → 企业微信群机器人 WebHook」,完全在平台内闭环,不需要中间库。

关键字段对照(源 → 目标):

含义	源(StrategyErrorDetail)	目标(WeChatRobotDetail)	说明
方案名称	strategy_name	name	推送消息标题
单据编号	number	number	出错的单据号
租户名	lessee.name	lessee_name	区分多业务组织
异常时间	response_at	response_at	用于排序
异常描述	problem	problem	错误内容正文

源端通过 recentSeconds=86400 控制只看最近一天,status=3,6 只捞「错误」和「跳过调度」两类,过滤掉完成、等待等噪音。

在轻易云上如何配置

源端选「WebAPI / 查询」,API 选 StrategyErrorDetail,方法 POST;ids 字段填入需要监控的策略 ID 列表(逗号分隔),可一次圈定十几条;status 写成 3,6,recentSeconds 默认 86400。响应字段保持 _autoFillResponse 自动填充即可,无需手工建表。

目标端选「WebAPI / 执行」,API 选企业微信机器人接口 WeChatRobotDetail,方法 POST。access_token 用变量传入机器人 key(集中放在平台凭证里,不要散落在策略里);name、number、response_at、problem 都从源端用 {{变量}} 直接引用,完成「字段级映射」。

两个 WebAPI 都关闭 idCheck,因为这是无主键的批量子调用。

实施步骤

增量起点:上线当天先只配源端查询,人工跑一次,把结果导出 CSV 当作「首日基线」,确认 ID 列表没漏。
全量触发:首周把 recentSeconds 临时改成 604800(7 天),跑一次全量,确认 7 天内的错误都能正确汇总到群里,排查字段缺失。
调度频率:源端用 30 9 * * *(每天 9:30 跑一次),目标端紧跟其后 31 9 * * *,错开一分钟,避免瞬时并发把机器人限流。
回看机制:轻易云默认保留运行日志至少 30 天,运维群里没收到消息时,可以回查源端的执行记录确认是否真的没异常,而不是「机器人抽风」。

编码映射上,常见做法是把十几条策略的 ID 列表集中维护在一个「监控方案清单」表里,新增/下线策略时只改这一处,所有推送策略共享同一个清单。表头表体分阶段上,目前这一步只推错误摘要(表头),等运维熟悉后再考虑把每条错误的堆栈片段也带出去(表体)。

踩坑复盘

status 默认值是「错误」,容易漏掉跳过。源端字段说明里写了「不填默认为 3」,所以很多人只看到错误,但「跳过调度」往往更危险——它意味着上游根本没拉到数据,业务静默。一定要显式写成 3,6。
access_token 直接写在 value 里。早期我们确实把机器人 key 硬编码进策略,后来客户要求统一管控,改成平台凭证变量,部署时由运维注入,这样换机器人不用改策略。
ids 列表越写越长。三十条策略全堆在一个字段里,既难维护也容易写错。稳妥做法是把 ID 列表抽到一张「监控清单」表,策略里只引用这张表。
同一分钟并发被限流。源端 9:30 跑完,目标端如果也写 30 9 * * *,平台其实会按调度顺序排队,但在网络抖动时仍可能撞车。错开一分钟更稳妥。
recentSeconds 单位是秒。新人容易写成 24,结果只查了 24 秒内的异常,群里空荡荡。一定写 86400。

适用场景与不适用场景

适用:多策略并存、需要每日集中巡检的供应链/财务集成;运维群已经习惯企业微信协同;对延迟容忍度为「次日上午」。不适用:需要分钟级实时告警(应改用单策略失败即推送);目标群不是企业微信(需要换机器人协议);异常量极大、需要分类分派的场景(应接工单系统而非群消息)。