MOM计划推转移结果回传:从金蝶云星空到MySQL的轻量闭环实践

这个策略解决什么问题

在某离散制造企业的生产现场,MES侧按下「推转移」之后,计划员需要知道 ERP 端有没有真正生成那张转移单、生成的单据号是多少、是否成功。

如果只把请求推过去,没有把结果回写到 MES,就会出现「MES 显示已提交、ERP 端却查无此单」的尴尬,排产员只能去 ERP 翻日志。

MOM-GXJH-计划推转移-转出(通用)-返回 这条策略就是解决这个闭环问题的:它在金蝶云星空生成转移单后,把成功标志、单据号 FBillNo、单据内码 FID,以及结果消息写回 MES 侧的 MySQL 接口表,让 MES 端能直接看到 ERP 的最终结果。

整体流向是 金蝶云星空(经由轻易云数据集成平台)→ MySQL,本质是一次「结果回写」,而不是主数据推送。

源端来自轻易云平台内部的中间结果(由上游策略触发后的回调消息),目标端是 MySQL 中的接口表。关键字段对照如下:

注意这里有个关键细节:iface_sequence = 1 走主更新,iface_sequence = 3 只更新 FID 和 FBillNo 不改状态。这是把「头信息回写」和「状态回写」拆成两段 SQL 的常见做法,在轻易云客户现场经常被叫做「表头表体分阶段」。

源端元数据是 WebAPI 类型的「请求空操作」(QUERY),它的作用是「等结果」,不主动调外部接口;真正触发回写的是上游策略把消息推送到本策略的消息队列。配置时把 autoFillResponse 设为 true,响应字段(上面那张表的左列)由上游自动注入,无需手工组装。

目标端是 MySQL 的 SQL 执行(EXECUTE),需要填两条 SQL:

主 SQL(main_sql):带条件 batch_id = :sourceid and iface_sequence = 1 and status not in ('S','A'),只更新非终态记录,避免重复覆盖已成功的行;
扩展 SQL(extend_sql_1):条件 iface_sequence = 3,只回写 FID 和 FBillNo,不改动 status,留给后续状态回写策略使用。

配置上还要注意一点:轻易云的「编码映射集中管理」在这里的价值在于,status 这个枚举值(成功/失败/异常)由映射表统一定义,后续如果要适配另一种 ERP,只换映射,不换 SQL 结构。

我们建议按「增量起点 → 全量触发 → 调度频率」三段来上线。

增量起点:先用一批历史已生成但未回写的数据做冷启动,通过全量 SQL 一次性把 FID/FBillNo 补齐,避免新旧数据混在一起难以排查。
全量触发:上线首日,人工在轻易云上对未成功的 iface_sequence = 1 记录手动触发一次,确认回写结果无误后再开启定时调度。
调度频率:源端 */7 * * * *、目标端 */1 * * * *。也就是说,平台每隔 7 分钟拉一次结果缓存,SQL 每分钟落地一次。这种「上游较稀、下游较密」的频率差,既能跟住上游回调节奏,又能避免漏单。

1. 漏加 status not in ('S','A') 导致重复覆盖。 这是最典型的翻车点:成功记录被多次回写,虽然值不变,但日志看起来像在反复更新,排查问题时会误导工程师。稳妥的做法是主 SQL 始终带这条过滤条件。

2. 把 FID 回写和状态回写塞进同一条 SQL。 一次写完看似省事,实际会让 iface_sequence = 3 的中间态记录也被改成终态,后续状态策略失效。所以坚持表头表体分阶段。

3. 字段名拼写沿用上游原样(is_sucess)。 这不是轻易云的锅,而是源端 ERP 返回就带错别字。建议在映射里把 is_sucess 重命名为 is_success,避免传染到下游所有表。

4. 调度频率两端相同导致积压。 源端和目标端都用 */1 * * * * 时,源端没有新数据时目标端会空跑。把源端放稀、目标端放密,既稳又省资源。

适用:MES 提交计划后,需要拿到 ERP 单据号才能继续后续工序的场景,例如车间报工、成本归集。

不适用:主数据(物料、BOM)同步,以及需要实时推送(秒级)的工位叫料场景——本策略分钟级调度,实时性不够;另外,金蝶云星空未启用的情况下,源端没有结果可回写,策略会空转。