这个策略解决什么问题在一次实际项目中某零售企业同时使用旺店通·企业版管仓库与电商、金蝶云星辰做财务与供应链总账。两边都各自维护了一份「货品/物料」主数据3 个月后两边数字对不上财务月结卡壳。「查询旺店通货品」这一策略的目的是把旺店通侧的货品主数据按时间窗增量拉到中间层做为后续向金蝶云星辰写入物料的「事实源头」。它本身只做读、不做写是一个典型的QUERY_ONLY单据类策略本质上是给整套主数据同步链路打底。数据流向与字段映射数据流向为「旺店通·企业版 → 轻易云集成平台」。源是业务系统目标平台本身只做暂存与中转真正的写入动作在依赖此策略的后续步骤中完成。下面给出关键字段对照便于理解拉取语义维度源端旺店通·企业版中间层轻易云集成平台备注接口goods_queryPOST写入空操作EXECUTE源端查询、目标端仅接收起始时间start_time{{LAST_SYNC_TIME|datetime}}增量起点截止时间end_time{{CURRENT_TIME|datetime}}当前调度时刻唯一编码goods_nogoods_no货品唯一标识分页大小page_size{{PAGINATION_PAGE_SIZE}}1~100页码page_no{{PAGINATION_START_PAGE}}默认从 0 开始平台 IDplatform_id透传用于多店铺区分需要注意源端的 end_time 在素材里被标注为「店铺唯一编码」一类描述这是平台接口字段含义在素材整理环节混入了不同字段的备注实际配置时以旺店通官方文档为准。在轻易云上如何配置把这条策略在轻易云数据集成平台里落地配置要点分四块数据源注册源平台选「旺店通·企业版」接口选goods_query请求方法 POSTeffect 为 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 做存在性判断即可不要让平台额外校验自增 IDbuildModel设 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并在监控里观察分页循环次数。适用场景与不适用场景适用单仓单店或店铺数量稳定、货品变更频次可控每日新增/修改在万级以下、需要为下游财务/供应链系统提供统一货品主数据源的中小零售与分销企业。不适用多仓且货品跨仓频繁调拨、对货品库存维度有强实时性要求日内多次同步、以及希望直接绕过中间层做「源到目标」直推的极简架构——后者往往在数据量过百万后断点续传与幂等控制会变得难以维护。