查询销帮帮产品分类并落入轻易云集成平台：单策略同步实战教程
这个策略解决什么问题
在零售与分销一体化的场景里，产品分类是后续商品同步、库存口径、销售统计的「地基」。一次实际项目中，某零售企业同时使用聚水潭管商品、用销帮帮管产品主数据与销售流程。最早他们让两边各自维护一份分类表，结果三个月后做品类分析时发现两边数字对不上——同一个「夏季连衣裙」在两边属于不同层级、不同名称。本策略的目标很简单：把销帮帮侧的分类作为唯一可信源，定时拉取并沉淀到轻易云数据集成平台，作为后续聚水潭商品映射和销帮帮自身业务单据的字典底座。
数据流向与字段映射
整体流向是「销帮帮 → 轻易云集成平台」。销帮帮侧通过 POST /pro/v2/api/product/categoryList 拉取分类列表，轻易云侧则以「写入空操作」的 WebAPI 占位承接，后续由同平台下游策略消费这份分类字典。
关键字段对照如下：
| 语义 | 销帮帮源字段 | 类型 | 轻易云承接字段 | 说明 |
|---|---|---|---|---|
| 分类唯一编码 | id | string | category_id | 作为下游编码映射的 key |
| 分类名称 | name | string | category_name | 用于前端展示与匹配 |
| 父分类编码 | parentId | string | parent_category_id | 用来还原树形层级 |
| 排序号 | sort | number | sort_no | 控制层级展示顺序 |
| 启用状态 | enable | number | status | 0 停用 / 1 启用 |
| 公司 ID | corpid | string | corp_id | 租户隔离字段 |
| 启用序列号 | enableSerialNumber | string | serial_flag | 标识该分类下商品是否启用序列号管理 |
| 同步时间戳 | 由轻易云自动生成 | datetime | sync_time | 增量起点判断依据 |
这里要注意，销帮帮源端启用了 autoFillResponse，响应里 corpid、enableSerialNumber 等字段会以 _autoFillResponse 自动补齐，工程师只需要在轻易云里把它们标记为「由源端自动填充」，不要手工再传一遍。
在轻易云上如何配置
我们在客户现场通常按三步走：
第一步：注册源端连接器。 在轻易云集成平台的「系统对接」里，把销帮帮作为外部业务系统接入，记下 platform_id，并配置鉴权信息（公司 ID 与 userId）。这一对凭证要进凭证库统一管理，不要散落在策略里。
第二步：配置 QUERY_ONLY 策略。 把源端的元数据 JSON 导入策略编辑器，轻易云会自动识别出 request 里的 corpid、userId 和 otherRequest 里的 StrategyId。StrategyId 在查询场景下一般为空，但保留字段方便后续在策略中心做反查与排障。
第三步：配置目标端「写入空操作」。 目标端是轻易云集成平台自身的「写入空操作」WebAPI，effect 是 EXECUTE，method 是 POST，request 和 response 都为空。它的作用是给调度器一个明确的「落点」，让分类数据进入平台内部的主题表（topic）供其他策略订阅。这样编码映射可以集中管理，避免散落在多个目标系统里。
实施步骤
我们建议按三个阶段推进，避免一次性上线把脏数据带进生产：
阶段一：增量起点准备。 先在轻易云里建一张分类字典表，把历史分类一次性全量初始化进去。这里采用「全量双轨」的做法：跑一次全量任务，把 sync_time 统一打上同一时间戳，作为后续增量比对的起点。
阶段二：调度策略上线。 源端 crontab 是 3 2 * * *，也就是每天凌晨 2:03 触发一次。建议轻易云侧的调度时间错开 1 分钟，比如设为 4 2 * * *，给源端系统留出缓冲。目标端的 crontab 写作 1 1 1 1 1，这是轻易云的「空跑占位」惯例：目标端不主动触发，而是由源端驱动完成后立即调用，落地延迟通常在秒级。
阶段三：分阶段投产。 第一周只在测试租户跑，观察返回的分类数和层级是否对齐；第二周切换预发；第三周正式上线，并打开轻易云的运行告警。一旦发现「本次返回数量异常为 0」，要立刻人工确认源端接口是否限流。
踩坑复盘
- 父分类编码缺失导致层级断裂。 销帮帮部分一级分类的
parentId返回为空字符串而不是 0，轻易云默认当成根节点处理，结果下钻时出现孤儿节点。稳妥做法是在轻易云的字段转换里把空串统一规整成0。 - 同一分类被多次入库。 早期我们没注意源端
idCheck为 false，导致每次查询都重新拉一遍并覆盖。后续把轻易云侧的入库动作从「覆盖式」改为「按 id 存在则更新、不存在则插入」，并把idCheck在源端配置里勾选启用。 - 凭证硬编码在策略里。 第一次配置时把
corpid和userId直接写在 request 字段里，换环境时要逐条改。正确做法是轻易云的凭证引用变量（${XIAOBANGBANG_CORPID}），由平台统一注入。 - 空操作的「写入空操作」被误以为是 Bug。 一些新同事看到目标端 request/response 都为空，会怀疑没写完。其实在 QUERY_ONLY 场景下，源端就是主驱动力，目标端只是落点；真正落地的字段在轻易云内部主题表里，不需要走业务系统接口。
- 调度时间扎堆。 默认源端 2:03、目标端「1 1 1 1 1」看似错开，但同租户还有其他五条策略在凌晨运行，容易引发瞬时压力。稳妥做法是把同租户的所有凌晨任务均匀分散到 02:00–04:00。
适用场景与不适用场景
本策略适合「单一可信源 + 平台内部字典沉淀」的场景，例如销帮帮是产品主数据唯一来源，需要把分类同步到轻易云供聚水潭商品映射、销售统计、BPM 流程使用。不适用于：源端有双向写入冲突的场合、需要实时（亚分钟级）响应的库存类场景、以及目标端本身就是强业务系统而非平台占位的场景。