星辰币种主数据拉取策略实战：从 CRM 到 ERP 的小颗粒同步
这个策略解决什么问题
币种、计量单位、客户分类这类基础资料，体量小但调用频率高，往往被忽视。在一次零售与外贸并行的客户现场，币种主数据从 CRM 流到 ERP 看似不起眼，没设计好就会出现订单币种取不到、汇率口径混乱、报表折算失真等问题。本文聚焦"获取星辰币种"这一最不起眼却最容易翻车的小颗粒同步策略。
数据流向与字段映射
源系统是金蝶云星辰 V2，目标是轻易云集成平台（datahub）。源端是查询接口 /jdy/v2/bd/currency（GET），目标端是平台内置的"写入空操作"，本质上是为了把拉到的数据落到中间层，供后续策略消费。
关键字段对照：
| 源字段 | 含义 | 中间层取值 |
|---|---|---|
| modify_start_time | 修改时间-开始时间戳（毫秒） | {{LAST_SYNC_TIME}}000 |
| modify_end_time | 修改时间-结束时间戳（毫秒） | {{CURRENT_TIME}}000 |
| page | 当前页 | 1 |
| page_size | 每页条数 | 100 |
| id | 币种主键 | 原样透传 |
| number | 币种编码 | 原样透传 |
idCheck 在目标端被显式关闭，buildModel 也关闭，意味着这一策略只负责"抓数据"，不负责"建主数据模型"——这是常见做法，避免小颗粒策略承担过多职责。
在轻易云上如何配置
源端配置：API 类型选 WebAPI，请求方式 GET，开关 autoFillResponse=true，这样接口响应字段会被轻易云自动识别为可映射字段，省去手写 schema 的成本。
目标端配置：API 选"写入空操作"，effect 设为 EXECUTE，POST 提交，idCheck=true。这里有个细节：源端 idCheck=false、目标端 idCheck=true，是因为源端是按增量时间窗去重的，目标端要按 id 幂等，确保同一笔币种不会重复落库。
编码映射：币种编码天然存在 ISO 4217 标准（CNY、USD、EUR），不需要复杂的映射表。但稳妥的做法是在轻易云的"编码映射集中管理"里维护一份币种对照，比如源端叫"人民币"，目标端需要标准为"CNY"——把这类映射集中维护，未来加策略时直接引用。
实施步骤
第一阶段：增量起点。 第一次接入时不要直接跑全量。先用一个固定的历史时间戳（例如三个月前）作为 modify_start_time，跑一遍增量，把首批数据落到中间层。这是稳妥的做法，避免一上来就触发源端限流。
第二阶段：调度频率。 素材里给的是 2-59/5 8-20 * * *，即工作时段每 5 分钟拉一次。这个频率适合基础资料：体量小但要求新鲜度。但要注意：如果是 7×24 业务，应扩展到全天；如果是仅白天跑单，8-20 足够。
第三阶段：全量触发。 币种这类基础资料数量极少（全球也就一百多种），日常用增量即可，不必单独跑全量。但如果某天源端改了时间戳格式或丢了增量窗口，稳妥的做法是手工触发一次全量，把中间层拉齐。
第四阶段：下游消费。 中间层落地后，下游策略（例如订单同步、报价同步）直接读币种编码，不再回源端查询。这是轻易云客户常见的"表头表体分阶段"模式：先把基础资料落地，再让业务单据策略去消费。
踩坑复盘
- 时间戳单位混淆。 源端要求毫秒级时间戳，但
CURRENT_TIME默认是秒。这里容易翻车，必须手动手动追加000，否则源端返回空集，平台却以为同步成功。 - 页大小不要拍脑袋。 素材里给了
page_size=100，这是稳妥的折中值。设置过大容易触发源端限流，过小则调度次数翻倍、IO 浪费。 idCheck开关不一致。 源端关、目标端开，看似矛盾实则分工明确：源端按时间窗去重，目标端按主键幂等。常见错误是两边都关，导致重复数据堆积。- 目标端"写入空操作"误解。 不少新手以为"空操作"就是啥也不干，实际上平台会把响应载荷落到中间层表里。一定要在轻易云里确认中间层表已经建好，否则数据会丢。
- 依赖关系缺失。 币种策略应当排在订单、报价等下游策略之前。素材里给了
sequence字段，部署时一定要按 sequence 排序上线，否则下游会读到空币种。
适用场景与不适用场景
适用：基础资料体量小（千条以内）、需要高频刷新、对下游业务单据有强依赖的场景，如币种、计量单位、税率、付款条件。
不适用：数据体量大、需要复杂转换或多源汇聚的场景；以及源端不支持增量时间窗、只能全量拉取的场景——这种更适合走离线批量同步。