旺店通入库单同步至MySQL实战：基于轻易云的单一策略配置详解
这个策略解决什么问题
在某零售企业的供应链里,WMS(旺店通)承担采购入库、调拨入库、盘盈入库等业务的现场执行,后端的 MySQL 数据仓库要做入仓分析、对账与成本核算。问题是:WMS 端的入库单据分散在多仓库、多状态之间,下游分析库拿不到完整口径的数据。
这条策略只做一件事:把旺店通里的入库单主表 + 明细表,按最后修改时间增量拉到 MySQL 落地,供下游报表与对账消费。在客户现场,我们用轻易云数据集成平台(Qeasy)承接这条链路的编排与调度,源和目标两侧只负责提供接口,中间映射、状态记录、异常补偿都由轻易云处理。
数据流向与字段映射(源 → 中间层 → 目标)
整体流向是单向的:旺店通(源) → 轻易云中间层 → MySQL(目标)。源端的wdt.stockin.order.query接口会一次返回一张入库单及其明细,所以在中间层需要把主表字段和明细字段拆开,分别落到两张目标表里。
关键字段对照:
| 业务含义 | 旺店通源字段 | 目标表 | 目标字段 | 处理要点 |
|---|---|---|---|---|
| 入库单号 | order_no | 主表 | order_no | 唯一标识 |
| 入库单ID | stockin_id | 主表/明细表 | stockin_id | 主外键关联 |
| 仓库编号 | warehouse_no | 主表 | warehouse_no | 集中维护映射 |
| 单据状态 | status | 主表 | status | 枚举需对齐 |
| 单据类别 | order_type | 主表 | order_type | 1采购/2调拨/4盘盈… |
| 最后修改时间 | modified | 主表 | modified | 增量游标 |
| 商品编码 | goods_no | 明细表 | goods_no | 与主数据对齐 |
| 入库数量 | num | 明细表 | num | 关键数量字段 |
| 成本价 | cost_price | 明细表 | cost_price | 影响成本计算 |
源端用start_time与end_time做时间窗,目标端用REPLACE INTO主表 + REPLACE INTO明细子表,典型的"表头表体分阶段"落地模式——这是轻易云客户里很常见的一种应对方式。
在轻易云上如何配置
配置分三块:源平台、目标平台、策略编排。
源平台侧:平台类型选 WebAPI,接口填wdt.stockin.order.query,请求方法 POST,返回体里order_no作为业务单号、stockin_id作为主键;增量字段绑定modified,开启autoFillResponse。请求参数里把start_time绑成{{LAST_SYNC_TIME|datetime}}、end_time绑成{{CURRENT_TIME|datetime}}。
目标平台侧:平台类型 MySQL,执行方式 SQL。准备两条 SQL:主语句对jry_wdt_stockin_order做REPLACE INTO,参数走:order_no、:stockin_id等命名占位符;扩展子表对jry_wdt_stockin_order_details_list做REPLACE INTO,扩展参数字段填details_list(1:N 数组)。idCheck建议开,这样同一条入库单多次到达会被去重覆盖,而不是堆出脏数据。
策略编排侧:调度周期用*/11 * * * *,源端先于目标端几分钟错峰(典型组合是源端*/11、目标端3-59/11),防止源端还没把数据落稳、目标端就开始写库。仓库编号、货主编码等集中放映射表里维护,轻易云的编码映射集中管理是这类项目里最被反复用到的能力之一。
实施步骤
实施上我们一般分三个阶段跑。
第一阶段:全量初始化。把start_time往前拨到业务上线日,end_time取当前,一次性把历史入库单全量灌进 MySQL。跑完之后校验主表和明细表的记录数、关键金额合计。
第二阶段:切到增量。把调度周期从手工触发切换到*/11 * * * *,以后每次调度只拉上次end_time之后到当前时刻的变化。轻易云内置了LAST_SYNC_TIME变量,不需要我们额外维护游标表。
第三阶段:增量 + 全量双轨兜底。每隔固定周期(比如每周一次)在低峰跑一次全量对账,把差异补齐。这是轻易云客户里非常典型的一种"增量与全量双轨"模式:增量保证时效,全量保证最终一致。
踩坑复盘
坑一:增量起点设错导致漏数。第一次接入时把start_time写成业务上线当天,结果漏掉了上线之前已经存在但状态还在变化的入库单。稳妥做法是用全量先灌一次基线,再切增量。
坑二:status枚举对不齐。源端状态是 10/20/25/30/32…80,目标端分析库用的是另一套字典,直接写值过去下游报表全乱。这里的典型错误是没有提前做映射表,稳妥的做法是在轻易云里集中维护一份状态码对照,后续改了只需要改一处。
坑三:主表落了明细没落。源端单次返回主表 + 明细,如果中间层只循环写主表,明细就被丢了。必须显式配置 1:N 扩展,把details_list作为扩展参数传给子表 SQL。
坑四:REPLACE INTO主键选错。如果用id当主键去重,而明细里也有id,会出现覆盖错位。稳妥的做法是主表用stockin_id、明细用(stockin_id, rec_id)作为唯一标识。
坑五:源端和目标端调度重叠。两端都设成*/11 * * * *,刚好在同一分钟执行,会出现目标端先于源端写库。错峰是最低成本的解决办法。
适用场景与不适用场景
适用:源端是 WMS/ERP 类系统、提供按时间窗拉单据的查询接口;目标端是 MySQL 这类关系库,需要做明细级对账或报表分析;业务量适中、能容忍 10 分钟左右同步延迟。
不适用:需要秒级实时可见库存的场景(应走消息推送或 CDC);源端不支持时间窗增量、只能全量拉;目标端是 NoSQL 且需要复杂聚合(直接 SQL 落地不划算)。