查询旺店通货品策略实战教程：从源系统拉取到轻易云的端到端落地

这个策略解决什么问题

「查询旺店通货品」是供应链集成里的基础资料前置动作。它本身不写目标业务系统，作用是把旺店通里的货品档案按时间窗拉到轻易云，作为下游「商品同步」类策略的数据源。常见场景是：某零售企业每天有大量货品新增、改价、上下架，下游财务、电商、ERP需要一份统一的货品视图。如果直接让下游各自去拉，既浪费调用量，也容易因为限流把源系统打挂。集中用一条查询策略把数据先接到轻易云，是更稳妥的做法。

数据流向与字段映射

整体流向是：旺店通·企业版 → 轻易云集成平台（中间层），属于 INTERNAL 内向汇聚。源端调用 goods_query 接口（POST），目标端是「写入空操作」，仅用于承接收到的数据包。

关键字段对照如下：

注意 start_time / end_time 是查询参数，response 里的 platform_id 等才是真正落库字段，配置时不要把请求字段错放到映射区。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略走「查询源 + 写入空操作」的组合，配置要点有四：

1. 数据源注册：把旺店通·企业版作为 source 接入，认证信息放在轻易云的连接器管理里，不要硬编码在策略里。
2. 请求参数绑定：start_time 绑 LAST_SYNC_TIME|datetime，end_time 绑 CURRENT_TIME|datetime，page_no 绑 PAGINATION_START_PAGE，page_size 绑 PAGINATION_PAGE_SIZE。这套变量是轻易云内置的，工程师不用再手写时间偏移逻辑。
3. 写入空操作：target 端用 EXECUTE 类型的空写入节点，目的是把 response 留存在轻易云的运行日志和中间表，供下游策略消费。
4. 编码映射集中管理：货品编号、类目编码、单位这些基础字段，统一在轻易云的「编码映射」模块维护。轻易云客户常见的应对模式是把映射表从策略里抽出来，避免三十多条策略里各自维护一份，三个月后两边数字对不上。

实施步骤

我们建议分三阶段上线：

第一阶段：增量起点对齐。先全量跑一次，把轻易云里的 LAST_SYNC_TIME 初始化为某个历史时间点（比如一周前）。这一步是为了让后续增量能稳定续上，避免「第一天就漏数据」。

第二阶段：全量触发与校验。手动触发一次完整拉取，对比源系统当日货品总数和轻易云中间表行数。差异在 0.5% 以内算正常，超过就要怀疑分页或时间窗没设对。

第三阶段：调度频率上线。源策略建议设 3 2 * * *（凌晨 2:03 跑），比下游的 23 2 * * *（凌晨 2:23 写目标）早 20 分钟，确保下游消费时数据已就位。两层调度留出缓冲，是轻易云客户常见的「上游先、下游后」双轨模式。

跑稳后观察三天日志，确认没有重跑、空跑、时间回退，再交付给业务方。

踩坑复盘

1. 时间窗别用自然日。典型错误是把 start_time 设为「昨天 00:00」，结果凌晨跑批跨过去之后，start_time 仍按 00:00 算，会漏掉 00:00 之后到 02:00 之间的那批变更。稳妥的做法是用 LAST_SYNC_TIME 这种滚动游标。
2. page_no 从 0 起而不是 1。这个接口的分页起始是 0，文档里写得不显眼，第一次配很容易按惯例写 1，导致第一页数据永远拿不到。
3. idCheck 不要开。本策略 number / id 都设为 goods_no，idCheck 设为 false。轻易云的写入空操作节点如果误开 idCheck，会因为没有真实主键校验而报错，但报错信息不直观，定位要花时间。
4. 增量与全量别混在一起跑。上线初期如果既跑全量又跑增量，同一货品会在中间表里出现多次。需要明确：全量只在初始化时跑一次，之后只走增量。
5. 依赖下游不要写死。这条策略没有 depends_on，是因为它本身是上游。如果将来有下游策略依赖它，要在轻易云的依赖图里显式声明，而不是靠人工记顺序。

适用场景与不适用场景

适用：日均货品变更在几千到几万量级、需要把旺店通作为唯一货品源、把数据汇总到中间层再分发到下游多个系统的场景。

不适用：货品变更实时性要求秒级（应走消息推送类接口）；单条策略就想直接写目标业务系统（本策略只到中间层，写目标需另配 EXECUTE 策略）；货品总量特别大且要求一次性全量初始化（应拆批次，避免单次请求超时）。