在制造业的 MOM(制造运营管理)链路里,计划订单从 MES 下推到金蝶云星空只是一半。车间在金蝶云星空做完汇报,审核状态、单据号、明细 ID 需要回流到 MES 这边的接口表,后续的车间作业、报工、入库才能继续往下走。这一步典型的卡点是:汇报单据频繁,但 MES 接口表只能按业务键幂等更新;一旦返回链路断了,车间看板就会出现「汇报了但 MES 没收到」的孤儿状态。本策略就是承接这条「回写」链路,我们用轻易云数据集成平台(Qeasy)把金蝶云星空的回报结果按计划单据键回写到 MySQL 接口表,做到两边状态一致。
数据流向与字段映射
数据流向比较简单:源端是轻易云平台内部触发器(基于上一条「计划推汇报」策略的执行结果),目标端是 MySQL 的两张接口表。关键字段对照如下:
注意两张表的 status 语义并不完全相同:汇报表用 S/A 表示成功/异常;入库接口表用 N/A 表示未处理/异常。回写时必须按各自语义落库,不能直接照搬字段值。
在轻易云上如何配置
源端 metadata 用的是「请求空操作」(autoFillResponse=true)的 WebAPI QUERY,实际上它不承担真正的取数,而是作为整条策略的执行入口与参数承接点,真正的数据已经在前序策略的上下文里。
目标端 metadata 用 WebAPI EXECUTE + SQL 方式落到 MySQL,这里有几个典型配置要点:
- 表头与扩展 SQL 分阶段:主表 main_sql 处理 hme_operation_report_iface,扩展 SQL extend_sql_1 处理 hme_prd_instock_iface。这种「表头表体分阶段」的模式在轻易云客户的供应链集成里非常常见,把同一事务下需要更新的多张表拆开,便于失败重试和单表补偿。
- 幂等条件内置在 WHERE 里:status not in ('S','A')、status not in ('N','A') 这类条件直接写进 SQL,意味着已经成功或异常终态的行不会被二次覆盖。这是增量与全量双轨之外的第三道闸——状态机幂等。
- 业务键参数化::fid、:FEntity、:fbillno、:is_success、:result_message、:iface_id、:operation_type、:source_id 这些绑定变量都来自源端传入,字段命名要保持和上游策略一致,否则会出现「值传进来了但落不到列」。
- idCheck=true:目标端开启了 ID 校验,避免脏数据被重复插入。
实施步骤
我们给客户做这套方案时,通常按三段推进:
- 第一段:增量起点。先确定「待回写」的筛选条件——也就是 MySQL 接口表中 status 处于可更新区间的记录。建议从一周的历史数据里挑 50 条左右做回放,验证映射与状态机无误。
- 第二段:全量触发。源端 crontab 设为 */7 * * * *,也就是每 7 分钟轮询一次,频次足以覆盖车间节奏,又不会对金蝶云星空接口造成压力;目标端 */1 * * * * 的 1 分钟节拍只在源端有结果产出时才会真正执行,平时是空跑,这是轻易云常见的「源端稀疏、目标端紧凑」调度组合。
- 第三段:稳定运行。上线后盯一周的 result_message,把出现频次最高的错误码归类,沉淀到编码映射表里做集中维护——这是轻易云客户常用的「编码映射集中管理」做法。
踩坑复盘
- 空操作源端的字段名容易混。autoFillResponse=true 看似省事,但下游 SQL 的绑定变量名必须和上游策略的 value 完全一致,否则 :fbillno 会拿到空串。这里稳妥的做法是把变量名沉淀到策略命名规范里。
- status 终态漏写导致重复回写。某次现场我们发现,汇报失败的行被反复写,因为 SQL 里只判了 status not in ('S','A'),没有把异常终态纳入;后来把终态集合写全,问题消失。
- 两张接口表状态语义不一致。汇报表用 S/A,入库接口表用 N/A,千万不要图省事共用一个映射函数,否则会出现「汇报成功但入库接口被误判」。
- NOW() 时区问题。私有化部署里 MySQL 服务器和金蝶云星空服务器时区可能不一致,last_update_date = NOW() 取的是 MySQL 本地时间,排查问题时记得比照 UTC,否则容易误判延迟。
- 依赖前序策略但 depends_on 为空。这条策略本质上是上一条「计划推汇报」的回报链路,虽然 index 里 depends_on 列表为空,但运行时上下文依赖很强,排错时一定要顺着前序策略的执行日志追,而不是从这一条孤立地看。
