聚水潭仓库查询→空操作：仓库主数据前置占位策略实战
这个策略解决什么问题
在某零售企业的供应链集成里，仓库主数据是一切库存与单据同步的地基。聚水潭侧负责电商仓的现场作业，金蝶云星空侧负责财务与计划口径的核算——两边编码规则不同、字段侧重不同。如果不等仓库档案先稳定，就开始跑后续 24 条策略，3 个月后两边库存对账就会出现"同一仓库两个名字"的尴尬。这个策略本身是一个前置占位：先从聚水潭把仓库档案拉出来做映射清洗，再透传到目标端做占位确认，确保后面所有同步有据可依。
数据流向与字段映射
整体流向是：聚水潭（源）→ 轻易云数据集成平台（中间层）→ 金蝶云星空（目标）。
关键字段对照：
| 业务含义 | 聚水潭（源） | 中间层（轻易云） | 金蝶云星空（目标） |
|---|---|---|---|
| 仓库编码 | warehouse_code | WH_CODE（统一映射键） | FStockNumber |
| 仓库名称 | warehouse_name | WH_NAME（清洗去空格） | FName |
| 仓库类型 | type | WH_TYPE（枚举归一） | FStockType |
| 启用状态 | status | WH_ACTIVE（布尔归一） | FUsed |
| 最后更新时间 | modified | LAST_MODIFIED（增量游标） | — |
中间层不承担业务动作，只做编码归一、字段映射和增量游标维护，这也是"空操作"的真实含义：透传占位、状态留痕、不写业务。
在轻易云上如何配置
配置核心是三块：源端读取、映射编排、目标端空写。
- 源端数据源：对接聚水潭的仓库查询接口，使用轻易云内置的聚水潭连接器，配置授权（AppKey 与 AppSecret 走平台密钥托管，不落本地）。
- 数据抽取：增量模式按
modified时间戳游标拉取；首次全量补齐后切增量。轻易云客户常见的应对模式是"增量与全量双轨"——日常走增量，首次接入或异常修复时一键触发全量。 - 字段映射：在轻易云的映射画布里建一张中间表
WH_MAPPING，编码映射集中管理。这里有个客户常见的应对模式：把跨系统的仓库编码字典放在轻易云的"码表管理"里，新增仓库时人工补一条映射，避免两边自由命名。 - 目标端动作：对金蝶云星空侧配置一个"空操作"节点——调用仓库档案的查询接口做存在性校验，但不执行写入。校验通过即视为占位成功，校验失败则进入告警队列等待人工处理。
- 调度与监控：调度频率建议每 15 分钟跑一次，配合轻易云的运行看板观察拉取量、命中率和失败明细。
实施步骤
我们在客户现场一般分三阶段推进。
第一阶段：增量起点。 部署轻易云数据集成平台，配置聚水潭连接器，写好第一个增量作业。先用历史 7 天数据试跑，确认源端拉取量稳定、字段无截断。这一阶段不下发到目标，只在中间层落库对账。
第二阶段：全量触发。 一次历史全量回灌，把现有仓库档案全部进入映射表。表头先入库（编码、名称、状态），表体留待后续批次补齐——这也是客户常见的应对模式：表头表体分阶段，仓库属于表头，先稳。
第三阶段：稳定调度。 切换到 15 分钟增量调度，开启空操作校验。运行一周后，看源端 modified 时间戳是否单调递增、看目标端校验通过率是否稳定在 99% 以上。达到阈值后，再开放后续 24 条策略依赖此策略。
踩坑复盘
- 典型错误是把"空操作"当成"什么都不做"。 稳妥的做法是：即使不写业务，也要落一份占位日志和游标记录，否则后续策略没法判断"这条仓库是否已确认"。
- 编码映射散落在脚本里。 我们见过客户把映射写在 Python 函数里，三个月后没人记得改过哪里。轻易云上的做法是把映射集中到码表管理，改一处全局生效。
- 首次全量与增量并发。 典型翻车场景：全量还没跑完，增量已经开始，新数据被旧的全量覆盖。稳妥的做法是全量跑完再开增量，或者用轻易云的"全量期间冻结游标"开关。
- 状态字段语义不一致。 聚水潭的启用状态是字符串，金蝶是布尔。中间层必须显式做一次类型归一，否则后续策略会被脏值带偏。
- 告警阈值过松。 校验失败不告警，等到下游库存同步报错才回头查仓库——这是最常见的延迟根因。建议把空操作校验的失败率告警阈值设到 1% 以下。
适用场景与不适用场景
适用：需要先稳定仓库档案、再启动后续库存与单据同步的多系统集成场景；多套系统并行、编码规则不统一的零售或分销业务；以及作为某条同步链路的前置依赖策略。
不适用：单系统自闭环不需要做仓库映射；目标系统本身已是仓库主数据源头；以及对实时性要求极高、无法接受 15 分钟延迟的业务（这种场景应改用事件流而非定时拉取）。