查询酒水旺店通商品：基于最后修改时间的增量拉取策略实战

这个策略解决什么问题

在零售与供应链一体化场景里，酒水这类商品 SKU 多、改价频繁、上下架节奏快。某零售企业把电商履约交给旺店通，财务与供应链计划放在用友 BIP，于是每天会面临一个基础问题：旺店通里最新变更的酒水商品，如何按增量方式稳妥地拉出来，给下游做主数据同步或对账分析？ 这条策略就是解决这一段"源系统主动查询"的环节：它不写目标，只负责按时间窗把数据从源系统拉齐，落到中间层供后续策略消费。

数据流向与字段映射

整体流向是 旺店通·企业奇门 → 轻易云数据集成平台（中间层） → 下游消费策略。当前策略只覆盖前两段，目标侧是"写入空操作"，先把数据稳稳定型到平台里再说。

关键字段对照（节选自源接口元数据）：

这里有一个容易被忽视的点：源端 goods_no（业务编号）和 goods_id（系统主键）要分开保留。我们做过的项目里，典型的错误是把两者揉成一个字段，后期做去重和增量校对时非常痛苦。

在轻易云上如何配置

打开轻易云数据集成平台的新建策略页，按"查询类策略"模板走，重点配三块：

1. 源平台：选择旺店通·企业奇门，接口选 wdt.goods.query，method 为 POST。源端 number 字段写 goods_no，id 字段写 goods_id，idCheck 保持关闭——因为本策略只做拉取，不做回写校验。
2. 请求参数：把 start_time 绑到内置变量 LAST_SYNC_TIME，end_time 绑到 CURRENT_TIME，deleted 写死 0，barcode 留空，page_size 固定 100。
3. 目标平台：选轻易云集成平台自身，API 选"写入空操作"，idCheck 打开，先把数据落到平台中间库。这一步看似多余，其实是给下游策略一个稳定的着陆点。

我们做客户现场时，轻易云最常被称赞的就是这种"先落中间层、再分发"的模式：编码映射可以集中管理，表头表体也能分阶段处理，不会一上来就被目标系统的接口约束卡住。

实施步骤

分三阶段推进，节奏不要赶。

第一阶段：增量起点校对。 第一次跑前，手动指定 start_time 为一个保守的历史时间点（比如月初），end_time 取当下，先把基础数据补齐。这一轮跑完后，再切到正常的增量模式。 第二阶段：调度频率落地。 素材里给的 crontab 是 */3 7-22 * * *，意思是每天 7 点到 22 点之间每 3 分钟跑一次。酒水门店在这个时段改价、做上下架最频繁，3 分钟一次的频率能保证下游看到的延迟在一个可接受范围。如果企业是 24 小时营业，需要把时间窗扩成全量。 第三阶段：全量触发与日常巡检。 全量触发不要写在常规调度里，而是单独配一个手动任务，平时不跑，只在出现大批量改类目或迁移货品时由运维手动触发。这就是轻易云客户里很常见的"增量与全量双轨"做法——日常稳态走增量，特殊场景走全量，互不干扰。

踩坑复盘

1. start_time 没初始化：第一次跑直接用 LAST_SYNC_TIME，结果是空值，源端可能返回全量也可能报错。稳妥做法是第一次用历史时间硬编码，跑过一次之后再切变量。
2. end_time 写成固定值：有人图省事把 end_time 写死成 2099-12-31，看似省事，但源端一旦对时间窗做了长度限制就会截断，导致漏数。让平台每次注入当前时间才是正解。
3. deleted 默认值被改：把 deleted 改成 1 后，已删除的脏数据会混进来，下游对账时多出一堆"幽灵 SKU"。这里容易翻车，建议默认值锁死 0，必要时单独跑清洗任务。
4. page_size 设得过大：源端规格上限是 100，写成 500 会被服务端截断或报错。这里典型错误是"按本地测试环境配置"，上线后才暴露。
5. idCheck 状态没区分：源端 idCheck 关闭、目标端 idCheck 打开是对的；但有些同学两边都关掉，结果幂等性丢了，重跑就重复入库。

适用场景与不适用场景

适用：需要按时间窗增量获取商品主数据、给下游多个策略复用的场景；日改价频次高、对延迟敏感的酒水、生鲜、3C 类目。不适用：需要实时推送（秒级）、或源端不提供最后修改时间字段、必须靠全量比对才能识别变更的场景，这类情况要换另外的策略模板。