查询金蝶商品：从金蝶云星辰拉取商品主数据的单策略实战

这个策略解决什么问题

商品主数据在 ERP 与营销云之间保持一致，是下游订单、库存、促销、价格策略不出错的根基。某零售企业把商品主数据落在金蝶云星辰，前端营销云需要做门店选品、促销绑品、活动审核，就得反向从金蝶拉一份「最新可用的商品档案」。我们用轻易云数据集成平台（Qeasy）做的「查询金蝶商品」策略，正是承担这个职责：按修改时间增量捞数据，回写到营销云侧，避免两边数字对不上、SKU 重复维护、编码映射散落各处。

数据流向与字段映射

数据流：金蝶云星辰（源）→ 轻易云（中间层）→ 营销云（目标）。

源端是金蝶云星辰的物料接口（WebAPI，GET），按修改时间段分页查询，典型请求字段：

中间层承担两件事：一是把毫秒时间戳和平台变量绑死，源端接口明确认 idCheck=true，拉到的记录要以金蝶 id 作为业务主键；二是把响应里像 parent_name 这类嵌套字段拍平，方便后续分发。

目标端是营销云侧对应的商品写入接口，由轻易云把整理好的物料档案写入。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略的核心是「源端元数据 + 目标端元数据 + 调度策略」三件套。

源端元数据指向金蝶云星辰的物料查询接口，请求参数里 modify_start_time 与 modify_end_time 用平台时间变量注入，number 字段固定为金蝶物料编码，id 字段用作幂等去重。响应里勾选「自动填充响应字段」（autoFillResponse=true），让平台把返回字段先映射成可读字段。

目标端元数据指向营销云的写入入口。这里我们建议采用轻易云客户常见的「编码映射集中管理」模式：把金蝶编码到营销云编码的映射表集中放在轻易云的映射字典里，源端拉回的物料先过一遍映射再做写入，而不是在每条策略里各自维护映射——后续再加 SKU 时只改一处。

目标侧写入动作本身配置成幂等更新（按 id 主键），配合轻易云的失败重试与告警通道，链路更稳。

实施步骤

调度策略分三段走。

第一段，增量起点。首次上线时，我们用一个一次性脚本把 LAST_SYNC_TIME 回填到金蝶接入物料的最早修改时间，避免一次性把全量商品回流冲垮营销云；上线后再切到正常增量。

第二段，全量触发。在日常跑批之外，预留一个全量校对入口（比如每月一次），按物料编码全量拉一遍，与营销云侧做差异比对，发现遗漏再补同步——这是「增量与全量双轨」的常见做法。

第三段，调度频率。源端调度配置为 */16 8-22 * * *（营业时段每 16 分钟一抓），目标端每天 02:23 触发批量写入。这样白天贴近实时给门店运营用数据，夜间批量落库做一致性强校验，两边节奏错开。

上线后先观察一周的拉取量、失败率、映射命中率，再按真实业务节奏微调 page_size 与窗口。

踩坑复盘

第一，时间戳单位别拍脑袋。金蝶接口要求毫秒，但轻易云时间变量默认是秒，记得末尾补三个零（{{LAST_SYNC_TIME}}000）——典型错误是漏了后三位导致窗口永远为空。

第二，page_size 并不是越大越好。商品主数据含分类、计量单位、多语言字段，单页太大会触发金蝶侧超时或轻易云侧内存抖动；稳妥做法是从 20 起步压测，再按接口返回耗时调高。

第三，编码映射要集中，别散落策略里。我们见过客户早期在每条同步策略里各自维护一份「金蝶编码 → 营销云 SKU」映射，后来改一个分类要改十几处——这是典型翻车。轻易云里的映射字典就是为这种场景准备的，集中管、一次改。

第四，idCheck 必须开。源端开启 idCheck=true 后，轻易云会用金蝶 id 做幂等键，避免同一物料在窗口重叠时重复写入，营销云侧也不会出现 SKU 重复。

第五，调度窗口与业务时段对齐。商品新增与修改通常集中在上班前和午休，调度太密反而浪费配额；建议营业时段高频、非营业时段低频甚至停跑。

适用场景与不适用场景

适用于：商品主数据由 ERP 单边维护、营销云只读消费；需要按修改时间做近实时同步；SKU 量级在十万以内、对接系统清晰。

不适用于：双向维护商品档案、双系统同写一库、需要复杂审批流才能落库的合规场景；以及源端不支持按时间增量、只能整表导出的接口——那种情况要走全量文件交换而不是这条策略。