供应商主数据查询同步：聚水潭与金蝶云星空之间的「仅查询」策略实战

这个策略解决什么问题

某零售企业把金蝶云星空作为后台 ERP，把聚水潭作为门店与电商前端系统。供应商主数据长期以金蝶为唯一真源，聚水潭侧只在采购下单时按编号反查。为了让「供应商名称、创建组织、使用组织、描述」等基础字段在两个系统间始终一致，他们需要一个只读查询通道：定时从金蝶拉一份最新的供应商列表到中间层，供后续策略复用，而不是直接把数据写回聚水潭。这就是「【仅查询】金蝶供应商信息」这条策略的定位——它是供应链集成方案里最基础、最稳的一张底图。

数据流向与字段映射

整条链路是单向读取：源系统金蝶云星空 → 中间层轻易云数据集成平台 → 目标端「写入空操作」。所谓「写入空操作」不是 bug，而是有意为之：轻易云在目标端挂一个空写接口，确保调度器能正常闭环，同时把数据留在中间层供后续策略消费。

关键字段对照（源系统 → 中间层）：

金蝶侧使用 executeBillQuery 这个 WebAPI 做表单查询，传参为组织与过滤条件，返回结构化供应商列表。轻易云这边按上述字段做一次透传，不做改写。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略配起来非常轻，核心三步：

1. 源系统连接：选金蝶云星空作为来源系统，填入 API 网关地址与授权信息（账号、密钥等敏感信息在此脱敏）。api 选 executeBillQuery，method 为 POST，effect 标记为 QUERY。
2. 字段勾选：把 FSupplierId、FNumber、FName、FCreateOrgId_FNumber、FUseOrgId_FNumber、FDescription 全部勾出来作为返回字段。number 与 id 都指向 FNumber，开启 idCheck，避免重复拉取。
3. 目标端配置：选轻易云内置的「写入空操作」作为目标 palatom，effect 标 EXECUTE，request 与 response 都留空。这样调度器跑完一轮就有完整的「成功」信号，方便看板统计。

我们见过不少客户在这一步直接把查询结果往聚水潭写，结果发现供应商编码命名规则不一致，造成下游采购单匹配失败。稳妥的做法是先只查询、留中间层，把编码映射集中管理，再决定是否回写。

实施步骤

把上线过程拆成三个阶段，节奏才稳：

• 阶段一：增量起点。首次运行前，先在金蝶里确认一张「供应商最后修改时间」基准表，轻易云按 FSupplierId 升序拉第一轮全量，作为后续增量的起点。
• 阶段二：全量触发。把 crontab 临时调成 0 0 1 1 1（每月 1 号凌晨）跑一次全量校验，确认中间层与金蝶行数一致、关键字段无空值。
• 阶段三：调度频率。正式上线后改为 5-59/30 7-23 * * *，即每天 7 点到 23 点每 30 分钟一次，业务高峰期保持近实时，离线时段不打扰数据库。

目标端那条 1 1 1 1 1 的 crontab 实际上不生效，因为是空写接口，这里仅作为占位。

踩坑复盘

1. 「仅查询」被误改成写入。客户现场最容易翻车的点，是二开同事看到「目标为空操作」就以为没配好，手动改成往聚水潭推供应商。结果聚水潭侧出现重复档案，3 个月后两边数字对不上。典型错误是低估了「中间层缓存」的价值。
2. 必填字段漏传。FCreateOrgId_FNumber 与 FUseOrgId_FNumber 是金蝶必填，如果查询条件里不带组织，金蝶会直接返回空集。建议在轻易云的请求参数里固定带上默认组织号。
3. 编号体系混淆。金蝶的 FNumber 与聚水潭的供应商简码并不一致，做表头表体分阶段同步时，编码映射一定要集中维护，不要散落在多个策略里。
4. 高峰期压库。每 30 分钟一次查询在数据量 5 万以内没问题，超过这个量级要加上分页参数或按组织拆分，否则会拖慢金蝶前台。
5. 空写接口的日志误导。目标端「写入空操作」成功后日志显示「成功」，但实际没写任何东西。运维同学第一次看到这个日志会怀疑人生，建议在策略描述里明确标注「QUERY ONLY」。

适用场景与不适用场景

适用：金蝶作为供应商主数据唯一真源，聚水潭或其他前端系统需要按编号反查、或者后续策略需要消费这份快照。不适用：需要把供应商信息实时回写前端、或两端都需要独立维护供应商档案的双主模式——那种场景请直接走「供应商主数据双向同步」策略，而不是「仅查询」。