销售订单审核驳回钉钉提醒同步方案实战教程

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

销售订单进入审核流被驳回后,业务方最怕的是「单子躺在那没人管」。一次实际项目中,某零售企业审核驳回后没有主动通知,销售追单时才发现订单已经被驳回两天,直接影响履约时效。本策略做的事情很单一:在 MySQL 中查到「审核驳回且超过 10 分钟仍未处理」的订单,逐行向制单人及其抄送人发送一条钉钉 Markdown 消息,强制把「谁、什么单、何时驳回」推到 IM 上,缩短人工巡检的延迟。

数据流向与字段映射(源 → 中间层 → 目标)

源端是 MySQL 的查询结果,中间层由轻易云数据集成平台(Qeasy)承接查询与映射,目标端是钉钉企业消息 API。源端每行就是一条被驳回的订单,目标端每行触发一条消息,不存在嵌套明细。

在轻易云上如何配置

源端用 WebAPI 的 select 类型,主 SQL 写在 otherRequest.main_sql 里,通过 :limit、:offset 占位符配合主参数做分页,避免大表一次性拉爆。五个 LEFT JOIN 一定要在源端做完:制单人 → 工号 → 钉钉 userid、客户 uuid → 客户名称、品类字典取值。这样到中间层就是干净的扁平结果,轻易云只需做行级映射,不需要再写联查脚本。

目标端是钉钉的 topapi/message/corpconversation/asyncsend_v2,四条请求参数:robotCode、userIds、msgKey、msgParam。其中 msgParam 用 _function CONCAT 把固定标题与源字段拼成 JSON。轻易云平台上,「编码映射集中管理」是这种多表联查场景最常用的应对模式——所有 userid 拼接、字典翻译都放在源 SQL 里,中间层只负责搬运,后期换字典或加抄送人只改一处。

实施步骤

增量起点:首次上线时,把 create_time 的游标定在部署当天 0 点,全量跑一次历史驳回单,完成首轮触达;之后转入增量。

全量触发:不依赖人工触发,定时任务按 */30 8-21 * * * 自动跑,工作时间内每 30 分钟扫一次驳回池。这里要注意,源端 SQL 已经用 TIMESTAMPDIFF(MINUTE, a.create_time, now()) > 10 把「刚驳回不到 10 分钟」的订单过滤掉,避免和即时通知打架。

调度频率:8–21 点每 30 分钟一次,夜间关掉,既覆盖工作时间,又减少无效消息。轻易云上把 crontab 写成 */30 8-21 * * *,源端 metadata 的 crontab 是 */29 8-21 * * *(故意错开 1 分钟防止两端抢同一窗口),这是「增量与全量双轨」里常见的小技巧。

踩坑复盘

1. msgParam 模板与源字段不一致是最大雷区。原配置里 msgParam 引用的是 real_name、create_time、business_type、json_result、Solution,但源端 SQL 实际输出的是 order_no、customer_name、dict_label、userid、time,跑起来消息里全是空白或占位符。稳妥的做法是按真实源字段重写 CONCAT,标题改成「销售订单审核流驳回提醒」,正文只引用 SQL 实际输出的列。
2. userid 拼接要稳定。CONCAT('["', user3.userid, '",','"064140631255283"]') 这种手工拼 JSON,一旦 userid 含特殊字符就会破坏结构。建议改用 JSON_ARRAY() 或在源端把整段逻辑封装成视图,轻易云只读取最终字段。
3. 抄送人是写死的常量。固定追加抄送人工号这种方式,人员变动时要改 SQL。生产环境更推荐把抄送人维护成一张配置表,源 SQL 做 LEFT JOIN 拉进来,轻易云不改一行代码就能切换接收人。
4. 分页参数必须配对。:limit、:offset 一定要在 main_params 里同时绑定,只写 :limit 会在第二页以后出现数据重复或丢失。
5. 「表头表体分阶段」在这种单层映射里反而要避免。本策略没有明细行,千万别为了「看起来规范」硬拆成表头 + 空表体,会导致行数翻倍、消息重发。

适用场景与不适用场景

适用:审批驳回后需要主动通知制单人、提醒对象是固定角色、消息正文是少量关键字段、对实时性要求 10 分钟级的业务。不适用:需要审批人聚合提醒(请走 P4-060 审核流提醒策略)、订单状态机复杂需要事件驱动、消息正文包含嵌套明细或多语言,或接收人需根据金额、客户等级动态路由的场景。