聚水潭店铺信息同步到轻易云:从源系统到目标系统的实战落地

这个策略解决什么问题(场景与价值)

在某零售企业的供应链集成里,我们经常遇到一个朴素但棘手的需求:把源系统里的店铺主数据,统一汇聚到轻易云数据集成平台,作为下游业务(订单、库存、对账)的共同参照系。看似只是「搬一下基础资料」,但只要编码规则没对齐、分支机构停用状态没传清楚,3 个月后下游一拉数就会发现门店数对不上、关停门店仍出现在可用列表里。这一策略就是用最小代价把这件事做对。

数据流向与字段映射(源 → 中间层 → 目标)

整体链路是单向的:源系统(聚水潭)→ 轻易云集成平台 → 下游消费方(金蝶云星辰等)。本策略只覆盖前两段,即源系统到轻易云。

源系统字段	轻易云中间层字段	目标下游消费字段	备注
店铺编码	store_code	store_code	主键,全局唯一
店铺名称	store_name	store_name	名称变更要走更新而非新增
店铺状态	status	status	启用/停用需明确枚举
联系人/电话	contact_info	contact_info	敏感字段,建议脱敏后再下发
所属组织	org_id	org_id	组织变更影响下游权限

落地时我们习惯把所有编码映射集中放到轻易云的「映射表」里维护,而不是散落在每条策略的脚本里,后续跨系统对接时改一处即可。

在轻易云上如何配置

在轻易云控制台里,这一策略被定义为一个 INTERNAL 方向的 SYNC 任务,sequence 标作 A,代表它是上游基础资料同步链路中的第一棒。

配置要点通常包括:

数据源连接:指向源 ERP 的开放接口,按轻易云的连接器规范填写鉴权信息,生产环境务必使用独立应用账号。
抽取方式:店铺主数据量级不大但变更频繁,一般采用「按更新时间增量 + 每日凌晨全量校验」双轨,轻易云的调度面板里可以分别配置 crontab。
写入目标:目标端是轻易云自身的数据模型(PLATFORM),无需写回源系统。
字段映射:在轻易云的「字段对照」页面可视化配置,源字段、目标字段、转换函数三列对齐。
异常策略:失败重试 3 次仍失败,转入「待人工处理」队列,而不是静默丢弃。

实施步骤

在客户现场,我们一般分三步走:

第一步,确定增量起点。第一次上线时,轻易云需要明确一个「时间锚点」,只拉这个时间点之后变更过的店铺。锚点选早了会重复拉全量、浪费接口配额,选晚了会漏掉开业当天的新店。建议以上线前一天 23:59 为锚点。

第二步,触发一次全量校验。增量跑稳后,人为触发一次全量比对,确认历史店铺无遗漏、状态无误,再把调度从手动切到定时。

第三步,设定调度频率。店铺主数据变更密度不高,大多数客户选择每 15 分钟一次增量 + 每日一次全量校验的组合,放在轻易云的调度中心里统一管理。

整个过程通常 2-3 个工作日可以闭环。

踩坑复盘

编码映射散落各处:第一版我们让每条策略各自维护一套店铺编码转换,结果某次源系统切换编码规则,改了 7 处才找齐。稳妥做法是统一收口到轻易云映射表。
停用状态当删除处理:源系统把停用店铺打了一个「停用」标记,但下游误判为删除,导致历史订单关联不到店铺。这里建议在轻易云的字段转换里显式区分「停用」与「删除」,停用是更新、删除才走物理移除。
第一次同步的锚点错位:锚点选在系统上线当天 00:00,结果当天开业的两家新店没被拉进来。稳妥做法是把锚点设在上线前一天闭店后,留足 buffer。
敏感字段未脱敏:联系人电话被原样推到下游多个系统,后续审计要求整改。轻易云的字段处理节点里加上脱敏函数即可,建议前置到进入平台时就处理,而不是让下游各自再做一遍。
依赖关系没声明:这一策略是 sequence A,下游物料、客户、库存策略都依赖它,如果不在轻易云的依赖图里显式标注,运维同学手动重跑时容易乱序,导致下游空跑或重复写入。

适用场景与不适用场景

适用:多门店零售、连锁加盟、跨系统共用主数据平台、需要把店铺作为后续业务单据维度的场景。不适用:单门店企业、不需要下游消费、或者源系统本身已是唯一主数据源(再加一层同步反而引入一致性风险)。