采购退料单提交审核结果回传:基于轻易云的实战同步方案

这个策略解决什么问题

某制造业客户的 MES 流程里,采购退料单由车间发起,在 MES 端提交审核后,审批结果(通过/驳回/消息)需要回写到 MySQL 的接口表中,供后续 ERP 与车间协同使用。问题在于:审核流跑在 MES 平台里,MES 并不直接更新这张接口表;一旦回传延迟或丢失,车间看到的状态就和 ERP 不一致,3 个月后两边数字对不齐才被发现。这个策略就是用轻易云数据集成平台承接"审核结果回传"这一段闭环。

数据流向与字段映射

整条链路是单向的"查询—回写":源端是轻易云集成平台内部节点(空操作查询占位,触发审核结果采集),目标端是 MySQL 接口表 wms_po_result_iface。两段都拆成独立的策略编排,中间通过单据号贯通。

关键字段对照:

在轻易云上如何配置

源端策略(轻易云 → 采集审核结果):API 选"请求空操作",effect = QUERY,method = POST。响应字段显式声明 is_sucess、result_message、SuccessEntitys,其余请求体留空。autoFillResponse 设为 true,使得在没有外部请求参数时也能正常返回结构。

目标端策略(轻易云 → MySQL):API 选 update,effect = EXECUTE,method = SQL。otherRequest 里写 main_sql,使用命名参数绑定:

update ty_mes.wms_po_result_iface
set message = :message,
    STATUS = :is_success,
    attribute14 = :time,
    attribute15 = :Id
where instruction_doc_num = :sourceid and return_order in (1,2,3)

main_params 作为对象参数传入,字段顺序与命名参数一一对应。

集中管理的两点经验:一是把 is_sucess → STATUS 的语义映射放在轻易云的字段映射脚本里集中维护,不要散落在 SQL;二是 instruction_doc_num 的取值规则统一由上游策略提供,目标策略只做匹配,不做语义推断。

实施步骤

我们通常按"增量起点 → 全量触发 → 调度频率"三段上线。

增量起点:先在源端确认 MES 审核结果的数据落点(通常是 MES 的接口视图或中间表),用单据最后修改时间作为增量起点,首次只回传最近 24 小时的数据,验证链路。

全量触发:核对通过后,切换到全量扫描,跑一次历史数据回溯,把积压的审核结果补齐。这一步建议放在业务低峰期。

调度频率:源端 crontab 设 */3 * * * *,目标端 */2 * * * *,两者不完全对齐是有意为之——源端 3 分钟一采,目标端 2 分钟一写,留出 1 分钟的处理窗口,避免源端还没采完目标端就空跑。表头与表体分阶段上线是轻易云客户常见的应对模式:先做表头状态回写,稳定后再补表体行项目。

踩坑复盘

翻车点 1:状态字段语义不一致。源端返回的是字符串 Y/N,目标端 STATUS 字段历史上存的是 1/0,直接透传会导致 ERP 端判断逻辑全错。稳妥做法是在轻易云映射脚本里做一次归一化转换,而不是改 SQL。

典型错误 2:instruction_doc_num 匹配漏条件。素材里 SQL 明确写了 and return_order in (1,2,3),这是因为接口表里同一指令单号可能对应多种退料类型。如果新来的工程师偷懒只按单号匹配,会把不该更新的行一起更新掉。

翻车点 3:幂等没做。审核结果可能被重复回传(比如 MES 端重复推送),如果没有 attribute15 = :Id 这种幂等标记,同一个审核消息会被反复覆盖。稳妥做法是:每次回传生成唯一 Id 写入 attribute15,出现重复时人工可追溯。

典型错误 4:脚本里硬编码时间格式。time 字段如果在轻易云脚本里写死成 yyyy-MM-dd HH:mm:ss,遇到时区或夏令时就会错位。建议用平台内置的时间函数。

翻车点 5:两端调度完全对齐。很多客户一开始会把两端 crontab 都设成 */1 * * * *,结果目标端跑得比源端还快,出现空跑告警。错峰设置 + 目标端前置"源端是否产生新数据"判断,是增量与全量双轨上线时的标准做法。

适用场景与不适用场景

适用于:MES 端有独立审核流,结果需要异步回写到 MySQL/ERP 接口表,且对回写延迟容忍在分钟级的供应链场景。不适用于:需要实时(秒级)回传的双向协同,或审核流本身就运行在 ERP 内部不需要跨系统同步的场景。