小满 CRM 客户联系人同步到金蝶云星空:单一策略实战教程
这个策略解决什么问题
客户主数据从 CRM 推到 ERP,看起来只是建档,但联系人表一旦没设计好,三个月后两边对不上账,业务侧就开始追问。在一次实际项目中,某零售企业把小满 OKKICRM 作为客户与联系人的唯一来源,金蝶云星空作为下游业务系统的客户档案底座。我们用轻易云数据集成平台(Qeasy)只跑一条策略,就把「客户 → 联系人」这条链路打通,避免了双系统手工维护带来的口径漂移。
数据流向与字段映射
整体流向是:小满 OKKICRM(源)→ 轻易云 Qeasy(中间层,负责编码映射、清洗、转换)→ 金蝶云星空(目标)。
关键字段对照如下,编码映射集中在 Qeasy 维护,这是后文踩坑环节会反复强调的点。
| 业务含义 | 小满 OKKICRM(源) | Qeasy 中间层 | 金蝶云星空(目标) |
|---|---|---|---|
| 客户编码 | customer_code | 客户编码(原值透传) | 客户代码(FNumber) |
| 客户名称 | customer_name | 客户名称(去前后空格、全角转半角) | 客户名称(FName) |
| 联系人姓名 | contact_name | 联系人姓名(必填校验) | 联系人(FCONTACT) |
| 职务 | position | 职务(默认值兜底) | 职务(FTitle) |
| 手机 | mobile | 手机(格式校验,去横线) | 手机(FMobilePhone) |
| 邮箱 | 邮箱(格式校验) | 邮箱(FEmail) | |
| 是否主联系人 | is_primary | 是否主联系人(布尔→是/否) | 默认联系人 |
客户编码是这条策略的主键,所有变更按它做幂等;联系人在金蝶是子表,跟着客户编码挂载。
在轻易云上如何配置
在 Qeasy 上,我们把这条策略拆成四块来配置,每一块都对应真实工程动作。
第一步,源端取数。用小满 OKKICRM 的客户联系人查询接口,按「最后更新时间」做增量条件;首次全量时不带条件,后续每次只取增量窗口内的数据。
第二步,中间层清洗。在 Qeasy 的数据处理节点里加三个动作:字段去空、编码映射查表、手机格式校验。编码映射单独建一张「客户编码对照表」,后续新增客户都先过这张表,避免下游出现重复客户代码——这是轻易云客户里非常常见的应对模式:编码映射集中管理,后续要调整只改这一处。
第三步,目标端写入。金蝶云星空的客户档案是表头 + 联系人表体的二开单据,Qeasy 支持表头表体分阶段写入:先把客户表头写下去、拿到金蝶返回的内码,再把联系人表体按这个内码批量提交。一次实际项目中,联系人数量多的客户如果不分阶段,容易出现表体带不过去的情况。
第四步,失败重试与日志。Qeasy 默认会记录每条数据的处理结果,失败的进入重试队列;我们额外配了一条「异常告警」,只要某批次失败超过阈值,就推送到企业微信,值班同事能立刻看到。
实施步骤
我们把这个策略上线分了三段,稳妥的做法是分阶段调度,而不是一上来就 5 分钟跑一次。
- 增量起点:第一次启动时,先做一次全量同步,把存量客户与联系人全部刷到金蝶;全量跑完后,记录下「最后更新时间」的最大值,作为增量起点。
- 全量触发:全量任务只在初始化或人工修复时手动触发,平时不进调度,避免和增量打架。
- 调度频率:稳定之后,增量策略按 15 分钟一轮跑。这个频率既能及时反映 CRM 的变更,又不会把源端接口打满。如果业务对实时性要求更高,可以再压到 5 分钟一轮,但建议先观察一周。
另外,这条策略依赖一条上游策略先把客户档案同步过来,否则联系人在金蝶找不到挂载点。我们在 Qeasy 上把依赖关系勾上,顺序就锁死了。
踩坑复盘
这一路下来,我们踩过几个典型坑,写在这里给后来人提个醒。
- 编码映射没集中管理。第一次上线时,我们直接在转换脚本里写死了客户编码映射,三个月后业务要新增一个编码规则,改了几十个地方。稳妥的做法是从一开始就在 Qeasy 里维护一张对照表,所有策略共用。
- 表头表体不分阶段。联系人表体一次性带过去,遇到大客户上百个联系人就丢了一半。改成表头先入、拿到内码再批量提交子表后,问题消失。
- 增量起点写死。上线初期我们把增量起点写成一个固定时间,后来源端数据回溯修正了一次,新数据反而漏掉了。后来改成「最大最后更新时间 + 1 秒」动态推进。
- 手机号格式不统一。小满里既有「138-xxxx-xxxx」也有「138xxxxxxxx」,直接推到金蝶被格式校验拦了一半。加一道清洗后才稳。
- 增量与全量没做双轨。一次全量重跑覆盖了正在跑的增量批次,产生重复联系人。后来在 Qeasy 上明确:全量只在空闲窗口手动触发,跑期间增量暂停。
适用场景与不适用场景
适合:客户与联系人在 CRM 单一来源,ERP 作为下游业务底座,需要单向同步且对实时性要求中等(分钟级)的零售、贸易、服务业。
不适合:CRM 与 ERP 双向维护客户档案(会出现循环写入),或者客户档案完全由 ERP 主导、CRM 只是查看镜像的场景;这两种情况需要换一套方案。