客户物料对应表同步金蝶建单回写实战:从源 MySQL 到金蝶云星空的回环配置

这个策略解决什么问题

在某零售企业的供应链集成现场,我们最常被问到的不是「能不能同步」,而是「同步过去之后,源端怎么知道结果」。客户物料对应表从 CRM 端的 MySQL 推到金蝶云星空建单,只是链路的一半;另一半是金蝶端的单据编号、成功标志、错误信息要回写到 MySQL,业务人员才能基于这一张对应表做后续动作。这条策略把「推单 + 回写」做成一个闭环,避免出现「金蝶里已经有单,但 CRM 端不知道」的孤儿数据。

数据流向与字段映射

整体流向是 MySQL(源业务表) → 轻易云集成平台 → 金蝶云星空(建单) → 轻易云集成平台 → MySQL(回写状态)。源端是一张客户物料对应表,平台侧把它组装成金蝶 WebAPI 所需的请求体;目标端在金蝶成功建单后,把单据编号与成功标志回写到源表的指定字段。

值得注意的是,字段名是平台内部的逻辑名,真正落到数据库时再映射为列名,这一点在客户现场最容易因为「字段名长得像列名」而混淆。

在轻易云上如何配置

我们在轻易云数据集成平台(Qeasy)里把这个策略拆成两段:一段是「源 → 金蝶」的推送,一段是「金蝶响应 → MySQL」的回写。

第一段,源 API 配置成 WebAPI / POST / QUERY,请求体留空(空操作),靠脚本从 MySQL 抽取待同步记录;响应里声明 单据编号、sourceid、is_sucess、result_message 四个字段,作为后续回写的输入。

第二段,目标 API 配置成 WebAPI / SQL / EXECUTE,otherRequest 里直接写 main_sql,形如 update wk_wodtop_customer_material_ref set sync_1=:is_success, sync_2=:is_success1 where data_id=:sourceid,参数 main_params 是对象类型,把第一段响应里的四个字段映射过去即可。

编码映射我们建议集中放到平台的映射表里维护,而不是散落在每个策略里——这是轻易云客户里最常见的应对模式之一,后期换编码规则只改一处。

实施步骤

第一步,在源 MySQL 里确认对应表有 data_id 主键和两个标志字段,缺一不可;缺了 data_id,回写就找不到行。第二步,在轻易云里先把源 API 与目标 API 各建一条,先用一条记录做单点验证,确认金蝶能建单、MySQL 能被更新。第三步,把单点跑通后,再配调度:源端 */2 * * * *,目标端 */7 * * * *,让回写节奏比推送略慢,避免出现「单据还没建出来,回写就已经执行」的情况。

增量起点建议从「当前时间往前推 N 分钟」开始,先把存量里未同步的数据清空;全量触发则用一次性脚本,只在初始化时跑一次,跑完后停掉,后续完全靠增量。

踩坑复盘

踩坑一:把回写当成独立的策略,而不是闭环的一部分。 典型错误是只配了「源 → 金蝶」就收工,结果金蝶侧的 单据编号 永远回不来,业务人员还是要在两边对账。稳妥的做法是把回写当成推送策略的下游,而不是另起一条并行策略。

踩坑二:sync_1 和 sync_2 含义不分。 我们在客户现场见过一种情况:sync_1 写的是「平台推送成功」,sync_2 写的是「金蝶建单成功」,两者经常被混用,导致报表口径不一致。稳妥的做法是在字段命名阶段就定清楚,比如 sync_push 与 sync_kd,并写到映射表说明里。

踩坑三:回写 SQL 里 where 条件用了业务字段而不是 data_id。 一旦业务字段在源端被改过,回写就会落空。稳妥的做法是始终用 data_id 这类不可变主键做定位。

踩坑四:调度频率倒挂。 源端每 2 分钟推一次,目标端每 7 分钟回写一次,看似没问题;但金蝶建单本身有耗时,回写如果跑得比建单还快,会拿到空值。稳妥的做法是回写节奏 ≥ 推送节奏,且加一个「响应非空才回写」的判断。

适用场景与不适用场景

适用:CRM 与 ERP 之间存在「业务对应表 + 单据回写」形态、且源端是关系型数据库、能提供稳定主键的场景。不适用:金蝶侧是批量导入而非单据建单、或源表没有稳定主键无法回写的场景,以及需要强实时(秒级)回写的场景——这种建议走消息队列而不是轮询。