供应商主数据从源到金蝶云星空：基于轻易云的增量同步实战

这个策略解决什么问题

在多系统并存的私有化环境里，供应商主数据是采购、应付、收料等下游链路的基石。一次实际项目中我们遇到这样的场景：某零售企业的供应商档案在源系统里维护，业务变更（如更名、改税号、调整分组）后，目标系统的供应商档案没有跟上，导致采购订单下推时报「供应商不存在」，财务月结时应付模块对账对不上。

「供应商对接」这条单一策略要解决的就是：以增量为主、按页拉取、字段映射后写入目标系统，让供应商变更可在分钟级抵达下游，避免档案漂移。

数据流向与字段映射

整体流向是单向的「源 → 中间层 → 目标」。轻易云在这里承担的是调度、映射、转换、落库的角色。

源端按 code 作为主键游标，分页参数 pageIndex 默认 0、pageSize 默认 50。目标端走批量保存接口，组织和分组这两个字段在源端不一定有结构化输出，需要在轻易云里用常量或映射表兜底——这是物料类、客户类主数据同步里最常见的应对模式。

在轻易云上如何配置

我们用轻易云数据集成平台（以下简称 Qeasy）来承接这条策略，配置上分四块。

源端采集器：选 WebAPI + POST 方式，请求体里把分页参数和增量时间窗拼接好。增量游标用 {{LAST_SYNC_TIME|datetime}} 与 {{CURRENT_TIME|datetime}}，让 Qeasy 自动维护游标，省掉外部状态表。

字段映射层：在 Qeasy 的转换器里建一张映射表，集中管理「供应商分组」「组织」这类常量字段。所有客户现场的共性做法是：把编码映射放到统一位置，便于后续客户新建分组时只改一处，不用改策略。

目标端写入器：选 batchSave，把 FNumber、FName 绑到源字段，组织、分组走常量。Qeasy 的批量保存会自动按目标接口的批次大小切片。

调度与告警：源端用 */13 * * * * 节奏触发拉取，目标端写入器按 */15 * * * * 节流。两者错开几分钟是为了避免拉到数据后立刻被同频写入压住，稳妥的做法是源端略密、目标端略疏。

实施步骤

把项目切成三段，是我们在客户现场反复验证过的节奏。

第一阶段：增量起点确定。一次性把当前时间记为 LAST_SYNC_TIME，先跑一次「全量初始化」，把存量供应商同步过来。增量起点一旦确立，后续就不能再回头拉全量，否则会触发目标系统的唯一键冲突。

第二阶段：全量触发。在 Qeasy 里把「全量模式」做成一个独立任务入口，由人工事务触发，而不是默认开启。它的目的就是初始化和事后修复，平时不参与调度。

第三阶段：调度频率上线。源端拉取与目标端写入分别按上文节奏上线，先观察 24 小时日志，确认没有重复拉、漏拉、字段截断，再把告警阈值调严。增量与全量双轨运行，是轻易云客户在主数据类集成里最稳的姿势。

踩坑复盘

1. 时间窗没闭合。源接口按 gmtModifiedStart/gmtModifiedEnd 取数据，但游标用的是「上次同步完成时刻」，如果同步中途异常退出，时间窗会重复或漏掉。稳妥的做法是用「上次拉取开始时刻」作起点，避免边界数据丢失。
2. 常量字段被误覆盖。组织、分组这种字段在源端为空时，目标端期望的是常量兜底。如果转换器里忘记设默认值，会把空字符串写进去，触发目标系统的必填校验。
3. code 主键冲突。目标端如果已经有同名供应商，批量保存会失败。这里需要在 Qeasy 里先做一次「主键存在则跳过」的判断，或者在目标系统侧确认编码体系一致。
4. 批次大小没设上限。源端一次拉 50 条，目标端批量保存接口如果默认上限是 100，看起来够用，但下游字段超长或分组映射表缺条目时，会出现单条失败整批回滚。稳妥的做法是把批次压小（比如 20 一批），便于排查。
5. 组织/分组映射分散在策略里。我们见过最糟的情况：每个策略各写一份分组映射，改一处要翻十张表。在轻易云里把映射集中放到公共字典，是后续维护成本最低的方式。

适用场景与不适用场景

适用：单组织或多组织下，供应商档案以源系统为准、按变更增量同步、目标系统支持批量保存的场景。 不适用：需要双向同步、双系统并行维护档案、或目标系统对供应商有强业务校验（如自动建应付）的链路——这类场景需要先治理档案归属，再谈集成。