客户主数据从用友NCC到吉客云：单一策略同步实战教程
这个策略解决什么问题
在某零售企业的实际项目里，用友NCC是后台 ERP，存放最权威的客户主数据；吉客云是前端业务平台，需要用到客户档案来跑单据。两边一旦不一致，开单员就要在两个系统来回核对，效率低还容易出错。我们用轻易云数据集成平台承接，把用友NCC的客户档案单向同步到吉客云，做成一条可监控、可重跑、可追溯的策略。
数据流向与字段映射
整体流向是：源系统（用友NCC）→ 轻易云中间层（Qeasy）→ 目标系统（吉客云）。中间层只负责搬运和字段转换，不沉淀业务数据。
关键字段对照（仅列出会引发问题的字段，具体字段名以脱敏后的代号表示）：
| 业务含义 | 源端（用友NCC） | 中间层（Qeasy） | 目标端（吉客云） |
|---|---|---|---|
| 客户编码 | cust_code | cust_code（主键） | customer_code |
| 客户名称 | cust_name | cust_name | customer_name |
| 客户简称 | cust_short_name | 截取/补齐逻辑 | customer_short |
| 客户分类 | cust_type_id | 类型映射字典 | customer_category |
| 默认币种 | currency_id | 币种代码转换 | currency |
| 税号 | tax_no | 直接透传 | tax_no |
| 地址 | address | 拼接（省市区+详细） | address_full |
| 状态 | enable_flag | 启用=1/停用=0 | status |
编码映射集中管理是轻易云客户里常见的做法：所有客户分类、币种的映射值都放在中间层的映射表里，源端或目标端字段调整时，只改一处，不用动策略本身。
在轻易云上如何配置
打开轻易云数据集成平台的新建策略向导，按下面几个要点配置：
- 数据源注册：源端选择用友NCC的对应账套接口（按客户实际授权配置），目标端选择吉客云的客户档案写入接口。这一步只做连通性验证，不拉数据。
- 请求参数与分页：用友NCC的接口通常带分页参数，中间层要配置 pageSize、pageIndex 的循环逻辑，保证大数据量时不会漏页。
- 字段映射：把上表的字段一一对到目标端的写入接口字段，启用类型转换、字符串截取、地址拼接等转换器。
- 去重与主键策略：以客户编码作为唯一键，目标端按主键做 upsert，重复编码覆盖更新而非新增，避免档案分裂。
- 异常处理：配置失败重试次数、超时阈值、失败行落库到异常表，方便事后人工补跑。
- 日志与审计：开启轻易云的运行日志，关键字段变更留痕，方便审计追溯。
实施步骤
这条策略建议按三阶段推进，避免一上来就跑全量把目标端冲乱：
第一阶段：增量起点确认。 先在源端捞一批最近有更新的客户（按修改时间过滤），作为同步起点。轻易云会记录这个时间戳，后续自动增量。
第二阶段：全量触发。 第一次上线时，手工触发一次全量，把历史客户档案一次性铺到吉客云。全量跑完后立即切换到增量模式。增量与全量双轨是轻易云客户里非常成熟的应对模式。
第三阶段：调度频率。 客户主数据不像订单那么高频，日常每 30 分钟一次增量即可；停用的客户单独跑一次停用状态同步（每日一次或按需触发）。夜间再做一次兜底的全量校验，把当天漏掉的增量补齐。
上线初期建议人工核对两边客户数量与抽样字段；运行稳定后切到自动调度。
踩坑复盘
- 编码映射没集中管：早期把分类、币种的映射值直接写在策略里，源端一改分类名称，目标端就出现脏数据。稳妥的做法是全部上提到中间层的映射表。
- 地址字段直接透传：源端地址是分字段存的，目标端是单一长字段，没做拼接就推过去，前端展示会少省市区，用户体验差。
- 主键没去重：同步策略没带主键 upsert，目标端按编码新增，导致同一个客户出现两条档案。
- 停用客户当成启用推过去：源端 enable_flag 是字符 'N'/'Y'，写脚本时当成布尔处理，所有客户全变成启用。稳妥做法是在映射层显式转成 1/0。
- 首次全量把目标端冲乱：没设首次全量的人工确认环节，跑完后业务部门反馈"我刚维护的备注被覆盖了"。稳妥做法是首次全量前清场或做字段级合并策略。
适用场景与不适用场景
适用场景：客户主数据权威源在用友NCC，吉客云只做消费；客户档案量在十万级以下；变更频率不高（每日几十到几百条）。
不适用场景：吉客云有独立维护客户档案、双向编辑；客户档案量在百万级以上需要走专用 ETL；以及需要实时逐笔同步的强一致场景。