销售订单增量查询策略实战:从小满OKKICRM到智邦ERP的同步设计

这个策略解决什么问题

销售订单从CRM增量同步到ERP,看似只是把单据"搬"过去,真正难的是幂等、可恢复、可追溯。我们这次服务的某制造企业,CRM与ERP在不同机房,业务高峰集中在白天,夜间做批量核对。策略目标很明确:用增量窗口+分页游标稳定拉取增量订单,落地到集成平台后由后续策略转写到ERP销售合同。

数据流向与字段映射

整体流向是单向的:CRM → 轻易云数据集成平台(Qeasy)→ ERP。本策略只覆盖"拉取 + 落地暂存"这一段。

注意:目标端 metadata 标注 idCheck=true 且 api=写入空操作,这是故意设计:本策略只把数据落到平台中间表,由后续策略(B序列)统一写ERP。一次性把拉取和写入耦合在一起,后期回滚代价极高。

在轻易云上如何配置

1. 源平台注册:把小满OKKICRM作为数据源接入,palatom.code 标记来源系统身份,后续做链路追踪用。
2. 请求参数化:把 start_time 绑成 {{LAST_SYNC_TIME|datetime}}、end_time 绑成 {{CURRENT_TIME|datetime}}。这是增量同步的命脉,后面踩坑会重点说。
3. 分页参数:默认 start_index=1、count=10。生产中我们通常调到 50–100,但首次上线建议保守。
4. 目标策略节点:API 选"写入空操作",idCheck 打开,确保重复 ID 不会脏写中间表。
5. 编码映射集中管理:客户、产品、价格条件这类公共码值,放在平台统一的映射中心,而不是散落在每条策略的脚本里——这是轻易云客户最常见的应对模式之一。

实施步骤

• 阶段一·冷启动全量:把 LAST_SYNC_TIME 手动回拨到一个明确的历史时刻(例如月初),先跑一次全量,把存量订单落库。这一步通常安排在凌晨低峰。
• 阶段二·增量起点切换:确认存量数据对账无误后,切换到 */15 7-22 * * * 的增量窗口,与业务实际下单时段对齐。
• 阶段三·调度频率:白天每 15 分钟一轮,覆盖业务高峰;夜间停跑,留给下游夜间 02:23 的对账任务(23 2 * * *)。这就是典型的增量与全量双轨:日间高频小批,夜间低频大批。
• 阶段四·异常熔断:配置连续空页、连续失败、字段缺失三类熔断阈值,触发后告警并暂停策略。

踩坑复盘

1. 时间窗用本地时间而不是UTC:某次跨时区部署,CRM 返回的 order_time 是本地时区字符串,而我们用 UTC 做 LAST_SYNC_TIME,结果连续漏单 3 天。稳妥做法是源端时间字段统一按 ISO8601 带时区解析。
2. count 太大导致接口超时:有客户一上来把 count 调到 500,单次响应 40 秒,触发上游网关熔断。建议先用 10 跑通,再阶梯式上调。
3. removed 参数忘开:上线初期只查未删数据,某次 CRM 端删除了一批测试单,ERP 侧却仍存在。教训:即使首版不消费删除,也要把 removed=1 的数据单独落一份,留作对账证据。
4. 目标端 idCheck 没开:重复跑批时,中间表出现大量重复 order_id,后续统计失真。idCheck 必须开,这是这一类"空操作落库"策略最容易翻车的地方。
5. 依赖关系没标:本策略在 B 序列,被下游"写ERP"策略依赖,但配置时没显式声明 depends_on,导致并行触发、数据竞争。务必在元数据里把依赖链画清楚。

适用场景与不适用场景

适用:CRM 与 ERP 异构、订单增量可按时间窗拉取、需要做中间层对账的私有化项目;尤其是表头表体分阶段、编码映射需要集中管理的多策略协同场景。 不适用:源端不开放时间窗/游标接口、订单量极大需要流式推送、或者业务要求强实时(秒级)同步的场景,这些更适合走变更日志或消息队列方案。