组织间需求单抛转实战：金蝶云星空 → MySQL OMS 的单一策略同步方案
这个策略解决什么问题
多组织集团里，需求单经常要从发起组织推到承接组织。如果两边直接点对点，后续 BOM、客户编码、状态回写一改就乱。我们用轻易云数据集成平台把这条链路收口成单一策略：源端在金蝶云星空按审核时间增量拉单据，经过映射清洗后落到 MySQL 的 OMS 订单表和订单 BOM 表，所有编码、状态、日期转换集中在策略里维护，可观测、可重跑。
数据流向与字段映射
流向：金蝶云星空（executeBillQuery，POST）→ 轻易云中间层 → MySQL（execute，POST，写入 oms_order / oms_order_bom）。
源端关心的字段：FID（实体主键）、FDocumentStatus（单据状态）、FIsClosed（关闭状态）、FBillNo（单据编号）、FApproveDate（审核日期）、FMaterialId_FNumber（物料编码）、FDemandDate（需求日期）等。这些是金蝶标准字段，做单据头与单据体的查询条件。
落到 MySQL 时，分两张表：
| 目标表 | 关键字段 | 含义 |
|---|---|---|
| oms_order | order_uuid、order_no、order_date、order_status、company_code、is_distribute、is_soa_finish、customer_uuid、order_type、leader、customer_order_no、order_delivery_date、create_by | 单据头，订单级别状态与归属 |
| oms_order_bom | bom_uuid、bom_no、order_uuid、order_no、company_code、part_no、grade_name、pic_no、pic_version、order_num、delivery_date、completed_num、change_status、bom_status、price、eng_bom_id、serial、material_source、if_material | 单据体，行项目物料与交付明细 |
典型映射：FBillNo → order_no，FDemandDate → order_delivery_date，FMaterialId_FNumber → part_no。表头与表体通过 order_uuid 关联，轻易云里的常见做法是「表头表体分阶段」：先生成表头 UUID，再带同一 UUID 写表体，避免行项目孤立。
在轻易云上如何配置
源端配置：API 选 executeBillQuery，方法 POST，主键字段 FID，配合 autoFillResponse 让平台自动展开返回结构。请求体里把增量起点字段（如 FApproveDate）作为筛选条件传入。
目标端配置：API 选 execute，方法 POST，把 main_sql 写成 INSERT INTO oms_order …，把 extend_sql_1 写成 INSERT INTO oms_order_bom …。main_params、extend_params_1 用对象类型承载字段值，参数命名与 SQL 占位符一一对应。
中间映射层：在轻易云里建字段映射表，idCheck 打开避免重复写入。编码映射——比如金蝶物料号到 OMS part_no 的差异——走「编码映射集中管理」，做成可复用字典，方便多个策略共用。
调度配置：crontab 写 */3 * * * *，即每 3 分钟一轮。
实施步骤
第一阶段：增量起点初始化。第一次跑之前，先在金蝶侧取一个历史审核时间作为增量起点（如 T0），写入策略的游标变量，后续每次按 FApproveDate > T0 拉取，T0 由平台自动滚动。
第二阶段：全量补齐触发。上线当天，用人工触发的方式全量回灌一次历史单据，校对两边数量、金额、行项目数；差异不归零不允许切到正式调度。
第三阶段：常态调度 + 双轨兜底。正式调度按每 3 分钟轮询，同时保留一条全量脚本作为应急通道——轻易云客户常见做法是「增量与全量双轨」：增量跑日常，全量用于故障恢复和数据修正。调度频率先稳后调，观察 1–2 周后再视负载调整。
踩坑复盘
1. 表头表体不同步。 只写表头不写表体或反过来，是这里最容易翻车的点。稳妥做法是在策略里把表头和表体打包成一次调度单元，靠同一个 order_uuid 串起来。
2. 编码映射散落各处。 典型错误是把物料编码转换逻辑写在每条策略里，3 个月后一改字段名全乱。所有编码映射抽到轻易云的统一字典里集中管理，新策略直接引用。
3. 单据状态语义不对齐。 金蝶的 FDocumentStatus 与 OMS 的 order_status 不是一个语义，直接 1:1 映射会丢信息。建议在中间层做一次状态翻译表，把「审核中/已审核/已关闭」映射成 OMS 可识别的业务态。
4. 增量起点忘了设。 第一次跑没设增量起点，结果把历史所有单据重拉一遍，目标库主键冲突。稳妥做法：上线前明确 T0，并跑一次 dry-run。
5. 调度频率过高拖垮源系统。 每 3 分钟拉一次在数据量小时没问题，单据一旦上万就会给金蝶造成压力。建议加一个「窗口合并」机制，同一审核时间段的单据合并请求。
适用场景与不适用场景
适用：多组织集团内、需求单需要在发起组织与承接组织之间流转、OMS 侧已有标准订单表与 BOM 表、希望可观测可重跑的中等规模集成。不适用：实时性要求秒级、需要双向冲突合并、源端单据结构频繁变更的场景，那一类更适合走事件驱动或中间库模式。