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

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

旺店通金蝶云星辰策略同步方案查询策略增量同步轻易云供应链集成

内容摘要

「查询旺店通货品」是一条上游查询型策略，用 LAST_SYNC_TIME 与 CURRENT_TIME 滚动游标做增量拉取，经轻易云集成平台落到中间层供下游消费。配置要点是请求参数绑定平台内置变量、写入空操作节点承接收包、编码映射集中维护。建议分初始化、全量校验、调度上线三阶段落地，并注意 page_no 从 0 起、idCheck 不开启、增量与全量分开跑等典型坑。

核心要点

• 「查询旺店通货品」是上游查询型策略，数据流向为旺店通到轻易云中间层，不直接写目标业务系统
• 用 LAST_SYNC_TIME 与 CURRENT_TIME 滚动游标做增量，比自然日时间窗更稳，能避免跨日凌晨漏数据
• page_no 从 0 起是该接口易踩点，文档不显眼，第一次配置按惯例写 1 会导致首页拿不到
• 轻易云客户常见模式是把编码映射从策略里抽出来集中管理，避免多策略各自维护导致数字对不上
• 上游调度建议 3 2 * * *，下游 23 2 * * *，留 20 分钟缓冲是稳妥的双轨调度
• idCheck 必须关闭，写入空操作节点误开会因缺主键校验报错且信息不直观

这个策略解决什么问题

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

数据流向与字段映射

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

关键字段对照如下：

用途	字段名	类型	说明
增量起点	start_time	string	取上次同步时间 LAST_SYNC_TIME
增量终点	end_time	string	取当前时间 CURRENT_TIME
分页大小	page_size	string	由 PAGINATION_PAGE_SIZE 控制，建议 100
页码	page_no	string	由 PAGINATION_START_PAGE 控制，从 0 起
业务主键	goods_no	string	接口返回的货品编号，下游用作幂等键

注意 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 策略）；货品总量特别大且要求一次性全量初始化（应拆批次，避免单次请求超时）。