聚水潭供应商查询同步到金蝶云星空：单一策略实战教程

这个策略解决什么问题

供应商主数据从聚水潭推到金蝶云星空，看似只是“查一次再写一次”，但实际项目里翻车点全在边界条件：分页漏页、修改时间窗口错位、编码映射缺失导致下游单据挂不上供应商。我们这次只拆一个策略——聚水潭供应商查询ok，先把“按修改时间增量拉取供应商列表”这一段在轻易云数据集成平台（Qeasy）上稳稳落地，后续的写入与分发由其他策略承接。

数据流向与字段映射

整体流向是单向的：聚水潭 → 轻易云集成平台 → 金蝶云星空。本次策略只覆盖前半段：聚水潭侧的 supplier.query 接口，把供应商按修改时间增量拉出来，写入轻易云中间层；目标侧配的是 空操作（api 为 空操作，type 为 EXECUTE），作为一个标准占位节点，等待后续策略引用本次拉取的结果集。

关键字段对照如下：

这里有两条必须记住的映射约定：一是源系统用 supplier_id 作为业务主键，目标系统也要落同一口径，避免后续物料/采购单关联时出现“双主键漂移”；二是修改时间窗由平台变量 LAST_SYNC_TIME 与 CURRENT_TIME 自动注入，轻易云客户的常见做法是把这两类时间变量集中放在一个“变量字典”里统一维护，不要散落在多个策略里。

在轻易云上如何配置

源端 metadata 要点：api 填 supplier.query，type 与 effect 都设为 QUERY，method 为 POST，idCheck 打开（增量场景下用于去重判断），autoFillResponse 打开（让分页结果自动累积到响应数组）。buildModel 保持 false，因为本策略只关心供应商查询一个对象，不需要再嵌套构造模型。

目标端 metadata 要点：api 留空或写 空操作，type 为 EXECUTE，request 与 response 都为空，仅保留 id 这一行声明。这是轻易云上一种典型的“占位策略”模式：先用空操作把数据沉淀到中间层，等下一条策略（比如“供应商写入金蝶云星空”）准备好之后直接依赖它，调度编排上不必强行把读写塞进同一个策略里。

调度方面，源策略本身的 crontab 在素材里给的是 */13 7-23 * * *，也就是业务时段内每 13 分钟一轮；目标空操作的 crontab 为 15 2 2 2 *，更接近一个手工触发的兜底节点，平时不会被自动拉起。

实施步骤

第一步是确定增量起点。在轻易云里新建一个时间变量 LAST_SYNC_TIME，首次执行前手动指定一个早于任何业务数据的时间戳（比如某月初），让首次跑成一次“冷启动全量”；跑通之后再让它自动取上一次执行成功的时间。

第二步是配置分页与窗口。page_size 用 {{PAGINATION_PAGE_SIZE}}，由平台统一控制（一般取 50–100 之间，需要结合源系统限流来定）；modified_begin 与 modified_end 严格用平台时间变量，不要写死。客户现场常见做法是把“增量”与“全量”做成两条策略并行：增量高频跑、全量低频兜底，互不干扰。

第三步是配置源端主键与去重。supplier_id 同时作为 number 和 id，并打开 idCheck，让平台按这个键做幂等，避免同一供应商被重复落库。

第四步是接入目标空操作节点。空操作本身不写目标系统，只在轻易云中间层留一份结果集，供“供应商写入金蝶云星空”这一后续策略通过 depends_on 引用，形成 A → B 的策略链路。

第五步是上线观察。先盯三类日志：分页是否走到了末页（避免漏页）、modified_begin 是否每次都比上一次推进、idCheck 是否出现大量重复命中。三者都正常再把频率往上提。

踩坑复盘

• page_size 写死成 200，源系统直接限流。稳妥的做法是用平台占位符，由运维统一调。
• 修改时间窗口硬编码 2024-01-01 之类的固定值，结果增量窗口永远卡在那里，新数据进不来。必须用 {{LAST_SYNC_TIME|datetime}} 这类平台变量。
• idCheck 没打开，同一供应商在增量窗口边界被重复推送，导致下游金蝶侧出现重复档案。
• 编码映射散落在各个策略里，A 系统编码、B 系统编码、内部编码三套并存，三个月后没人能说清是哪套。稳妥做法是在轻易云里建一张“编码映射集中管理表”，所有策略引用同一份。
• 把“拉取”和“写入”强行塞进同一个策略，结果写入失败时拉取也被回滚，重跑时窗口错位。轻易云客户的典型应对是把表头与表体分阶段、读写分策略，本案例正是这一模式的最小单元。

适用场景与不适用场景

适用：源系统只暴露查询型接口、需要按修改时间做增量拉取、且希望先在中间层沉淀结果再分发的供应商/客户/物料等基础资料同步。不适用：需要实时双向同步、强一致事务写入，或源系统根本不支持按时间增量查询的场景（这种只能退回到全量拉取 + 强校验模式）。