委外出入库单从旺店通同步到 MySQL:基于轻易云的实战方案

这个策略解决什么问题

在某零售企业的委外加工场景里,委外仓库的出入库单据是财务对账、库存核算和供应商结算的唯一依据。这些单据托管在旺店通系统中,下游的 MySQL 数据仓库却拿不到,导致月末对账时两边数字对不齐,运营每周要花大半天手工补录。这个策略的目标,就是用轻易云数据集成平台(Qeasy)把旺店通的委外出入库单按增量方式拉到 MySQL,做到入库即落账、对账无需人工。

数据流向与字段映射

整体流向是 旺店通(源) → 轻易云集成平台(中间层) → MySQL(目标)。源端是旺店通·企业奇门的一个查询接口,目标端是一条可执行 SQL,中间层负责字段清洗、编码映射与子表展开。

主表和子表通过 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 分钟,避免源端刚返回结果就被目标端读到空。

实施步骤

我们一般分三个阶段落地:

1. 增量起点:先在轻易云里跑一次全量,确认主表 + 子表行数与源端一致;然后把入参里的 status 收敛到「60 待出库 / 65 待入库」之后的状态,作为增量起点,避免历史脏数据回流。
2. 全量触发:对账日前后,临时把入参清空触发一次全量回灌,完成差异核对,核对完恢复增量。
3. 调度频率:日常按 11 分钟一轮跑,源端错峰 3 分钟;对账日临时加密到 5 分钟一轮,核对完毕立即恢复原频率。

踩坑复盘里我们总结过一个稳妥的做法:全量回灌只在轻易云里以「重新执行一次写入」触发,不要改源端 order_type 等入参,否则会把取消单也带回来。

踩坑复盘

1. 错峰调度没设:源端刚写完,目标端立刻读,容易出现「读到一半」的快照。我们在轻易云里把两端 cron 错开 3 分钟,问题就消失了。
2. 1:N 子表忘绑定:源端返回的 details_list 没显式绑到 extend_params_2,子表会写空。配置时一定要在目标端把 extend_params_2 = details_list 写死。
3. REPLACE INTO 被改成 INSERT INTO:某些客户为了让历史数据可见,手动改成 INSERT INTO,结果主键冲突后整批失败。幂等场景坚持 REPLACE INTO,这是轻易云推荐的标准写法。
4. 状态码被翻译:把旺店通的 status=80 已完成 翻译成下游的「已结算」,结果对账时两边口径不一致,排错排了一整天。原值下推、下游解释,是更稳妥的做法。
5. 全量回灌误带取消单:入参 status 留空时,源端会返回状态 10 取消 的单据。我们后来在轻易云里加了一个过滤节点,只让 status >= 20 的单据进入下游。

适用场景与不适用场景

适用:委外仓出入库量大、单据状态需要实时落到数据仓库做对账和报表的企业;源端是旺店通、目标端是 MySQL 这类关系型库,且能接受 11 分钟级延迟。

不适用:需要秒级实时库存的场景(请走消息队列直推);源端单据结构频繁变动、字段命名不稳定的环境(请先在轻易云里做一层 schema 冻结)。