物料成本核算单同步返回信息策略实战教程:从金蝶云星空回写 MySQL 的闭环设计

这个策略解决什么问题(场景与价值)

物料成本核算单在金蝶云星空保存后,业务团队往往需要在 MySQL 这边立刻看到「是否成功、提示什么」。我们这次处理的就是这条最短闭环:金蝶侧一有修改返回,MySQL 业务表就把 HEADER_ID 对应的那行打上同步结果标签。一次实际项目里,客户最初是凌晨批处理回写,导致车间上午对账时 MySQL 还是「未回执」状态,排查问题要追溯十几个小时。改成准实时回写后,定位时间从小时级压到分钟级。

数据流向与字段映射

整体流向是「金蝶云星空 → 轻易云 → MySQL」。源端是一个「请求空操作」(effect=QUERY)动作,只负责按 HEADER_ID 拉取本次提交的返回信息;目标端是一条 update SQL,直接改 MySQL 业务表的 sync_kingdee 字段。

关键字段对照:

目标端只接收 main_params 对象,核心 SQL 是:update ty_report.hme_cost_acc_header set sync_kingdee=:is_success where HEADER_ID=:HEADER_ID。

在轻易云上如何配置

在轻易云数据集成平台(Qeasy)里,这条策略配置成「源组件 + 目标组件」两步式,没有写转换脚本,字段映射直接走平台内置绑定。

源组件要点:autoFillResponse 打开,这样返回体里的字段值会作为变量传给下游;is_sucess、result_message 这些字段保留为空值,由运行期填充。

目标组件要点:method=SQL,idCheck=true,buildModel=false。参数绑定时把源端的 HEADER_ID、is_sucess 映射到 main_params,再让 otherRequest 里的 main_sql 引用这些命名参数。

实施步骤

分三阶段上线。

第一阶段:增量起点。 先确认 MySQL hme_cost_acc_header 表里 sync_kingdee 字段已存在,默认值为「N」或空。源端以「最近一次成功提交的 HEADER_ID 列表」作为起点,避免空跑。

第二阶段:全量触发。 上线第一天手动触发一次,把历史未回写的数据补齐。源端 crontab 设为 */7 * * * *,每 7 分钟拉一次金蝶返回;目标端 crontab 设为 */2 * * * *,只要队列里有数据就尽快写回 MySQL。两条调度时间错开,避免雪崩。

第三阶段:稳态运行。 观察一周,确认 sync_kingdee 字段更新延迟稳定在分钟级,再把人工巡检脚本铺上。

踩坑复盘

踩坑 1:is_sucess 的拼写不一致。 源端字段名带下划线 is_sucess(明显是金蝶侧的拼写习惯),目标 SQL 写成了 is_success。典型错误是直接复制 IDE 提示去改,结果两边对不上。稳妥的做法是字段名保持原样,在 MySQL 列名上对齐,而不是反过来。

踩坑 2:result_message 为空时 SQL 报错。 当金蝶返回成功时,消息文本是空字符串,如果按 NOT NULL 写入就会抛错。建议把 MySQL 端列允许 NULL,或者源端做一层默认值兜底。

踩坑 3:HEADER_ID 类型是 float。 MySQL 主键如果是 bigint,直接传 float 会丢精度。稳妥的做法是在平台里加一步类型转换,统一转成字符串再比对,或者 MySQL 端改成 VARCHAR 主键。

踩坑 4:crontab 错位导致回写落后。 源端 7 分钟一轮、目标端 2 分钟一轮,看似合理,但如果源端一轮拉 200 条,实际落地可能要十几分钟。容易翻车的地方是只看调度频率,不看单批数据量。

踩坑 5:没有把「同步返回信息」和「同步主数据」混在一条策略里。 一次实际项目中,客户图省事把返回回写塞进主数据推送策略,结果主数据失败时返回回写也跟着失败,排错时互相干扰。稳妥的做法是表头表体分阶段、回写独立成策略。

适用场景与不适用场景

适用: 单据保存后,业务侧需要快速拿到「成功/失败」标签的闭环场景;MySQL 作为查询库、金蝶作为业务系统的典型组合。

不适用: 需要返回明细行(表体)或大量业务字段的场景——本策略只回写 HEADER_ID 级别的成功标志,不适合做完整单据镜像。