【仅查询】金蝶组织信息：从旺店通到金蝶云星空的基础资料探针策略实战

这个策略解决什么问题

在供应链集成项目里，「只查询不写入」的策略往往被低估。某零售企业的集成方案里共 40 余个同步策略，其中有一个看起来很轻量的策略：【仅查询】金蝶组织信息。它本身不往任何系统写数据，但承担了一个关键角色——把金蝶云星空里的组织档案（编码、名称、组织 ID）按调度频率拉回轻易云集成平台，供其他写入策略在做编码映射时实时核对。

我们用轻易云数据集成平台承接这件事，目的不是搬运数据，而是「探针 + 缓存」。一旦组织信息有变动，下游的物料、客户、仓库等同步策略不会因为编码失效而失败。

数据流向与字段映射

该策略的数据流向非常清晰：金蝶云星空作为唯一源系统，通过查询接口把组织档案拉到轻易云集成平台，目标端是「写入空操作」，即数据落到平台自有存储，不向任何下游业务系统推送。

关键字段对照如下：

设计上有个易被忽略的细节：number 字段被显式设为 FNumber，id 字段设为 FOrgID，并且 idCheck=true。这意味着轻易云在拉取时会把 FOrgID 作为幂等键去重，避免分页翻页过程中同一条组织被重复拉到中间层。

在轻易云上如何配置

源端选择「金蝶云星空 · executeBillQuery」WebAPI，请求方式 POST，效果类型 QUERY。目标端选择「轻易云集成平台 · 写入空操作」，效果类型 EXECUTE，这样数据只会落到平台自有的组织缓存表，不污染任何业务库。

配置上有三个要点：

1. 请求体构建：使用金蝶的 executeBillQuery 接口，把分页参数 Limit 与 StartRow 注入到 otherRequest，由轻易云内置分页器自动翻页，直到拉完为止。
2. 响应映射：由于目标是写入空操作，autoFillResponse=true 必须打开，让平台把查询结果按 request 字段顺序自动填到中间表。
3. 调度策略：源端 crontab 是 0 0 * * *（每日零点），目标端 crontab 是 1 1 1 1 1（占位符，不会真正触发）。这种「一端真调度、一端永不调度」是只读探针策略的典型配置套路。

实施步骤

分阶段推进，我们建议按下面节奏走：

第一步：把策略上线到「全量触发」模式。 第一次运行时让轻易云一次性把金蝶云星空里的全量组织档案拉过来，作为基线快照。运行一次后观察中间表行数与源端系统组织总数是否一致。

第二步：切换到「增量 + 定时」模式。 确认全量数据无误后，把策略挂到每日零点调度。由于只查询不写入，增量起点天然就是「最近一次成功拉取的时间戳」，无需复杂的水位管理。

第三步：接入下游策略的依赖关系。 在轻易云的策略编排里，把物料、客户、仓库等写入策略的 depends_on 指向本策略。这样一旦组织信息同步失败，下游策略会自动暂停，避免把无效编码写进金蝶。

第四步：定期对账。 每月做一次抽样对账，确认中间表里的 FNumber 与金蝶云星空的库存组织、行政组织保持一致。

踩坑复盘

坑 1：把「仅查询」当成了「不需要幂等」。 典型错误是直接关掉 idCheck，结果分页边界处同一组织被拉两次，下游做编码映射时出现一对多。这里稳妥的做法是：始终保留 idCheck=true，用 FOrgID 做去重锚。

坑 2：忽略了分页参数的注入位置。 金蝶的 Limit 与 StartRow 属于 otherRequest，而不是 request。有些工程师把它写在主请求体里，结果金蝶接口直接报参数错误。

坑 3：目标端也写了调度表达式。 如果两端都按 0 0 * * * 跑，会让平台误以为是一次完整的「同步」，触发不必要的空写入链路。目标端一定要用占位表达式关掉实际调度。

坑 4：组织档案变更后下游策略没感知。 某制造企业就遇到过：金蝶里改了某个组织的名称，但下游物料策略还在用旧编码。解决办法是把本策略的下游依赖打开，并在轻易云的编码映射里集中管理「编码 → 名称」的对照。

适用场景与不适用场景

适用：作为多策略依赖的基础资料探针；需要实时核对组织编码但不希望产生业务写入；跨系统的组织档案一致性巡检。

不适用：需要把组织信息写回到任何业务系统的场景（应改为标准 SYNC 策略）；组织档案频繁变动且实时性要求在分钟级以内（建议改用实时事件触发而非定时查询）。