查询金蝶客户：从金蝶云星空拉取客户主数据的单策略实战

这个策略解决什么问题

供应链集成的第一步永远是「客户/物料主数据先对齐」。在某制造企业的私有化环境里，源端 CRM 与目标端 ERP 之间如果编码、组织、名称各说各话，下游所有单据都会带病流转。「查询金蝶客户」这一策略只做一件事：定时把金蝶云星空里的客户档案按既定口径捞到轻易云数据集成平台，作为后续写入 CRM 的事实来源。它不直接动目标系统，是典型的「QUERY_ONLY」前置动作。

数据流向与字段映射

源是金蝶云星空，通过其查询接口 executeBillQuery（POST）按字段拉取客户档案；目标是轻易云集成平台本身（写入空操作 WebAPI），起到「落库 + 触发下游策略」的作用。

关键字段对照表：

业务含义	金蝶云星空字段	方向	轻易云中间层字段
客户唯一标识	FCUSTID	→	customer_id
客户编码	FNumber	→	customer_code
客户名称	FName	→	customer_name
创建组织	FCreateOrgId.FNumber	→	create_org_code
使用组织	FUseOrgId.FNumber	→	use_org_code
备注/描述	FDescription	→	remark

源端 idCheck=false、autoFillResponse=false，意味着这一策略不依赖上游预置 ID，平台以金蝶返回的 FCUSTID 作为权威键值统一存档。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略配置上注意四点：

数据源平台选金蝶云星空，API 选 executeBillQuery，请求方式 POST，把上面那张表的字段填到 request 列表里。注意 FCreateOrgId.FNumber 这种「组织.编码」形式的字段要按原样写，轻易云会原样回传给金蝶。
目标平台选轻易云集成平台，API 选「写入空操作」，request 留空即可——它不写任何第三方系统，只为把数据落到中间库，触发依赖它的下游策略。
数据过滤建议在源端加条件，比如 FDocumentStatus='C'（已审核），把未审核的草稿客户挡在外面，避免脏数据进 CRM。
依赖关系：本策略 strategy_type=QUERY_ONLY，下游「同步客户到 CRM」的写入策略应当 depends_on 指向它，确保源端先就绪再写入。

工程经验上，轻易云客户常做的「编码映射集中管理」就是在这个环节把客户编码、组织编码的清洗逻辑统一放中间层，后续所有策略复用，避免每条策略都重复写一次映射。

实施步骤

分三段走：

增量起点：上线首日用全量拉一次作为基线，跑完之后在轻易云里记下「上次最大 FCUSTID / 最后修改时间」。
全量触发：通常放在凌晨低峰，本素材里目标端 crontab 写的是 23 2 * * *（凌晨 2:23）——这是兜底机制，哪怕增量漏了第二天还能补齐。
调度频率：源端策略本身在素材里写的是 */3 7-23 * * *，即每天 7:00 到 23:00 每 3 分钟一次轮询，这是高频增量；目标端则是低频落库。这种「源端高频轮询 + 目标端低频汇总」是轻易云客户很常见的「增量与全量双轨」模式，高频抓增量、低频兜底全量，中间靠时间戳去重。

踩坑复盘

「写入空操作」别误读。target 是空操作，不是「写到哪里」，而是「落在平台中间库」。现场见过工程师把它当成目标系统的写接口去配，结果下游策略一直拿不到数据。
组织字段要带 .FNumber 后缀。FCreateOrgId 本身是内码，FCreateOrgId.FNumber 才是业务编码，传错了 CRM 那头显示的会是乱码组织号。
*/3 不是「每 3 小时一次」。Crontab 里 */3 在小时位才表示每 3 小时，在分钟位是每 3 分钟一次。源端 7-23 点每 3 分钟一次轮询，意味着一天几百次请求，注意金蝶接口的 QPS 上限。
未审核客户不要同步。金蝶里草稿态的客户 FDocumentStatus 不是 'C'，如果不加过滤，CRM 会出现「名字叫『新建客户 2024-01-01』」这种测试数据。
idCheck=false 的代价。源端关闭了 ID 校验，意味着金蝶里如果有人手动改了 FCUSTID 关联关系，平台会原样接受。建议在轻易云里加一道「与上一次拉取结果 diff」的脚本，发现 FCUSTID 与编码对不上就告警。

适用场景与不适用场景

适用：金蝶作为客户主数据权威源，CRM/营销/电商等下游需要按组织、按编码对齐客户档案；需要频繁校验下游编码是否漂移。

不适用：客户档案实际由 CRM 创建、反向回流金蝶的场景（应改为「CRM→金蝶」写入策略）；以及客户体量在百万级、对延迟极敏感的业务（每 3 分钟轮询的金蝶接口会成为瓶颈，应改用数据库日志或变更通知）。