BOM接口抛转失败钉钉通知策略实战教程：MySQL异常日志到钉钉消息的端到端配置

这个策略解决什么问题

在一次实际项目中，我们遇到某制造企业的BOM主数据从ERP向MES抛转时偶发失败。失败记录零散落在MySQL接口日志表里，业务员过了一天才发现物料编码未审核导致BOM没下发，产线早已停料。这个「BOM接口抛转失败-钉钉通知」策略要解决的就是：把异常从"被动翻日志"变成"主动告警"，按业务类型（41=同步、43=修改）分门别类，把责任人和解决方案一并推到钉钉群，让一线操作员在分钟内收到提示。

数据流向与字段映射

整体链路：MySQL接口日志表 → 轻易云查询组件 → 中间字段映射 → 钉钉群机器人Webhook。

源端（MySQL，WebAPI/POST查询）从接口请求日志表里筛出"未成功且10分钟内未恢复"或"业务类型为41/43"的记录。关键字段：

源字段	含义	中间层处理	目标字段（钉钉msgParam）
json_result	接口返回错误信息	截取首个Message与BillId拼接	`### 返回报错信息：{{json_result}}`
business_type	41/43业务码	case when转中文	`### 单据类型：{{business_type}}`
create_by / real_name	发起人/姓名	关联用户表取真实姓名	`### 操作者：{{real_name}}`
create_time	创建时间	原值透传	`### 操作时间：{{create_time}}`
userid	钉钉接收人	关联钉钉用户表，缺省回退到固定账号	`userIds`（数组）
Solution	解决方案文案	case when按业务类型给不同提示	`### 解决方案提示：{{Solution}}`

目标端调用钉钉 topapi/message/corpconversation/asyncsend_v2，msgKey 用 sampleMarkdown，msgParam 通过字符串拼接函数动态组装标题、正文与Markdown标记。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略拆成"源+目标"两张元数据卡。源端声明为select型WebAPI，主SQL语句放进otherRequest.main_sql，主参数main_params做分页占位（:limit :offset），这样翻页逻辑直接交给轻易云内置的分页器，工程师不用写循环。

目标端声明topapi/message/corpconversation/asyncsend_v2，把机器人编码、userIds、msgKey写死在请求体里，msgParam用轻易云的_function CONCAT(...)函数做模板拼装。轻易云客户里常见的应对模式是把这种"动态Markdown模板"集中放在目标端的函数式字段里维护，避免散落在多个策略里——后续业务术语变更只改一处。

idCheck在源端关闭（按业务主键去重，不按接口日志自增id），目标端开启，保证同一条失败不会重复推送。

实施步骤

阶段一：全量触发。首次上线时手动跑一次，把历史积压的失败记录一次性推完，让业务方确认告警文案格式。

阶段二：增量起点。把源端SQL里的create_time起点对齐到全量跑完的时间戳，后续只取新增或"10分钟仍未恢复"的记录。轻易云里通过metadata.number字段保存上次最大id实现增量游标，是典型的增量与全量双轨做法。

阶段三：调度频率。源端crontab设为*/29 8-21 * * *，目标端*/30 8-21 * * *，错峰29/30分钟避免源未查完目标就发空消息。工作时间段覆盖8点到21点，与现场排产时间对齐，非工作时间靠数据库自身的告警兜底，避免夜间刷屏。

阶段四：联调验收。故意在ERP侧造一条编码未审核的BOM，观察钉钉是否在两分钟内收到Markdown消息，操作者姓名是否正确。

踩坑复盘

占位符语法别混用。源SQL里:limit :offset是轻易云的动态语法，别图省事写?，不然分页器直接失效，第一页查全表把目标端冲垮。
userid空值要兜底。操作员若未绑定钉钉，user3.userid为NULL，CONCAT出来的JSON数组会带"null"字符串，钉钉接口返回非法参数。稳妥的做法是ifnull(user3.userid,'')，再叠加一个固定值班账号作为兜底接收人，确保消息不丢。
msgParam别用真换行。Markdown里换行要用 \n（两个空格加\n），直接换行在钉钉Markdown渲染里会被吃掉，看起来挤成一团。
idCheck别两端都关。源端idCheck关、目标端idCheck开，是为了让"重复跑同一条历史失败"时只发一次；如果两端都关，重跑会把历史失败重发一遍，群里会被刷屏。
时区与now()别双重计算。源端now()取的是数据库时区，目标端msgParam里不要再做时区转换，否则同一时间会出现两个时间戳，业务方对账时一头雾水。

适用场景与不适用场景

适用：ERP→MES/PLM的接口失败告警、单据抛转异常通知、需要按责任人精准投递的工作群消息。不适用：高频交易型通知（分钟级上百条会触发钉钉限流）、需要双向交互的场景（钉钉机器人群消息是单向推送，回复需另开会话）、含敏感凭证的明细传输（应走加密通道而非群机器人）。