供应商同步状态回写：MySQL 与金蝶云星空的双向闭环实践

这个策略解决什么问题

供应商主数据落到 MySQL 业务表后，审批、停用、冻结这些状态变更仍发生在金蝶云星空。业务侧经常拿着本地编码去查「这家供应商现在到底能不能用」，结果发现 MySQL 里写的是 3 个月前的状态。我们在一家零售企业的私有化环境里就踩过这个坑——采购下单失败，复盘才发现是供应商在金蝶侧早就被冻结了，MySQL 这边的启用标志没跟上来。

这条策略就是把金蝶云星空的供应商实时状态回写到 MySQL，让业务系统能就近读到「当下」的状态，而不是依赖人工对账。

数据流向与字段映射

整体流向是：金蝶云星空（源）→ 轻易云数据集成平台（中间层，做转换与调度）→ MySQL（目标）。

值得说一句的是，轻易云上把「编码映射」集中放在策略层管理，比散落在各个 SQL 里好维护得多——后续加公司账套、加组织隔离，改一处就够。

在轻易云上如何配置

源端配置用金蝶云星空的 executeBillQuery，做 POST 查询，effect 设为 QUERY。关键点是把 FSupplierId 和 FNumber 同时带出来，因为后面要靠这两个字段做唯一定位。

目标端是 MySQL，用 WebAPI 的 execute 接口，方法 POST。这里有个典型的工程选择：把业务表更新写成 main_sql 这种 otherRequest，由轻易云做参数化绑定，传入 supplier_short_code 和 yn_lock，而不是让源系统一条条推明细过来——既省带宽，也避免大事务。

主请求体 main_params 只做空壳触发，真正的 SQL 走 otherRequest。这是轻易云上一个常见模式：表头表体分阶段，主体结构与具体 SQL 解耦，调字段时不用动整张表 schema。

实施步骤

1. 增量起点：先在 MySQL 里给 basic_supplier_info 的 supplier_short_code 建唯一索引，并把 yn_lock 默认值初始化为 0。
2. 全量触发：第一次跑全量，把金蝶云星空里所有供应商的 FDocumentStatus 都拉一遍，update 到 MySQL。这步建议放在业务低峰期，轻易云的调度支持「立即执行」+「错峰跑批」。
3. 增量与全量双轨：日常按小时跑增量（源 crontab 写的是 3 */1 * * *，目标写的是 5 */1 * * *，差 2 分钟，留出源端到目标端的传输余量）；每周一次全量兜底，覆盖漏单和异常。
4. 校验机制：轻易云上对 yn_lock 字段加值域校验，发现非 0/1 的脏数据直接进异常队列，不污染业务表。

踩坑复盘

• 状态码字典没对齐：金蝶的 FDocumentStatus 是枚举字符串，MySQL 这边早先有人写成了 Y/N。第一版没做映射，跑完后 yn_lock 全是空。稳妥做法是在轻易云的转换脚本里集中维护一份字典，源端和目标端字段值有变化时只改一处。
• 用名称做关联条件：早期版本有人图省事用 FName 去匹配，结果两家供应商重名，直接 update 错行。后面所有回写策略一律强制走 supplier_short_code + company_code 复合条件。
• MySQL 表没建唯一索引：第一次跑全量时因为缺唯一索引，重复跑了 3 次，yn_lock 倒是不会错，但日志里一堆 warning，给排查带来干扰。
• 源端和目标端同时刻跑批：原来两个 crontab 都设在整点，金蝶侧查询慢的时候直接把 1 小时窗口吃掉了。错峰 2 分钟是稳妥的写法。
• company_code 写死在 SQL 里：业务方提了一个新公司账套接入需求，结果 SQL 改了一处漏改另一处，状态只回写到了一半公司。后面在轻易云上把 company_code 提到请求参数里，由调度上下文注入，适配新组织时只改配置。

适用场景与不适用场景

适合供应商状态需要在多个业务系统就近读取、且源系统是金蝶云星空、私有化部署的场景。不适合纯单向物料主数据下发，也不适合对实时性要求在分钟级以内的业务——本策略以小时为粒度，强实时场景请走事件驱动的轻通道。