【仅查询】星辰币别同步策略实战：从源系统拉取币别档案到中间层

这个策略解决什么问题（场景与价值）

在多系统供应链集成里，币别档案是一类典型"小但关键"的基础资料。某零售企业的项目现场，源系统是金蝶云星辰，目标侧是领星ERP，结算、汇率、采购价都依赖币别字典。如果源系统的币别发生新增或停用，目标侧没及时同步，后续单据就会出现汇率错算、报表对不平的问题。

本策略【仅查询】星辰币别，定位非常清晰：不主动写入目标业务系统，而是把币别档案统一收口到轻易云数据集成平台（Qeasy）的中间层，作为后续所有跨系统单据同步的"币别基准表"，由其他策略按需引用。这种"中间层收口 + 引用解耦"的模式，在轻易云的客户里很常见。

数据流向与字段映射（源 → 中间层 → 目标）

数据流向很直接：源系统（金蝶云星辰）→ 轻易云中间层 → 业务策略按需引用。本策略只负责前两段，不直接写回领星ERP。

关键字段对照表（按实际场景简化）：

业务含义	源字段	中间层存储	备注
币别内码	id	currency_id	主键
币别编码	number	currency_code	如 CNY、USD
币别名称	name	currency_name	显示用
状态	status	is_active	启用/禁用

源 API 调用 /jdy/v2/bd/currency，GET 方法，effect 为 QUERY。目标端配置的是 Qeasy 平台内部的"写入空操作"，作用是把数据落到中间层（实际写入由轻易云内部机制完成），无需回执业务字段。

在轻易云上如何配置

在轻易云数据集成平台的策略配置页里，新建一个策略，按下面的要点填：

策略名称：建议命名规范带上"仅查询"标识，例如 【仅查询】星辰币别-ok，方便后期维护一眼分辨。
源平台：选择金蝶云星辰V2 的 WebAPI 适配器，API 路径 /jdy/v2/bd/currency，请求方法 GET。
请求参数：模糊搜索 search 留空；pagesize 固定 100；page 通过分页循环自增。
分页与游标：源接口是分页查询，轻易云默认会按页拉满。这里idCheck 设为 true，配合 id 作为幂等键，避免重复落库。
目标平台：选择轻易云集成平台自身的 WebAPI 适配器（datahub），API 选择"写入空操作"，effect 为 EXECUTE，POST 方式，request/response 字段都为空——这不是漏配，而是这种收口类策略的典型写法。
元数据建模：buildModel 设为 false，autoFillResponse 设为 true，让平台按源响应结构自动铺字段，省掉人工建模型的活。

实施步骤

第一阶段：增量起点确认

上线前先在源系统人工盘点一次币别档案，确认总数与启用状态，作为基线。第一轮跑全量，把基线数据全部落到中间层。这一步看似多余，但轻易云的客户里几乎都栽过：没做基线，上线后某天突然发现中间层少了几条币别，根本没法判断是源系统漏推还是中间层丢的。

第二阶段：全量触发

手动触发一次全量同步，确认页大小、过滤条件无误。币别档案量一般不大（几十到几百条），全量几分钟就跑完了。全量通过后，把策略从手动切到定时。

第三阶段：调度频率

本策略的 crontab 配的是 59 2 * * *（每天凌晨 2:59 跑一次）。这里有讲究：避开整点高峰，挑一个源系统相对空闲的"分钟偏移"。轻易云客户里常见的应对模式是"增量与全量双轨"——本策略做每日全量兜底，对币别启停状态变化频繁的企业，再叠加一条基于变更时间的增量策略，但本素材只展示全量这一条。

第四阶段：监控与告警

在轻易云的运行监控里，盯两个指标：单次拉取的记录数是否与源系统当日币别总数一致；连续失败次数。币别同步失败不会立刻爆业务，但会在某个深夜报表作业里炸出来。

踩坑复盘

典型错误是分页参数写死在请求里。page 字段如果被配置成定值 1，第二天同步出来就永远是同一页。稳妥的做法是交给轻易云的分页循环机制，由平台自动翻页。
idCheck 千万别关。币别档案可能因为源系统重推而产生重复，关掉幂等检查后，中间层会出现"同编码多行"，下游引用策略会随机命中一条，排查起来极其痛苦。
目标端"写入空操作"不要当成配错。第一次看到这个配置，新人工程师会怀疑自己漏配了字段。实际上这是轻易云"中间层收口"的标准模式——目标适配器本身不映射业务字段，数据落到平台自有的中间表。
调度时间不要和源系统备份窗口撞车。某次客户现场，币别同步卡在凌晨 3 点（源系统在做数据备份），后来把 cron 调到 2:59，问题消失。
币别编码命名规范要在源头对齐。领星ERP 这类目标系统对币别编码有严格的字符校验（通常要求大写字母），如果源系统有 cny 这种小写编码，建议在轻易云的字段映射里加一步转换，而不是指望目标系统自动转。

适用场景与不适用场景

适用：币别档案量不大（数百条以内）、变更频率低、需要被多个下游策略统一引用的场景；以及希望把"基础资料"和"业务单据"解耦的多系统集成架构。

不适用：源系统币别频繁新增且需要实时同步到目标业务系统的场景；以及源系统币别字段与目标系统差异巨大、必须逐字段定制映射的复杂场景——后者更适合走物料级编码映射集中管理。