金蝶组装拆卸子品同步到 MySQL：单策略实战教程

这个策略解决什么问题

在某制造企业的供应链场景里，金蝶云星空里跑着组装拆卸单据，下游的 MySQL 数据仓库和分析系统需要拿到这些单据的子品明细做成本核算与库存归集。问题在于：组装拆卸单的子品行变更频繁，靠人工导出不现实；直接对金蝶接口高频轮询又会拖慢源系统。我们用轻易云数据集成平台（Qeasy）承接这一策略：源端按 8 分钟一轮的节奏拉取子品，落到 MySQL 后再做下游分发。

数据流向与字段映射

数据流向为：金蝶云星空 → 轻易云集成平台（中间层）→ MySQL。源端调用金蝶的 executeBillQuery（POST，QUERY 类型）按单据号 FBillNo 与子品行 FSubEntity_FDetailID 过滤增量；目标端在 MySQL 上以 batchexecute 批量写入，主键 id 参与幂等校验。

关键字段对照表如下：

表头和表体里出现的 FSubEntity_FDetailID 与 FEntity_FEntryID 命名容易让人混淆，配置映射时务必在轻易云里集中管理，避免下游脚本里再散落一遍。

在轻易云上如何配置

进入轻易云数据集成平台后，这条策略本质是一个「源查询 → 目标写入」的链路，配置要点有四：

1. 源端连接器：选金蝶云星空，认证按公有云租户配置；接口选 executeBillQuery，请求体里把 FBillNo 与 FSubEntity_FDetailID 暴露为可注入变量。autoFillResponse 保持开启，省去手工拼字段。
2. 目标连接器：选 MySQL，api 选 batchexecute，idCheck=true，依赖主键 id 做幂等，避免重复写入。
3. 字段映射：在轻易云的映射画布里逐字段对位，库存组织编码用 FStockOrgId.FNumber 这种「对象.属性」写法，源端会自动展开。buildModel 关掉，走真实接口取数。
4. 调度：源端 crontab 写 */8 * * * *，目标端错开 5 分钟写成 3-59/8 * * * *，给源端留出查询与落中间表的时间窗。

实施步骤

我们在客户现场通常把这条策略拆成三段上线：

• 阶段一：增量起点。先用一张「最近 7 天已审核组装拆卸单」做冷启动，把 FBillNo 与子品行 FSubEntity_FDetailID 拉齐写到 MySQL。轻易云里把 number 设为 FBillNo、id 设为 FEntity_FEntryID，idCheck=false 方便首次全量灌入。
• 阶段二：全量触发。冷启动完成后，将源端过滤条件切到「按最后修改时间 ≥ 上次同步时间」，目标端打开 idCheck=true，靠主键 id 去重。这一步是「增量与全量双轨」的常见做法——保留全量补数通道，增量跑日常。
• 阶段三：调度频率。源端 */8 * * * * 每 8 分钟拉一次；目标端 3-59/8 * * * * 错峰写入。运行一周后观察源端接口耗时与 MySQL 写入延迟，再决定是否把轮询收紧到 5 分钟。

踩坑复盘

1. 「对象.属性」写错层级。金蝶字段 FStockOrgId.FNumber 漏写或多写一层点号，源端返回空值。稳妥做法是在轻易云的「编码映射」模块里把这类嵌套字段集中维护，下游不再各自解析。
2. 冷启动时打开幂等校验。首次全量灌入时如果 idCheck=true，会因为目标表为空而被误判冲突。冷启动阶段必须把 idCheck 关上，待首次写入完成后再打开。
3. 源端与目标端同频调度。源端拉取还没结束，目标端就开始写 MySQL，会出现漏数。把目标端 crontab 错开几分钟是最简单也最有效的办法。
4. 表头表体混传。组装拆卸单有表头（FBillNo、FBillTypeID）和表体（FEntity_FEntryID、FNote），一次接口返回后直接落库容易把表体行错挂到表头。我们采用「表头表体分阶段」——先落表头主表，再以 FBillNo 为外键落子表行，MySQL 端用主键 id 做唯一约束。
5. 断点续传靠 FBillNo。8 分钟一轮如果某次失败，轻易云会把本轮 FBillNo 列表记入重试队列；不要在脚本里自己另写补偿，否则会和平台的去重逻辑打架。

适用场景与不适用场景

适用：金蝶云星空里组装拆卸、调拨、其他出入库等带表体子品的单据，需要把子品行增量落 MySQL 做下游分析或库存归集。不适用：需要亚秒级实时同步的现场作业（8 分钟轮询不够用），以及金蝶端没有 executeBillQuery 权限的小规模租户场景。