生产汇报单返回信息回传实战教程:用轻易云把金蝶云星空的反馈写回MySQL

这个策略解决什么问题

生产汇报单从 MES/中台推到金蝶云星空之后,车间关心的并不是「单据是否发出」,而是「金蝶有没有真正接收、成功还是失败、报错原因是什么」。这条策略解决的就是闭环问题:把金蝶云星空的接收结果(单据内码、编号、是否成功、消息文本)按 sourceid 写回到 MySQL 业务表里,让上游系统拿到反馈、决定是否重推。

在一次制造业客户现场,我们就用轻易云数据集成平台(Qeasy)承接这条回传链路,3 分钟一轮稳定轮询,失败时通过 result_message 直接定位问题。

数据流向与字段映射

数据流向:金蝶云星空(作为「源」,实际是被查询端) → 轻易云中间层 → MySQL(作为「目标」,业务回写表)。

源端通过金蝶云星空的「请求空操作」类查询接口(POST),按汇报单的 sourceid 抓取最新返回信息;目标端用一条更新 SQL 把结果写回 wms_instock_confirm_main_task_detail 之类的回写表。

关键字段对照:

源字段(金蝶返回)	中间层标识	目标字段(MySQL)	说明
`sourceid`	`:sourceid`	`KingDee_id` 关联键	业务回写定位主键
`生产订单号`	`:Number`	`KingDee_no`	金蝶单据编号
`is_sucess`	`:is_success`	`is_success`	成功标志位
`result_message`	`:message`	`KingDee_message`	失败原因/提示
—	`:time`	`syn_time`	同步时间,由平台注入

在轻易云上如何配置

源端策略用「请求空操作」+ autoFillResponse=true,平台会自动用源端单据的 Number、Id 等上下文去拼请求,避免每次手工注入。idCheck 建议打开,空跑时立刻能在日志里看到。

目标端策略直接走 SQL 执行类 WebAPI,main_sql 写在 otherRequest 里作为模板,main_params 走 request 数组,典型写法:

update wms_instock_confirm_main_task_detail
set KingDee_id=:Id,
    KingDee_no=:Number,
    syn_time=:time,
    is_success=:is_success,
    KingDee_message=:message
where id=:sourceid

配置上要注意三件事:

占位符命名要和源端响应字段一一对应,别图省事全用 :value。
编码映射集中放在轻易云的「字段映射」里,不要散落在每条策略里,后续换表只改一处。
表头(成功标志)与表体(消息、编号)分阶段回写,这样失败单据也能先落标志位,排查时不用等全字段。

实施步骤

我们建议分三步走,稳妥推进:

第一步,增量起点初始化。先在 MySQL 端跑一次全量,把历史未回写单据的 is_success 全部置为「处理中」,避免新一轮调度把老单据误判成「待回写」。

第二步,触发首批回传。手动触发一次策略,核对 5~10 条样本,确认 KingDee_id、KingDee_no、KingDee_message 都准确落表,再放开自动调度。

第三步,调度频率上线。生产环境按 */3 * * * *(每 3 分钟)轮询,既能保证 5 分钟内闭环,也不会把金蝶查询接口打满。

如果金蝶端积压比较多,可以临时切到「增量 + 全量双轨」:增量按 3 分钟跑,全量按小时补一次,跑完关掉。

踩坑复盘

is_sucess 拼写不一致。源端金蝶返回的是 is_sucess(源素材如此),目标 MySQL 字段是 is_success,中间层要做一次字段重命名,否则更新会「静默成功」——SQL 跑了但值没进去。
sourceid 重复回写。如果回写表里同一个 sourceid 存在多条(比如重推),更新会覆盖,丢失历史错误信息。建议用 where id=:sourceid and syn_time is null 这类条件,或者改用追加日志表。
空跑假阳性。idCheck=true + autoFillResponse=true 组合下,源端没数据时也会返回一行,导致 is_success 被错写成「成功」。稳妥的做法是在目标 SQL 里加 where exists(真实回执) 之类的判定,或干脆把空响应过滤掉再写。
金蝶限流。每 3 分钟一轮,每轮如果一次查几百条,容易触发金蝶云星空的 API 限流。客户现场常见做法是单次拉 50 条、失败重试 3 次,轻易云的「分页+限速」参数正好对应这个需求。
消息文本乱码。金蝶返回的 result_message 偶尔带 emoji 或特殊字符,MySQL 表字符集如果不是 utf8mb4,会出现截断或 ?。

适用场景与不适用场景

适用:金蝶云星空作为接收方,需要把处理结果(成功/失败/单据号/消息)回写到上游业务库,做单据闭环或重推判定的场景。

不适用:实时性要求秒级的场景(本方案分钟级,改用消息推送更合适);以及金蝶端没有对应查询接口、只能靠回调拿结果的场景。