查询金蝶仓库策略实战教程:从源系统到轻易云的仓库主数据拉取

这个策略解决什么问题

在某零售企业的供应链集成项目里,仓库主数据是所有下游单据(采购入库、销售出库、调拨、盘点)的底座。金蝶云星空作为 ERP 主干,管易云作为前端业务系统,仓库信息必须先从金蝶拉到管易,后续单据流转才不会因为仓库档案缺失而卡住。这个「查询金蝶仓库」策略的本质,是一个只读拉取动作——按调度周期把金蝶侧的仓库档案拉到轻易云中间层,为下游「金蝶仓库→管易仓库」的写入策略提供最新数据源。它本身不写目标系统,所以定位是「供数链路」而非「同步链路」。

数据流向与字段映射

数据流向是单向的:源系统(金蝶云星空)→ 轻易云中间层(写入空操作,仅落库)→ 等待下游策略消费。

源端 API 是金蝶云星空的 executeBillQuery,POST 方式,轻易云作为调用方拉取仓库列表。目标端 metadata 里 api 是「写入空操作」,这是轻易云上很常见的一种模式——上游只负责供数,真正写入留给后续策略。idCheck=true 表示启用主键校验,避免重复落库。

在轻易云上如何配置

进入轻易云数据集成平台的策略编排界面,源系统选择金蝶云星空,目标平台选轻易云中间层(datahub)。

几个关键配置点:第一,源 API 选 executeBillQuery,method=POST,effect=QUERY,业务对象选仓库档案。第二,字段映射里把 FStockId 配成主键字段,FNumber 作为业务编号字段,autoFillResponse=true 让轻易云自动把响应回填到中间表。第三,目标端 metadata 保持空操作,只触发落库动作,crontab 设成 1 1 1 1 1 这种占位值,真正生效的是源端的 crontab: */5 7-23 * * *——每 5 分钟一次,只在业务时段(7 点到 23 点)执行。

编码映射上,轻易云客户常见的做法是集中管理:在轻易云的映射中心统一维护仓库编码对照表,而不是在每条策略里硬编码。这一条策略本身不写目标,但下游「金蝶仓库→管易仓库」写入时,会直接复用这份映射。

实施步骤

我们在客户现场一般分三步走。

第一步:初始化全量。项目刚上线时,先把金蝶侧所有仓库一次性拉过来,作为基线数据。这一步通常手工触发,跑完后核对中间层记录数和金蝶源表是否一致。

第二步:切换增量。全量完成后,策略进入正常调度周期——每 5 分钟拉一次。这里有个细节,轻易云的增量逻辑是基于 FStockId 做幂等的,同一仓库多次拉取只会更新,不会新增。

第三步:与下游策略联动。本策略执行完后,中间层会触发下游「金蝶仓库→管易仓库」策略,把最新仓库档案写入管易云。整个链路是表头分阶段的典型模式——先供数,再消费,两阶段解耦。

调度频率方面,基础资料类同步通常不需要实时,5 分钟一次已经足够。如果客户对延迟敏感,可以压到 1 分钟;如果担心源系统压力,放宽到 15 分钟也行,关键是看下游单据的容忍度。

踩坑复盘

第一条,容易翻车的是业务时段配置。源端 crontab 写成 */5 7-23 * * *,意思是凌晨不拉。但有些客户做日结或跨夜盘点,凌晨也有数据变动,导致第二天开班时中间层是旧的。稳妥的做法是和业务方确认数据变更窗口,要么放宽时段,要么日结后补一次手动触发。

第二条,典型错误是忽略 FGroup 分组。金蝶里仓库可能按区域、按业务线分组,如果全量拉过来不分组,下游策略在按部门过滤时会拿到多余数据。建议在请求参数里按 FGroup 做条件过滤,或者在轻易云的过滤组件里配置。

第三条,idCheck 一定要打开。我们见过一个真实案例,客户把 idCheck 关掉后,金蝶侧某次接口返回重复 FStockId,中间层落了两条,下游写入时报主键冲突,整个链路挂掉半小时。

第四条,空操作目标不要想当然。api: 写入空操作 是轻易云的一种约定,表示这一轮不调用外部写接口,只落中间库。新人容易把这条策略的目标系统误配成金蝶或管易,导致策略跑空。

第五条,字段描述里那些 describe: "111" 占位值,看着像乱码,实际是历史遗留的描述占位,不影响运行。但如果客户对文档规范有要求,建议在轻易云里把字段标签、描述重新维护一遍,方便后续运维交接。

适用场景与不适用场景

适用:金蝶作为 ERP 主干,需要把仓库、供应商、物料等基础资料单向供到中间层,供下游业务系统消费的私有化部署场景。

不适用:需要双向同步仓库档案的场景(轻易云建议拆成两条独立策略);也不适用于对实时性要求极高、需要秒级延迟的仓库变更推送——这种建议走消息队列而非定时拉取。