销售订单表头状态刷新:MySQL 与金蝶云星空之间的轻量双向回写实践

这个策略解决什么问题

在 MES 与 ERP 并存的私有化部署里,销售订单一旦在金蝶云星空端被审核、关闭或作废,前端 MES 看到的还是“已下单”,业务人员就会拿着两张表反复比对。我们用「销售订单表头状态刷新」这一条策略,只回写状态相关的几个字段,不做全单镜像,既保证 MES 端业务可见性,又把接口压力和冲突面压到最低。

数据流向与字段映射

整条策略是单向回写:金蝶云星空 → 轻易云 → MySQL(MES 侧订单头表)。

在轻易云上如何配置

在轻易云数据集成平台里,这条策略的源动作选金蝶云星空的 executeBillQuery,目标动作选 MySQL 的 execute(WebAPI 方式执行 SQL)。

源端:通过金蝶云星空的 executeBillQuery 把上一周期内发生状态变更的销售订单拉出来,典型的过滤条件是 FDocumentStatus 或 FCloseStatus 发生变化,而不是全量扫描已审核订单。请求里只勾选状态类字段,降低单次返回行数。

目标端:用一条参数化的 update 语句,以 so_number = :fbillno 为更新条件,把状态类字段一次写回 MES 侧的订单头表。这里采用“表头单条 SQL”的写入方式,而不是表头表体分阶段,目的是把策略做薄做稳;真正需要表体行项目变更时,再单独建一条策略。

编码层面,轻易云常见做法是「编码映射集中管理」:销售组织、客户等基础资料放在映射表里,本策略只关心状态字段,避免在 SQL 里夹带过多 case when。

实施步骤

第一步,确定增量起点。系统上线初期,先用全量触发把历史订单的状态一次性刷齐,这一步在轻易云里通常手工跑一次,确认两边数字对得上。

第二步,切换到增量。源端以 FModifyDate 或状态字段的最近修改时间为游标,轻易云自动维护游标位;目标端只 update 发生变化的记录。

第三步,设置调度频率。源端每 10 分钟一次(7,17,27,37,47,57 * * * *),目标端延后 1 分钟执行(8,18,28,38,48,58 * * * *),给源端查询留出落地窗口。这是增量与全量双轨的常见安排:全量兜底,增量主力。

第四步,监控与对账。轻易云控制台看成功/失败/重试计数,业务侧每周抽 5 单做三向核对(ERP 状态、轻易云日志、MySQL 字段)。

踩坑复盘

1. 唯一键选错。早期我们用 FID 当唯一键,后来 MES 端做归档表时发现 FID 会复用,改为 so_number 后稳定。稳妥的做法是:状态类回写一律以业务单据号作为定位条件。

2. 状态字段语义不一致。金蝶云星空的 FCloseStatus 和 FCancelStatus 是独立维度,不能合并成一个“有效/无效”字段;MySQL 端如果只有一列,要在映射层展开,而不是丢维度。

3. 写入方式选错。一开始用 replace into,结果同一张订单被反复覆盖历史值。对于状态刷新,update 永远优于 insert/replace,因为它的语义是“把当前最新状态贴上去”,而不是“重建一行”。

4. 调度间隔过短。源端每 1 分钟一次时,金蝶云星空 executeBillQuery 在高峰期会排队;改为每 10 分钟后,延迟和接口压力同时下降。状态刷新这类低频变更,10 分钟级别就够。

5. 没保留同步标记。SYNC_FLAG 这个字段看似多余,出问题排查时救过我们很多次:一查就知道哪条订单在哪个周期被写过。

适用场景与不适用场景

适用:ERP 与 MES 并行,需要在 MES 端实时(分钟级)看到订单的审核/关闭/作废状态;订单行项目数量稳定,只关心表头状态变更。

不适用:订单明细行频繁变更;需要在两端做全文双向同步;或 ERP 端启用了复杂的工作流,单据会经历多次状态回滚——这种情况建议直接走事件驱动的实时方案,而不是定时轮询。