物料主数据同步实战:从金蝶云星空到小满OKKICRM的单一策略深度拆解

这个策略解决什么问题

物料主数据从 ERP 推到 CRM,看起来只是「把编码、名称、规格搬过去」,但真到了客户现场,销售在 CRM 里报价时发现编码对不上、规格型号错位、单位不一致,3 个月后两边数据已经分叉得不可收拾——这是我们见过最典型的「简单事情做砸了」的场景。本文聚焦一条单点策略:把某 ERP(本文称「A 系统」)的物料主数据,以定时轮询的方式抽取并写入某 CRM(本文称「B 系统」)的产品库,保证两边编码一致、关键属性同步,让销售、供应链、财务都拿到同一套物料口径。

数据流向与字段映射

整体流向为 A 系统(源) → 轻易云数据集成平台(中间层) → B 系统(目标)。源端通过查询接口按编码去重拉取,中间层做字段映射与转换,目标端通过 WebAPI 写入产品档案。

关键字段对照表(基于真实生产元数据,数值类字段以原样透传,文本字段按目标接口约束处理):

源端的 number 与 id 字段分别对应业务编码和系统主键,目标端的这两个位置都填 "0",意味着目标系统自身负责唯一性,中间层不参与主键生成。

在轻易云上如何配置

在轻易云(Qeasy)数据集成平台里,这条策略落成一个标准的「源 QUERY + 目标 EXECUTE」组合,几个关键配置点:一是源端用 executeBillQuery 这类查询接口,把 idCheck 打开,让平台用主键做幂等校验,断点续跑不会重复;二是源端的 buildModel 关闭、autoFillResponse 打开,响应结构由平台自动填充,不用手写反序列化;三是目标端用 WebAPI 的 /v1/product/push,方法 POST,字段值通过 {{FName}} 这类变量引用源端字段,改动一处、所有调用同步生效。

工程上的几个习惯:把编码映射(尤其是新旧编码、内外码)集中放在轻易云的「映射表」里,不要在脚本里写死;表头与表体分阶段上线,先跑物料头信息,稳了再挂扩展属性;增量按主键 + 修改时间双轨,全量用一次性触发,日常调度只跑增量。

实施步骤

分阶段调度是这次能平稳上线的关键,实际跑下来大致分三步:

1. 增量起点确定:首次上线前,在源系统里跑一次全量,把当前所有物料的主键记下来作为「水位线」。轻易云里把 FMasterId 作为增量锚点,首跑之后只拉 FMasterId > 已记录水位 的记录。
2. 全量触发:用轻易云的「一次性全量」任务把历史物料一次性灌到 B 系统,过程中观察失败率与重试次数。全量跑完后,把水位线推到当前最大值,正式进入增量调度。
3. 调度频率:源端 cron 设为 0-59/5 7-20 * * *(每 5 分钟一轮,工作时段运行),目标端 1-59/5 7-20 * * *,两个时间点错开 1 分钟,避免雪崩。非工作时段停跑,降低对源系统压力。

上线前我们还会做一次「空跑」:把目标接口切到 sandbox 或加 dry-run 开关,只读不写,验证字段映射和过滤条件是否符合预期。

踩坑复盘

1. 编码没做集中映射:典型错误是把 FNumber → product_no 直接写在每条策略的脚本里,后来编码规则一变,8 条策略改得人仰马翻。稳妥的做法是在轻易云的映射表里统一维护,所有引用策略只读映射表。
2. 规格型号长度截断:源端规格型号最长 200 字,B 系统接口上限 80 字,直接灌会触发接口报错。这里容易翻车,稳妥的做法是中间层加一个截断 + 省略号规则,并在日志里标记被截断的记录,事后让业务确认是否需要拆分。
3. 数值字段转字符串丢精度:毛重这种 decimal 类型,直接 toString 在某些语言运行时会出现科学计数法,目标系统反序列化就崩了。稳妥的做法是在轻易云的字段转换器里指定小数位数与格式,例如 0.000。
4. 幂等键没选对:早期我们用过 FNumber 做幂等键,但源端允许编码修改,导致同一条主键写了两次新值,旧数据残留。稳妥的做法是用 FMATERIALID(主键)做幂等键,业务编码变更不影响去重。
5. 工作时段外调度:源系统夜间有结账与备份,5 分钟一轮的轮询会和批处理抢资源。稳妥的做法是把 cron 限定在 7-20 时段,夜间让源系统休息。

适用场景与不适用场景

适用:ERP 为主数据源、CRM/电商/WMS 为消费方的物料档案同步;编码规则稳定、字段语义清晰的存量系统对接;需要 5–10 分钟级别准实时的供应链下游系统。

不适用:物料频繁增删改且要求秒级一致的高频场景(应改用事件驱动 + CDC);源端编码规则正在重构或字段语义未对齐的项目;目标系统对主键生成有强约束、不允许外部传入业务编码的接口(需先与业务方对齐主键策略)。