这个策略解决什么问题(场景与价值)
销售订单进入审核流被驳回后,业务方最怕的是「单子躺在那没人管」。一次实际项目中,某零售企业审核驳回后没有主动通知,销售追单时才发现订单已经被驳回两天,直接影响履约时效。本策略做的事情很单一:在 MySQL 中查到「审核驳回且超过 10 分钟仍未处理」的订单,逐行向制单人及其抄送人发送一条钉钉 Markdown 消息,强制把「谁、什么单、何时驳回」推到 IM 上,缩短人工巡检的延迟。
数据流向与字段映射(源 → 中间层 → 目标)
源端是 MySQL 的查询结果,中间层由轻易云数据集成平台(Qeasy)承接查询与映射,目标端是钉钉企业消息 API。源端每行就是一条被驳回的订单,目标端每行触发一条消息,不存在嵌套明细。
| 源字段 | 来源 | 目标字段 | 映射类型 | 转换规则 |
|---|---|---|---|---|
| --- | 常量 | robotCode | CONSTANT | 钉钉机器人编码固定值 |
| userid | 源端 SQL CONCAT 生成 |
userIds | DIRECT | JSON 数组字符串,制单人 + 固定抄送人 |
| --- | 常量 | msgKey | CONSTANT | sampleMarkdown,Markdown 模板 |
| order_no | mbs_order.order_no | msgParam.text | DIRECT | 消息正文中的订单号 |
| customer_name | basic_customer_info | msgParam.text | DIRECT | 客户名称 |
| dict_label | sys_dict_data(品类字典) | msgParam.text | DIRECT | 订单品类展示名 |
| time | 源端 SQL now() |
msgParam.text | DIRECT | 消息时间戳 |
在轻易云上如何配置
源端用 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 分钟防止两端抢同一窗口),这是「增量与全量双轨」里常见的小技巧。
踩坑复盘
- msgParam 模板与源字段不一致是最大雷区 。原配置里 msgParam 引用的是
real_name、create_time、business_type、json_result、Solution,但源端 SQL 实际输出的是order_no、customer_name、dict_label、userid、time,跑起来消息里全是空白或占位符。稳妥的做法是按真实源字段重写 CONCAT,标题改成「销售订单审核流驳回提醒」,正文只引用 SQL 实际输出的列。 - userid 拼接要稳定 。
CONCAT('["', user3.userid, '",','"064140631255283"]')这种手工拼 JSON,一旦 userid 含特殊字符就会破坏结构。建议改用JSON_ARRAY()或在源端把整段逻辑封装成视图,轻易云只读取最终字段。 - 抄送人是写死的常量。固定追加抄送人工号这种方式,人员变动时要改 SQL。生产环境更推荐把抄送人维护成一张配置表,源 SQL 做 LEFT JOIN 拉进来,轻易云不改一行代码就能切换接收人。
- 分页参数必须配对 。
:limit、:offset一定要在main_params里同时绑定,只写:limit会在第二页以后出现数据重复或丢失。 - 「表头表体分阶段」在这种单层映射里反而要避免。本策略没有明细行,千万别为了「看起来规范」硬拆成表头 + 空表体,会导致行数翻倍、消息重发。
适用场景与不适用场景
适用:审批驳回后需要主动通知制单人、提醒对象是固定角色、消息正文是少量关键字段、对实时性要求 10 分钟级的业务。不适用:需要审批人聚合提醒(请走 P4-060 审核流提醒策略)、订单状态机复杂需要事件驱动、消息正文包含嵌套明细或多语言,或接收人需根据金额、客户等级动态路由的场景。