物料成本核算单同步返回策略实战:从金蝶云星空拉取结果回写MySQL
这个策略解决什么问题
物料成本核算单在金蝶云星空里新增之后,MES侧的报表表头并不知道这次保存到底成功了没有、HEADER_ID 是什么、错误信息是什么。下游的对账、结账、重算都要等这层"同步返回信息"落库之后才能动。客户现场常见的痛点是:MES先调保存接口,金蝶返回OK,MES却没把 HEADER_ID 和同步结果写回自己的业务表,导致两边对账时口径不一致。
我们用轻易云数据集成平台(Qeasy)承接这层"短链路回写",把金蝶侧的同步结果准实时拉回来,更新到 MySQL 的成本核算单头表上。
数据流向与字段映射
整个链路分两段:第一段是金蝶云星空把物料成本核算单的新增结果回写到轻易云集成平台(内部状态落库);第二段是轻易云按调度把结果通过 SQL update 回写到 MySQL 业务表。
关键字段对照:
| 业务含义 | 轻易云侧字段 | 来源(金蝶/平台内部) | 目标 MySQL 字段 | 写入方式 |
|---|---|---|---|---|
| 单据头主键 | HEADER_ID | 金蝶返回 | ty_report.hme_cost_acc_header.HEADER_ID | WHERE 条件 |
| 来源单据ID | sourceid | 平台内部关联 | (仅内部使用) | 不落库 |
| 是否成功 | is_sucess | 金蝶返回 | sync_kingdee | 赋值 |
| 返回消息 | result_message | 金蝶返回 | (可按需扩展) | 可选 |
注意:is_sucess 字段名是金蝶接口本身的拼写,我们没有擅自改名,后续如果客户要统一成 is_success,建议在轻易云的字段映射里集中改一次,不要散落在多条策略里。
在轻易云上如何配置
源端配置(WebAPI,QUERY,POST):
- API 选择"请求空操作",类型为 WebAPI,effect 设为 QUERY;
- 自动填充响应 autoFillResponse 设为 true,这样平台内部状态(来源ID、是否成功、返回消息)会作为响应字段直接带出;
- 响应字段保留 HEADER_ID、sourceid、is_sucess、result_message 四个,其余不要勾,免得脏字段污染下游。
目标端配置(SQL,EXECUTE):
- 类型选 WebAPI,但 effect 是 EXECUTE,执行方式为 SQL;
- 请求参数 main_params 用对象类型承载 HEADER_ID 和 is_success 两个变量;
- 真正的写入 SQL 放在 otherRequest.main_sql 里,模板写法:
update ty_report.hme_cost_acc_header set sync_kingdee=:is_success where HEADER_ID=:HEADER_ID; - 开启 idCheck(true),平台会用 HEADER_ID 做幂等校验,重复回写不会重复扣账。
调度上,源端策略的 crontab 我们一般设成 */7 * * * *,目标端 SQL update 策略设成 */2 * * * *,让"拉取"比"回写"稍慢一拍,避免源端还没拉到结果,目标端就抢跑更新成空。
实施步骤
- 增量起点:先在金蝶云星空手动新增一张物料成本核算单,确认返回结构里 HEADER_ID、is_sucess、result_message 都齐;
- 全量触发:在轻易云上把源策略和目标策略的"立即执行"按钮各点一次,观察 MySQL 那张成本核算单头表的 sync_kingdee 字段是否被更新;
- 调度频率:稳态后,源端每 7 分钟轮询,目标端每 2 分钟执行,形成"近实时"的回写节奏;
- 回归校验:用 SQL 抽样 100 条核对 sync_kingdee 值与金蝶端的保存日志是否一致,误差要求为 0。
如果客户还有 MES 工序成本反写需求,可以在这条策略之后再接一条"工序成本明细同步",但要单独建策略,不要和头表回写混在一条 SQL 里——这是我们见过最容易翻车的地方。
踩坑复盘
- 典型错误是直接把金蝶的 is_sucess 字段名当 MySQL 列名用。稳妥的做法是在轻易云的字段映射里做一次别名转换,两边各用各的拼写,代码里别硬编码。
- 不要把 UPDATE SQL 写进 main_params 字符串里。main_sql 必须放 otherRequest,平台才会做参数化绑定;放错位置会导致 SQL 注入风险和全表更新事故。
- autoFillResponse 关掉之后字段会丢。这条策略依赖平台内部把来源ID和成功标志带出来,如果客户环境里关了它,HEADER_ID 还在,但 is_sucess 会变成 null,回写就全成"未同步"。
- idCheck 要保持开启。金蝶接口在网络抖动时偶尔会重复回调,关掉幂等校验会导致 sync_kingdee 被覆盖成错值。
- 不要让源端和目标端用同一个 crontab。两边同频时,目标端有时会读到上一轮还没刷新的源端状态,造成"看起来成功但实际是旧值"的脏数据。
适用场景与不适用场景
适用:金蝶云星空与 MES/报表库(MySQL)之间的轻量回写;单据保存结果的成功/失败标志落库;HEADER_ID 这类主键需要同步给下游对账的场景。
不适用:需要带回带明细行(表体)的批量同步——这种场景应该在轻易云里走表头表体分阶段策略,而不是把所有字段塞进一条 UPDATE;也不适合双向实时联机交易,毫秒级一致性建议走接口直连而非平台调度。