生产领料单回执回传实战:从MES到MySQL的闭环同步方案

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

生产领料单从MES下发到ERP后,车间执行的结果(成功标志、消息文本、领料单号)必须回到业务侧才算闭环。如果只做单向推送,WMS或调度台永远不知道这一单究竟领没领成、领了多少、错在哪里。本文要解决的就是这个"回执回传"环节——把MES返回的执行结果,落到业务库的明细行上,让任务表自洽。

这条策略属于"双向集成"中的回写段:源是轻易云集成平台承载的MES返回接口(QUERY/POST空操作,触发式拉取),目标是一张业务MySQL明细表(EXECUTE/SQL)。

关键字段对照:

目标SQL(简化示意): update wms_instock_confirm_task_detail set is_success1=:is_success where uuid=:sourceid。

我们在客户现场做这一类策略时,通常按下面三步落地:

源端选"请求空操作" + QUERY:平台充当"轮询拉取"角色,定时把MES侧新产生的回执抓回来。autoFillResponse=true 让返回结构自动带出来,字段映射不用手抄。
目标端用SQL直连MySQL:不走单据接口,直接走update,条件就是uuid=:sourceid。这种"短链路回写"比再过一层API稳得多。
字段映射只抓4个关键值:sourceid 做定位键,is_sucess 落状态位,result_message 和领料单号 可选写入日志表或冗余字段,不要一股脑全塞到主表。

我们建议分三阶段调度:

阶段一增量起点:先跑一次历史回执,把积压的执行结果一次性回写,作为基线。
阶段二定时拉取:源端 crontab 设为 */7 * * * * 这种较密节奏,因为回执是事件驱动,频度可以拉高;目标端因为只是 update,频率可以更密(*/2 * * * * 也没问题)。
阶段三异常兜底:对is_sucess=失败的回执,单独打标记,触发重试或人工看板。轻易云上常见做法是把"成功"和"失败"拆成两个分支,失败走钉钉/企业微信告警。

**is_sucess 这个字段名带下划线和拼写错误,源端原样照搬,下游SQL里就得跟着写is_sucess,改起来很恶心。**稳妥做法是在轻易云里做一次"字段标准化",统一改成is_success。一次改错,所有下游都错。
**定位键不要用业务单据号,要用UUID或来源系统主键。**MES里领料单号可能在不同工序里复用,用业务号定位会导致误更新。
**回执里的"生产订单号"别直接落主表。**它只是上下文信息,落到主表会和后续生产订单同步策略打架,放进日志/冗余字段即可。
**crontab 别两个端都设成一样的频率。**源端是"拉",目标端是"写",两边同时高并发容易把MySQL行锁顶住。我们的经验是源稀目标密,或反过来,避免齐步走。
**失败回执一定要可观测。**如果只 update 不打日志,3 个月后客户问"为什么这单没领到"时,谁也答不上。

适用:MES/ERP之间需要把执行结果回写到业务库、做任务状态闭环、且数据量在百万级以内的明细行回写。 不适用:需要强事务一致、跨系统对账的场景;以及回执字段极多、需要复杂业务校验的复杂单据回传,那种更适合用API而不是裸SQL。