客户主数据增量更新：金蝶云星空到四化智造 MES 的 updateCustomer 同步策略实战
这个策略解决什么问题
某零售企业的 ERP 用的是金蝶云星空，生产现场用的是四化智造 MES。客户档案一旦改名、改编码、改联系方式,如果只靠人工在 MES 里改,两三个月后两边的客户编号就开始对不上,后续的订单回传、发货校验全部都会出错。
金蝶客户对接mes客户_修改 这个策略,只做一件事:把金蝶侧已审核的客户变更,增量推到 MES 的 updateCustomer 接口,定位更新而不是新增。素材里这条策略和 create 策略是配套的:create 管"首次",这个管"变更",搭配起来才是完整的客户主数据闭环。在轻易云数据集成平台(Qeasy)里,我们把客户修改这条策略独立出来,避免新客户和已变更客户混在同一条流里导致幂等性问题。
数据流向与字段映射
数据流向非常直接:金蝶云星空(BD_Customer) → 轻易云集成中台 → 四化智造 MES(Customer)。源端通过 executeBillQuery 拉取,目标端调用 /api/updateCustomer 执行更新。
关键字段对照表如下:
| 目标字段(MES) | 源字段(金蝶) | 映射类型 | 说明 |
|---|---|---|---|
| companyCode | 固定常量 | CONSTANT | 公司代码,固定填写租户/组织标识 |
| customerNo | {{FCUSTID}} | DIRECT | 金蝶客户主键,作为 MES 唯一流水号 |
| customerName | {{FName}} | DIRECT | 客户名称 |
| customerFullName | {{FName}} | DIRECT | 客户全称,与名称同源 |
| customerCode | {{FNumber}} | DIRECT | 金蝶编码透传 |
| contactName / contactPhone / currency / addressDetail 等 | 空字符串 | CONSTANT | 源端字段未映射,留待后续扩展 |
注意一点:customerNo 取的是 FCUSTID 而不是 FNumber。这样设计的目的是即便客户编码被改了,只要 ID 没变,MES 侧就能定位到同一条记录,避免出现"改了编码就找不到人"的尴尬。
在轻易云上如何配置
在 Qeasy 的策略编辑界面,我们习惯把编码映射集中管理,这条策略本身没有走 _findCollection,全靠直接映射和常量兜底,反而更稳。配置要点如下:
- 源端配置:协议选 WebAPI,effect = QUOTE,接口
executeBillQuery,主键FCUSTID,单据编号字段FNumber,idCheck 关闭(源端是查询语义,不需要做目标端存在性校验)。 - 目标端配置:协议 WebAPI,effect = EXECUTE,接口
/api/updateCustomer,idCheck 必须开成 true,这一步是这个策略的灵魂——只有开了,平台才会按customerNo去校验目标端是否存在,存在才更新,不存在跳过或告警,绝不会出现"重复创建"的脏数据。 - 字段映射:按上表逐一绑定,空值字段用空字符串常量,不要用 null,部分 MES 接口对 null 敏感。
- 增量变量:FilterString 里写
FApproveDate>='{{LAST_SYNC_TIME|datetime}}',这是轻易云标准的"上次同步时间"占位符,每次调度自动续接。
实施步骤
我们给客户落地时,通常分三步走,稳妥:
第一步,增量起点。 第一次上线,先用全量跑一遍 create 策略(对应的 P3-089),把已有客户全部建到 MES。这一步是地基,跳过直接跑 update 会导致大量"目标不存在"告警。
第二步,本策略生效。 create 跑稳之后,把 update 策略挂到调度器。建议先手动触发一次,核对一条已变更的客户数据是否正确更新到 MES,确认无误再上线定时。
第三步,调度频率。 按素材给的 * 7-22 * * *,也就是每天 7:00 到 22:00 的每个整点执行一次。客户档案变更不要求秒级同步,小时级足够;晚于 22 点不再触发,留出窗口给 MES 自身做夜间批处理。这种"表头增量 + 白天高频"的模式,是轻易云客户现场最常见的打法之一。
踩坑复盘
坑一:和 create 策略混淆。 早期我们图省事,把新增和修改合在一个策略里用 if-else 分支。运行三个月下来发现,MES 接口对同一 customerNo 重复调用 create 会报错,而 update 又不能覆盖全新客户,日志里一半是脏数据。后来老老实实拆成两条策略,create 用 createCustomer、update 用 updateCustomer,问题迎刃而解。
坑二:忘了开 idCheck。 目标端 idCheck 没勾选时,平台会盲调 updateCustomer,有些 MES 实现的语义是"不存在就创建",结果 MES 端冒出很多 customerNo 相同但来源不明的记录。稳妥的做法是 idCheck 始终开 true,让平台先校验。
坑三:用 FNumber 做定位键。 有人图方便把 customerNo 设成 {{FNumber}},结果客户编码在金蝶里被改过一次,这条记录就再也找不到了。一定要用业务主键 FCUSTID 这种 ID 类字段做定位键。
坑四:24 小时不间断调度。 客户要求"越实时越好",我们一度改成 5 分钟一次。结果和 MES 的夜间作业冲突,触发限流。改成工作时段整点跑,既满足及时性,又错开 MES 高峰。
坑五:空值字段被忽略。 素材里 contactPhone、addressDetail 等字段在源端是有数据的(FADDRESS、FTEL),但当前策略没映射,默认空串。三个月后业务方找过来问"为什么 MES 里电话是空的",才发现早期偷的懒。后期我们用 _function 加 case when 做了空值兜底,或者直接把字段映射补上。
适用场景与不适用场景
适用场景:金蝶作为 ERP 主数据源,客户变更需要同步到生产/制造端 MES,且 MES 提供按 ID 定位的 update 接口;企业已有 create 策略作为前置,本策略做增量补丁。
不适用场景:首次建档(请走 create 策略);MES 端没有按主键定位的能力,只能全量覆盖;客户变更频次极高(秒级),这种应改用消息队列而非定时同步。