查询金蝶云·星空旗舰版销售订单：策略级集成实战教程

这个策略解决什么问题

在一次实际零售企业的集成项目里，CRM 端签完销售订单后，业务和财务需要在 ERP 里即时看到单据状态。我们用轻易云数据集成平台做承接，把「查询金蝶云·星空旗舰版销售订单」单独抽成一个策略，让上游只管推、下游只管取，中间层按节奏轮询拉取，保证两边账目最终一致。

本策略属于查询型（QUERY_ONLY）策略，源是金蝶云·星空旗舰版，中间层落点是轻易云集成平台。

关键字段对照表

维度	源端（金蝶云·星空旗舰版）	中间层（轻易云）	说明
接口	`/kapi/v2/dsg5/sm/sm_salorder/queryadd`	写入空操作	源端 RESTful POST，中间层仅落库
单据编号	`number`（对应 `billno`）	`number`	业务主键
主键 ID	`id`	`id`（idCheck=true）	中间层强校验
分页参数	`pageNo`、`pageSize`	—	源端控制翻页
请求体	`data`（object）	—	业务过滤条件
自动填充	`autoFillResponse=true`	—	减少下游手写映射

注册源平台：在轻易云里把金蝶云·星空旗舰版登记为外部数据源，填入 platform_id 和基础连接信息，私有化环境一般走内网网关。
新建策略，选择「查询」动作：将接口元数据贴入，method 选 POST，effect 选 QUERY，number 字段绑定为 billno。
启用 autoFillResponse：这是金蝶这类接口的常用应对模式，让平台自动把 id、number 等字段回填到响应结构，工程师就不用在脚本里反复声明。
idCheck 关闭源、打开目标：源端 idCheck 设为 false，避免初次同步时被空值卡住；中间层 target 的 idCheck 设为 true，保证落到轻易云的数据必须有 id，便于后续去重。
目标端配「写入空操作」：因为本策略只完成「查询 → 落中间层」，下游消费由后续策略接管，目标端选 EXECUTE 空操作最干净。

在客户现场我们习惯分三阶段推进：

增量起点：先用 data 过滤条件只拉最近变更的订单，确认接口连通、字段对得上。
全量触发：初次上线或补数时，把 pageSize 调大，一次性回填历史单据；轻易云内部会自动按页循环。
调度频率：源端策略的 crontab 设为 */3 7-23 * * *，即营业时段每 3 分钟轮询一次；目标端（中间层落库）设在凌晨 23 2 * * *，集中收口，避免和白天的实时拉取打架。

这种「高频轮询 + 低频落库」的应对模式，能把压力错开，也方便出问题后定位阶段。

autoFillResponse 没开，结果响应体全是空：典型错误是直接照接口文档拼 JSON，没让轻易云自动回填 id、number，导致去重键全为 null。稳妥做法是显式打开 autoFillResponse。
pageSize 写 10 跑全量，跑了一整夜：金蝶接口默认 pageSize=10，全量场景必须调大；不少工程师没注意这里，直接用默认值上线。
idCheck 在源端开着，初次同步被卡死：源端 idCheck=false 是这种新增/初次同步策略的常见配置，目标端反过来要 true。
crontab 写 * * * * *，把源库打满：每分钟都拉，加上翻页没限速，目标库连接池很快被吃光。营业时段 3 分钟一次是经验值。
「查询」和「落中间层」耦合在同一策略里：一旦下游消费出问题，查询也被拖垮。我们坚持把查询单独成策略，下游消费另起一条线，故障半径更小。

适用：私有化部署下的零售或分销企业，需要把销售订单从 ERP 抽到中间层供下游 CRM、BI 或报表消费，对实时性要求在分钟级。不适用：需要强一致事务、秒级实时，或单据体量远超单接口翻页能力的场景，这种情况下应改走消息队列或数据库日志订阅。