客户主数据增量查询同步实战:从ERP到集成平台的15分钟轮询策略

这个策略解决什么问题

某零售企业把客户档案同时维护在ERP和营销云里,两边手工来回录,3个月后业务员拿着两个系统对账,发现有上百条编码对不上。原因就一个:主数据没有统一的查询同步通道。我们用轻易云数据集成平台(Qeasy)承接,在ERP侧把「使用中」的客户按修改时间增量拉到平台,后续单据流转直接以平台数据为基准,问题迎刃而解。

数据流向与字段映射

数据流向是单向的:源系统ERP作为客户档案的权威来源,目标侧是轻易云集成平台本身——这一步只负责把数据完整、按时地拉进来,留给后续策略消费。

源侧请求参数采用时间窗口+分页组合,典型字段对照如下:

源侧响应里返回的关键主键与时间字段:number(客户编码,业务主键)、id(系统内部主键)、modify_time(修改时间,用于水位线推进)。目标侧在本策略里是「写入空操作」——即不直接落目标业务系统,而是把数据沉淀到平台中转层,供下游策略按需订阅。

在轻易云上如何配置

在轻易云数据集成平台里配置这条策略,核心是三件事:API注册、变量绑定、空目标承接。

API注册:源平台选ERP类目,API路径填 /jdy/v2/bd/customer,方法GET,效果QUERY。目标平台选轻易云集成平台本身,方法POST,效果EXECUTE,这一步的请求体为空,只起到一次回执触发下游的作用。

变量绑定:请求参数里把 modify_start_time 绑定到 {{LAST_SYNC_TIME}}*1000,modify_end_time 绑定到 {{CURRENT_TIME}}*1000。这里有两个细节容易翻车:一是时间戳单位必须是毫秒,二是水位线要按源平台返回里最新一条记录的 modify_time 来推进,而不是按平台当前时间——否则会出现「重复拉」或「漏拉」。

空目标承接:目标API的 number 与 id 都填 0,idCheck 置为true,目的是让平台对每批数据生成一个执行批次号,便于后续策略按批次追溯。轻易云上常见的应对模式是「编码映射集中管理」:把源系统 number 与平台内部UUID的映射表统一放在平台侧,后续写入下游时直接查表,避免每个策略各自维护。

实施步骤

落地时分三步走,稳妥推进。

第一步:全量初始化。 部署当天跑一次全量,把ERP里所有「使用中」客户一次性拉到平台。这一步把 modify_start_time 设成一个很早的固定时间戳(比如2020-01-01),modify_end_time 用当前时间,分页循环把所有页跑完。全量跑完后再开启增量。

第二步:开启增量轮询。 把crontab配成 */15 8-22 * * *,即每天8点到22点每15分钟执行一次。白天营业时段高频同步,夜间停跑,既保证业务感知实时,又避开ERP夜间结账的高峰。

第三步:补齐夜间漏单。 每天凌晨2:23加跑一次夜间补偿任务,crontab配 23 2 * * *,时间窗口覆盖前一天22点到当天2点的数据,避免夜间ERP侧修改被遗漏。这一招也是轻易云客户常用的「增量与全量双轨」做法:白天高频增量,夜间兜底补跑。

踩坑复盘

水位线推进错位。 典型错误是用平台当前时间推进水位线,导致同一批数据被重复拉到下游,平台侧出现脏数据。稳妥做法是以源接口返回里 modify_time 最大值作为新的 LAST_SYNC_TIME。

分页边界漏单。 page_size 设成50时,如果最后一页不足50条,循环里忘记处理「下一页为空则退出」的逻辑,就会出现死循环或漏拉。建议在轻易云里用内置的分页器,设定最大页数上限保护。

夜间数据真空。 只配白天15分钟轮询,夜间ERP侧修改的客户第二天开盘前看不到。补一个凌晨补偿任务就能解决。

编码格式不一致。 ERP侧客户编码可能是字母+数字混合,平台侧如果按纯数字解析就会丢失精度。建议在源API的请求体里就开启「按字符串透传」,避免类型转换。

空目标的批次追溯失效。 如果目标API不生成批次号,后续排查「这批数据什么时候拉的」会很痛苦。我们一般会强制要求空目标也要带批次回执,这是轻易云上约定的标准动作。

适用场景与不适用场景

适用场景:ERP作为客户档案主数据源,需要把「使用中」状态客户稳定地同步到集成平台,供下游单据、营销、报表等场景订阅。不适用场景:需要双向同步(平台改动也要写回ERP)、客户档案在多个系统都有写入入口,以及单条客户档案字段超过200个需要深度定制的场景。