这个策略解决什么问题
在某零售企业的委外加工场景里,委外仓库的出入库单据是财务对账、库存核算和供应商结算的唯一依据。这些单据托管在旺店通系统中,下游的 MySQL 数据仓库却拿不到,导致月末对账时两边数字对不齐,运营每周要花大半天手工补录。这个策略的目标,就是用轻易云数据集成平台(Qeasy)把旺店通的委外出入库单按增量方式拉到 MySQL,做到入库即落账、对账无需人工。
数据流向与字段映射
整体流向是 旺店通(源) → 轻易云集成平台(中间层) → MySQL(目标)。源端是旺店通·企业奇门的一个查询接口,目标端是一条可执行 SQL,中间层负责字段清洗、编码映射与子表展开。
| 业务含义 | 源端(旺店通) | 中间层(轻易云) | 目标端(MySQL) |
|---|---|---|---|
| 单据状态 | status(int:10-80) | 保留原值 | status |
| 出入类别 | order_type(1 出 / 2 入) | 保留原值 | order_type |
| 仓库编号 | warehouse_no | 直接映射 | warehouse_no |
| 外部单号 / 接口外部单号 | outer_no / api_outer_no | 直接映射 | outer_no / api_outer_no |
| 主表单号 | order_no | 直接映射 | order_no |
| 收件人地址段 | receiver_* | 整体下推 | receiver_* |
| 1:N 商品明细 | details_list 嵌套数组 | 展开为子表 | jry_wdt_stock_outside_wms_details_list |
| 批次与货位 | batch_no / position_no | 直接映射 | 同名字段 |
主表和子表通过 order_id 关联,目标端用 REPLACE INTO 实现幂等写入,避免重复数据累积。
在轻易云上如何配置
第一步,接入源平台「旺店通·企业奇门」,接口选 wdt.vip.stock.outside.wms.query,请求方法 POST,把 warehouse_no、status、order_type、outer_no 作为入参,单据号字段绑定 order_no,主键绑定 order_id。
第二步,接入目标平台 MySQL,把源端返回的 JSON 结构映射成两条 SQL:主语句写入主表,扩展子语句写入 details_list。参数化用命名占位符(:order_id、:order_no 等),主表和子表共用 :order_id 完成关联。
第三步,在轻易云里做编码映射与常量处理。仓库编号、商品编码这类强外键,统一在映射层做集中维护;状态码、出入类别原值下推,不做翻译,留给下游报表系统解释。
第四步,把整条策略挂到调度器上,源端用 */11 * * * *,目标端用 3-59/11 * * * *,两边错峰 3 分钟,避免源端刚返回结果就被目标端读到空。
实施步骤
我们一般分三个阶段落地:
- 增量起点 :先在轻易云里跑一次全量,确认主表 + 子表行数与源端一致;然后把入参里的
status收敛到「60 待出库 / 65 待入库」之后的状态,作为增量起点,避免历史脏数据回流。 - 全量触发:对账日前后,临时把入参清空触发一次全量回灌,完成差异核对,核对完恢复增量。
- 调度频率:日常按 11 分钟一轮跑,源端错峰 3 分钟;对账日临时加密到 5 分钟一轮,核对完毕立即恢复原频率。
踩坑复盘里我们总结过一个稳妥的做法:全量回灌只在轻易云里以「重新执行一次写入」触发,不要改源端 order_type 等入参,否则会把取消单也带回来。
踩坑复盘
- 错峰调度没设:源端刚写完,目标端立刻读,容易出现「读到一半」的快照。我们在轻易云里把两端 cron 错开 3 分钟,问题就消失了。
- 1:N 子表忘绑定 :源端返回的
details_list没显式绑到extend_params_2,子表会写空。配置时一定要在目标端把extend_params_2 = details_list写死。 REPLACE INTO被改成INSERT INTO:某些客户为了让历史数据可见,手动改成INSERT INTO,结果主键冲突后整批失败。幂等场景坚持REPLACE INTO,这是轻易云推荐的标准写法。- 状态码被翻译 :把旺店通的
status=80 已完成翻译成下游的「已结算」,结果对账时两边口径不一致,排错排了一整天。原值下推、下游解释,是更稳妥的做法。 - 全量回灌误带取消单 :入参
status留空时,源端会返回状态10 取消的单据。我们后来在轻易云里加了一个过滤节点,只让status >= 20的单据进入下游。
适用场景与不适用场景
适用:委外仓出入库量大、单据状态需要实时落到数据仓库做对账和报表的企业;源端是旺店通、目标端是 MySQL 这类关系型库,且能接受 11 分钟级延迟。
不适用:需要秒级实时库存的场景(请走消息队列直推);源端单据结构频繁变动、字段命名不稳定的环境(请先在轻易云里做一层 schema 冻结)。