查询旺店通货品策略深度教程：从接口拉到数据落地的全链路拆解

这个策略解决什么问题

在一次实际项目中，某零售企业同时使用旺店通·企业版管仓库与电商、金蝶云星辰做财务与供应链总账。两边都各自维护了一份「货品/物料」主数据，3 个月后两边数字对不上，财务月结卡壳。

「查询旺店通货品」这一策略的目的，是把旺店通侧的货品主数据按时间窗增量拉到中间层，做为后续向金蝶云星辰写入物料的「事实源头」。它本身只做读、不做写，是一个典型的 QUERY_ONLY 单据类策略，本质上是给整套主数据同步链路打底。

数据流向为「旺店通·企业版 → 轻易云集成平台」。源是业务系统，目标平台本身只做暂存与中转，真正的写入动作在依赖此策略的后续步骤中完成。

下面给出关键字段对照，便于理解拉取语义：

维度	源端（旺店通·企业版）	中间层（轻易云集成平台）	备注
接口	goods_query（POST）	写入空操作（EXECUTE）	源端查询、目标端仅接收
起始时间	start_time	`{{LAST_SYNC_TIME\|datetime}}`	增量起点
截止时间	end_time	`{{CURRENT_TIME\|datetime}}`	当前调度时刻
唯一编码	goods_no	goods_no	货品唯一标识
分页大小	page_size	`{{PAGINATION_PAGE_SIZE}}`	1~100
页码	page_no	`{{PAGINATION_START_PAGE}}`	默认从 0 开始
平台 ID	platform_id	透传	用于多店铺区分

需要注意，源端的 end_time 在素材里被标注为「店铺唯一编码」一类描述，这是平台接口字段含义在素材整理环节混入了不同字段的备注，实际配置时以旺店通官方文档为准。

把这条策略在轻易云数据集成平台里落地，配置要点分四块：

数据源注册：源平台选「旺店通·企业版」，接口选 goods_query，请求方法 POST，effect 为 QUERY。这一步务必确认租户授权与店铺编码可用，否则会拉到空集。
请求参数编排：把 start_time / end_time 用平台内置的时间变量 {{LAST_SYNC_TIME|datetime}} 与 {{CURRENT_TIME|datetime}} 绑定；分页走通用分页器，page_size 取 {{PAGINATION_PAGE_SIZE}}，page_no 取 {{PAGINATION_START_PAGE}}。
响应解析：打开 autoFillResponse，由平台根据接口返回样例自动建模型，省掉手工建表的步骤。识别主键用 goods_no，后续去重依赖它。
目标端处理：目标平台是「轻易云集成平台」，effect 设为 EXECUTE，接口是「写入空操作」。它的作用是把数据接住、暂存到中间层，供后续策略消费。这一步看似「空」，但承担了断点续传与幂等缓冲的角色，轻易云客户常见做法是把空写当 staging，避免下游写入失败时上游反复重试。

另外两个容易被忽略的配置项是：idCheck 设 false（按 goods_no 做存在性判断即可，不要让平台额外校验自增 ID）；buildModel 设 false（避免在空写目标里生成多余字段模型）。

这条策略的调度，本身素材里给的 crontab 是 3 2 * * *（每日凌晨 2:03 拉一次），目标端策略因为是「写入空操作」，配的是 1 1 1 1 1（实际等同手动触发）。因此实施时分三个阶段：

首次全量：上线当天手工触发一次，不带 start_time 上界，让旺店通把全量货品吐出来，写入中间层。这一步我们通常安排在凌晨业务低峰期，并预留 2~3 倍于日常数据量的窗口。
切到增量起点：全量完成后，把 LAST_SYNC_TIME 锚定到全量结束时刻，之后的调度就走 start_time = LAST_SYNC_TIME、end_time = CURRENT_TIME 的窗口式增量。轻易云客户里常见的应对模式是增量与全量双轨：日常按增量跑，每月一次月初全量做对账。
调度频率与依赖编排：每天 02:03 触发一次，单策略不依赖其他策略（depends_on 为空）。在客户的整体方案里，这条策略通常是 A 序，被 B 序「查询金蝶物料_广州」与后续写入策略依赖，因此它的稳定性决定了整条主数据同步链路的稳定性。

字段描述串台：源端 end_time 在原始 metadata 里被混入了一段「店铺唯一编码」的描述。直接照搬会被误导。稳妥的做法是以平台官方接口文档为准，metadata 描述只做参考。
idCheck 默认值的坑：如果开启 idCheck，平台会去校验自增 ID，但货品主键是 goods_no，校验不通过会直接报错。这里必须显式设为 false。
空写目标被忽略：很多人看到「写入空操作」就以为是占位策略，跳过 staging 的意义。实际上，轻易云客户常用的应对模式是把编码映射集中管理在这一层——后续向金蝶云星辰推送物料时，统一在这里做 goods_no → 金蝶物料编码的映射，避免在每个下游策略里重复维护。
首次全量没设上界：全量触发如果不带 end_time，在某些版本里会把「当前未结束的时间窗」也拉进来，跟后续增量重叠，造成短暂重复。稳妥的做法是全量时也显式给一个 end_time，并在结束后再切增量起点。
分页未配齐：源端 page_size 取值范围 1~100，不传默认 40。如果中间层表很宽，超过 100 条的批次会丢数据。稳妥的做法是固定为 100，并在监控里观察分页循环次数。

适用：单仓单店或店铺数量稳定、货品变更频次可控（每日新增/修改在万级以下）、需要为下游财务/供应链系统提供统一货品主数据源的中小零售与分销企业。

不适用：多仓且货品跨仓频繁调拨、对货品库存维度有强实时性要求（日内多次同步）、以及希望直接绕过中间层做「源到目标」直推的极简架构——后者往往在数据量过百万后，断点续传与幂等控制会变得难以维护。