采购订单关闭终止：基于轻易云的 MySQL→钉钉 消息提醒同步实战

这个策略解决什么问题

在一次实际项目中,我们遇到这样的业务痛点:某制造企业的 MOM 系统中,采购订单被关闭、终止或删除后,采购员和采购组织负责人往往要等到对账或供应商反馈才发现异常,处理时机被严重滞后。

我们用轻易云数据集成平台(Qeasy)做了一件小事——把这三类事件从 MySQL 实时捞出来,推送到钉钉群里,5 分钟内相关人就能收到一条带完整上下文的 Markdown 通知。看似简单,但中间涉及增量同步、多表联查、Markdown 拼装和组织维度路由,任何一个环节没设计好,要么消息遗漏,要么消息错乱,要么把无关的负责人炸出来。

数据流向与字段映射

数据流向:MySQL(MOM 系统)→ 轻易云中间层 → 钉钉工作通知 API。

源端是 qyy_pur_message 消息表,扁平结构,每行对应一条待发通知。中间层需要联查 dingtalk_user(工号→钉钉 userid)、mt_po_header 与 mt_po_line(关闭/终止信息)、mt_po_line_attr(物料名称、规格型号、计划跟踪号)四张表。目标端是钉钉 topapi/message/corpconversation/asyncsend_v2 接口,每行独立触发一次消息推送。

关键字段对照:

在轻易云上如何配置

在轻易云平台里,这个策略被建模成一条「源集成流 + 目标集成流」的链路。

源端配置要点:API 类型选 WebAPI,effect 为 QUERY,把主 SQL 写入 otherRequest 的 main_sql,参数 :limit 与 :offset 绑定到 main_params;增量字段用 a.create_time >= '{{LAST_SYNC_TIME|datetime}}' 做游标过滤,系统会按调度节奏自动推进时间戳。

目标端配置要点:effect 设为 EXECUTE,请求方法 POST,接口地址写入 API 路径;msgParam 字段直接用 _function CONCAT 拼成 JSON,这是轻易云里很常见的一种「编码映射集中管理」做法——所有模板字段在一处维护,后续调整只动这一段。robotCode、msgKey 用常量,userIds 直接取 {{userid}}。

实施步骤

阶段一:增量起点初始化。第一次配置时,LAST_SYNC_TIME 建议先取一个业务上能接受回溯的时间点(例如部署当天零点),触发一次全量回灌,把历史未通知的消息补齐;之后调度即按 8 分钟节奏推进。

阶段二:全量触发。上线初期我们通常会安排一次「全量触发」——手动跑一次,核对消息接收人范围、文案格式、机器人是否被限流;确认无误后再开启定时。

阶段三:调度频率上线。源端 cron 配为 */8 * * * *,目标端 */10 * * * *,源稍快、目标稍慢,留出一定的处理窗口。轻易云平台天然支持「增量与全量双轨」:增量用于日常,全量按钮用于重跑。

阶段四:监控与对账。每天核对一次「源端新增消息数 vs 钉钉发送成功数」,偏差超过阈值就触发排查。

踩坑复盘

坑 1:把 now() 放在源端 SQL 里。第一次配置时,我们把通知时间写在源端 SQL 的 SELECT 里,结果消息堆积 8 分钟后推送时,所有消息都显示同一个早于实际的时间。稳妥的做法是 now() 放在目标端 _function CONCAT 里,每条消息取推送瞬间的时间。

坑 2:联查表连接顺序导致放大。mt_po_line_attr 有多条记录(不同 ATTR_NAME),如果不在 join 条件里写死 ATTR_NAME,会出现笛卡尔积,同一个订单行被发多条消息。后续我们统一要求:多属性联查必须每个属性独立 join,且 join 条件带 ATTR_NAME。

坑 3:userid 硬编码在 SQL 里。起初把组织负责人的钉钉 userid 写死在 CASE 表达式里,新人入职或调岗后收不到通知,排查成本极高。建议把这类「人」的映射关系外置到一张配置表,SQL 改成 join,变更只动配置表。

坑 4:CASE 分支漏写 ELSE。rk_status 出现数据库里没枚举到的值时,如果没有 else,SQL 会返回 NULL,钉钉端 JSON 里就出现 null 字样。规范上所有 CASE 必须带 else 兜底。

坑 5:Markdown 换行符写错。钉钉 Markdown 识别的是 \n(两个空格 + 换行),只写 \n 在钉钉端会糊成一段,这是我们现场踩过的一个小坑。

适用场景与不适用场景

适用:MySQL 等关系库中存在「事件消息表」,需要将状态变更近实时推送到 IM 或 OA;接收人范围随组织维度变化;消息体需要包含联查后的富信息。

不适用:接收人范围需要按角色动态计算且涉及复杂审批链的场景,本策略不做权限收敛;也不适合作为业务系统替代 IM 的消息总线,这里只做提醒与通知。