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