分步式调入单审核结果回传:从金蝶云星空到MySQL的闭环同步实战

这个策略解决什么问题

在 MES/WMS 推单到 ERP 的场景里,「单据推过去了」只是上半句;ERP 审核是否通过、ERP 端生成的调入单号是多少,必须回写到 MES 中间表,推单流程才算真正闭环。本文要拆解的,就是分步式调入单提交审核结果回传这一段——它跑在金蝶云星空审核动作之后,把 is_success、message、ERP 单号 (Number) 三个关键字段写回 MySQL 的接口表。

数据流向与字段映射

整体流向是「金蝶云星空 → 轻易云 → MySQL」。轻易云本身在这里既是触发源,也是搬运工:它用一条空操作 WebAPI(effect=QUERY)作为轮询触发器,把 ERP 端的审核结果字段采集进来,再用一条SQL 执行 WebAPI(effect=EXECUTE)写回接口表。

字段对照看三处最容易踩坑:is_sucess 在源端拼写如此(素材原文如此,非笔误),回写时映射到 STATUS;SuccessEntitys.0.Number 是嵌套数组第一项的 ERP 单号,落到 erp_warehouse_num;sourceid 必须从上游策略带过来,否则 UPDATE 无法定位行。

在轻易云上如何配置

源端(触发器)配置要点:API 选「请求空操作」,effect 设为 QUERY,method 用 POST,请求体留空,响应模板预置 is_sucess / result_message / SuccessEntitys 三个字段并开启 autoFillResponse。这种「空操作」常被用作心跳触发——ERP 端审核动作结束后,由业务事件驱动写入某个状态位,轻易云按 */3 * * * * 高频轮询这个状态位,一旦有值就启动后续回写。

目标端(SQL 回写)配置要点:API 选 update,method 选 SQL。request 里只放一个 main_params 对象,字段值用 {{SuccessEntitys.0.Number}} 这种点路径语法;真正的主 SQL 放在 otherRequest.main_sql 里,采用命名参数占位符 :message、:is_success、:time、:Id、:Number、:sourceid,平台会自动把 main_params 中的同名键绑定过去。注意 UPDATE 条件 where t1.instruction_doc_num = :sourceid,:sourceid 来自上游链路,不要硬编码。

依赖与调度:把这条策略的 sequence 放到被依赖的下游,depends_on 指向上游推单策略;源端 crontab 用 */3 * * * *(三分钟级),目标端用 */2 * * * *(两分钟级),形成「快轮询触发、快轮询回写」的窄窗口。

实施步骤

1. 增量起点:上线初期,在 MySQL 接口表里给已有「待回传」记录打一个标志位(如 attribute14 为空),首轮轮询会一次捞出全部,后续按状态收敛。建议先在测试环境跑通 3 条样本,再切生产。
2. 空操作触发器上线:在轻易云里配置好源端「请求空操作」,先用日志面板验证 SuccessEntitys 能否稳定取到,这一步不通就什么都别往下做。
3. SQL 回写配置:把 main_sql 与 main_params 完整填好,强烈建议在 Navicat/DBeaver 里先用同样的参数手工跑一次,确认影响行数符合预期。
4. 全量触发:把目标端调度临时改成 */1 * * * *,让历史积压尽快收敛,看到 STATUS 与 erp_warehouse_num 都被正确填充后,再切回 */2 * * * *。
5. 调度频率收敛:稳态运行 24 小时后,观察 ERP 审核回调的延迟分布,把源端和目标端的轮询间隔调到一个既不浪费资源、又能在业务容忍窗口内回写的值。

踩坑复盘

• SuccessEntitys 为空时整条链路沉默:金蝶云星空审核失败时,该数组可能不存在,若不做空值兜底,SQL 端 {{SuccessEntitys.0.Number}} 会拿到 null 写进 erp_warehouse_num。稳妥做法是在源端加一条空值校验,失败时把 is_success 设为 'N'、把错误信息填到 message,让 UPDATE 仍能落库。
• 命名参数漏写导致全表更新:main_sql 里出现过占位符、但 main_params 没传同名键时,某些驱动会把参数绑定成 NULL,导致 UPDATE 命中大量行。复盘时一定要在测试库先看 EXPLAIN 与影响行数。
• sourceid 没传,UPDATE 退化成全表扫描:这是真实客户现场最容易翻车的地方——上游策略没把 MES 端的单据号透传到这条策略的上下文里。建议在轻易云里把 sourceid 显式声明为入参,并在源端策略日志里搜一下是否真的带过来了。
• 源端字段名拼写 is_sucess 不修正:素材原文如此,建议在映射层加一个 alias 把它规范成 is_success,别让这种拼写一直传到下游 SQL 命名参数里。
• 轮询频率过高打挂 MySQL:两分钟一次的 UPDATE 本身不重,但如果接口表没建索引(instruction_doc_num 上一定要有索引),累积下来 IO 也会很高。

适用场景与不适用场景

适用:ERP 审核结果需要回写到 MES/WMS 中间表,且业务允许分钟级延迟;调用方已经能拿到审核回调字段,只需要落地到自有库。 不适用:对回写实时性要求秒级;ERP 端没有稳定的审核事件可监听,只能靠定时全表比对;需要把回写结果再推送给下游多个异构系统——这种情况建议先回写 MySQL,再各自单独拉,而不是让本策略兼任广播。