智邦ERP客户联系人查询同步：单一策略实战教程

这个策略解决什么问题

在某制造企业的私有化环境里，前端用小满OKKICRM管客户与销售，后端用智邦ERP承接合同与生产。客户在CRM签完合同，联系人信息散在两套系统：CRM记业务联系人，ERP的移动端通讯录记执行联系人。业务员经常问「这个客户最近对接人是谁、岗位是什么」，两边手动维护，三个月就对不上号。

本策略做一件事：从智邦ERP定时拉取客户联系人列表，作为基线数据落到轻易云数据集成平台的中间层，由其他策略按需读取。它不直接写业务单据，只做基础资料落库与版本对齐。

数据流向与字段映射

整体流向是 智邦ERP → 轻易云集成平台（datahub），单向拉取。源端为智邦ERP的WebAPI接口 /sysa/mobilephone/salesmanage/person/list.asp，方法POST，effect为QUERY；目标端在轻易云侧配置为「写入空操作」（effect为EXECUTE），意味着本轮数据先在datahub落地，再被其他策略消费。

关键字段对照如下：

源端 idCheck=true、autoFillResponse=true，表示返回结构会被轻易云自动解析为模型字段；buildModel=false 意味着不在源端建模，映射集中在轻易云侧做。

在轻易云上如何配置

在轻易云集成平台里配置这条策略，核心是三件事：源端连接器、定时调度、目标落地动作。

第一，源端连接器选「智邦ERP」类型，填入私有化部署的网关地址与鉴权信息。session 字段建议放在轻易云的环境变量里轮换，不要硬编码到策略配置。cmdkey 固定传 refresh，表示每次拉全量联系人。

第二，请求体 datas 为空对象即可，靠 session+cmdkey 触发服务端返回全量列表。

第三，目标端选「轻易云集成平台（datahub）」，effect 设为 EXECUTE，API 留为内置的「写入空操作」。这一段看似无意义，实则是把数据落到 datahub 的中间表，供下游策略按 contact_id 或 source_bill_no 关联读取。

第四，轻易云常见的客户做法是把编码映射集中管理：本策略里如果出现CRM编码与ERP编码差异，不在策略里写转换，而是在轻易云的「主数据映射」模块统一维护一份字典，本策略只负责原样落库。

实施步骤

我们建议分三个阶段跑通这条策略：

阶段一：增量起点。 先手动触发一次全量拉取，观察源端返回的列表大小与字段完整性。智邦ERP的联系人接口通常返回数百到数千条，首次跑完确认无超时、无截断。

阶段二：全量触发。 把源端 crontab 设为 3 2 * * *（凌晨2:03），目标端 crontab 设为 23 2 * * *（凌晨2:23）。两端错开20分钟，给源端留出充足的拉取窗口，也避免两边在同一秒抢占网关。

阶段三：调度频率。 联系人变化频率不高，每天一次足够；如果客户现场要求更高频，可改成每4小时一次，但要注意源端接口的并发上限。这种「全量双轨、增量兜底」的节奏，是轻易云客户里最常见的打法。

跑通后，用轻易云的运行日志核对源端返回条数、datahub落库条数、差异条数，三者对得上才能视为稳定。

踩坑复盘

踩坑一：把 session 写死在策略里。 智邦ERP的 session 有有效期，写死意味着每次过期都要人工换。稳妥的做法是放在轻易云连接器的鉴权脚本里，失败自动重登。

踩坑二：误把目标端当成业务写入。 本策略的目标 API 是「写入空操作」，只落中间层。新人容易误以为「没写入就是失败」，于是改成调ERP写入接口，造成重复数据。记住：基础资料类策略通常只负责「取齐、落齐」，不直接动业务单据。

踩坑三：忽略 ord 字段的去重作用。 同一联系人可能在不同单据下出现多次，仅用 name 去重会把同名联系人合并掉。务必用 ord+name 联合主键。

踩坑四：两端 crontab 撞车。 源端2:03拉，目标端2:23落，看似错开，但轻易云里若有其他策略也在2点档跑，可能挤占网关。建议先用轻易云的「调度日历」看一眼同窗口的策略密度。

踩坑五：私有化环境网络抖动。 凌晨跑批最容易撞上网络设备维护窗口。一次实际项目里我们遇到过每周三凌晨2:30网关联动，导致拉取超时。解决办法是在轻易云里配置失败重试3次，间隔指数退避。

适用场景与不适用场景

适用：需要把ERP侧的基础资料（联系人、岗位、地址）作为权威源，定时同步到中间层供其他系统消费；私有化部署、网络可控、变更频率低的场景。

不适用：需要实时查询联系人信息（应改用接口直连而非落中间表）；联系人数据高频双向修改（本策略只支持单向拉取，不处理回写冲突）。