组装生产日期反写同步：MySQL 状态回流到金蝶云星空的实战方案

这个策略解决什么问题

某制造企业的 MES 端组装产线在使用金蝶云星空进行生产订单管理时，遇到一个高频但容易被忽略的问题：MOM 侧修改了某张组装生产单据的生产日期，MES 需要回写一个「已同步」标识，避免下一次又把这条记录当作新数据重复推过去。看似只是改个标志位，但若没有独立的策略承载，3 个月后 MES 报表里的「已同步」与「未同步」会彻底对不上账。

这个策略本质是一次单向反写：源端发空查询、金蝶云星空侧执行标志写入，再由平台落库到中间库，调度频率约每两分钟一次。它不搬运业务字段，只搬运状态位，是生产同步链路里的「收尾」环节。

数据流向与字段映射

整条链路是：MySQL(MES 侧) → 轻易云数据集成平台(中间层) → 金蝶云星空(目标系统) → 回流到 MES 侧状态库。

关键字段只有三个，全部从源端经过中间层透传到目标端：

源端的 API 实际是一个 POST 的「请求空操作」接口，仅返回上述三个字段；目标端是金蝶云星空的 ZZdate2 WebAPI，方法为 POST，效果为 EXECUTE，请求体通过 _function CONCAT 把三个变量拼装成金蝶要求的 JSON。整个映射表非常薄，轻易云平台上常见的做法是把这种薄映射集中放到一张「轻映射表」里管理，避免每个策略都重复维护。

在轻易云上如何配置

在轻易云数据集成平台(Qeasy)中，这条策略以「源策略 + 目标策略」成对方式落地：

源端配置要点

• 平台类型：MySQL 对应的适配器；
• API：选择空操作或自定义查询接口，方法 POST，effect 设为 QUERY；
• 响应字段只勾选 formId、fid、rowsid 三个，其余忽略；
• 勾选 autoFillResponse，由平台自动构造响应，避免手工造数据；
• idCheck 打开，便于去重。

目标端配置要点

• 平台类型：金蝶云星空适配器；
• API 选 ZZdate2，method POST，effect EXECUTE；
• 请求体使用 _function CONCAT 把三个变量拼成金蝶要求的 JSON 串，FormId 字段用 _function 包裹；
• 响应字段留空，因为执行类接口不关心返回体；
• 同样打开 idCheck。

配置层面有几个我们经常看到的做法：薄字段映射走「集中映射表」、调度时间统一在策略的 crontab 字段里写、不要散落在各个执行器；自增序列 sequence 用于控制同一业务对象多条策略的执行顺序，本策略可以放在靠后的位置。

实施步骤

第一步：定义增量起点。 这条策略不搬运业务主数据，所以「增量」概念要重新理解——它搬运的是「上次未写过标识的记录」。在源端 SQL 或查询条件里加上 sync_flag = 0 AND update_time > 上次同步时间，只把还没打过标的记录捞出来。

第二步：先做一次全量触发，验证链路。 上线当天手工触发一次全量，观察金蝶侧 ZZdate2 接口的返回和 MES 侧状态库是否同步更新；同时把金蝶返回的错误码落库，便于排查。

第三步：进入高频调度。 crontab 配置为 */2 * * * *，每两分钟跑一次。轻易云客户常见做法是「增量与全量双轨」：调度器跑增量，夜间窗口跑全量校对，本策略因为只反写标识，夜间全量可以每天跑一次。

第四步：异常与重试。 配置失败重试 3 次，间隔指数退避；连续失败超过阈值告警到运维群。

第五步：上线后第一周每天对账，重点核对「源端未标记录数」是否随时间收敛到零附近。

踩坑复盘

踩坑一：把空操作当成业务查询来配置。 源端 API 实际只回传三个标识字段，业务同学一开始照着普通查询配置，结果把无关字段都拉过来，映射表膨胀了三倍。稳妥做法是：响应字段只勾需要的三个，autoFillResponse 打开。

踩坑二：_function CONCAT 里变量名写错大小写。 金蝶侧请求体对变量大小写敏感，{{formId}} 写成 {{Formid}} 会在金蝶端报空指针。配完一定要用「调试执行」跑一次，肉眼对照拼出来的 JSON。

踩坑三：忘了打开 idCheck。 没打开的话，平台不会按单据主键去重，同一条记录会被反复打标，源端日志里能看到同一个 formId 一分钟内出现多次。

踩坑四：调度频率过密。 一开始有人设成每 30 秒一次，结果金蝶侧接口频次限流，直接封 IP。两分钟一次是踩过这个坑之后的安全值，业务量大时可调，但要先确认金蝶侧的 QPS 上限。

踩坑五：表头表体一次性反写。 如果生产日期在表头、状态字段在表体，应该分两阶段：先反写表头标识，再反写表体标识，避免一条记录只更新一半。

适用场景与不适用场景

适用：生产订单/组装单的状态位、已同步标识、最后修改时间戳等「轻量字段」反写；源端无法直接写目标库的间接同步；需要高频但负载低的轮询场景。

不适用：业务主数据(物料、BOM、工艺路线)的全量同步；跨组织的批量数据迁移；对账要求毫秒级的实时场景——这种应该走事件驱动而非轮询。