供应商账号同步实战：从钉钉审批到 MySQL 主数据的单一策略落地

这个策略解决什么问题

某零售集团的供应商付款流程跑在钉钉宜搭上，财务每次都要把「创建供应商」审批单里的银行账号、账户名称、开户行再人工录入 MySQL 对账系统，重复劳动且月底对账极易出错。我们用轻易云数据集成平台承接了一条单一策略：把钉钉上审批通过的「创建供应商」单据，增量写入 MySQL 的供应商账号表，让审批流结束即产生可用对账数据。这一条策略看似只是单据搬运，却是后续银企直连、月度对账自动化的基础。

数据流向与字段映射

数据流：钉钉宜搭流程实例（增量）→ 轻易云中间层（过滤、空值兜底、编码映射）→ MySQL supplier_account 表。

关键字段对照：

在轻易云上如何配置

源端选「钉钉」连接器，API 用 v1.0/yida/processes/instances 的 QUERY 动作，把分页大小设为 50、应用 ID 与系统令牌走凭证管理，请求体里通过 searchFieldJson 限制 instanceStatus=COMPLETED 且 approvedResult=agree，并以「创建时间范围」做增量。

目标端选「MySQL」连接器，动作 EXECUTE，main_sql 写成一段标准化的 INSERT 模板，字段占位符用轻易云的 <{字段名}> 语法一一对应。idCheck 打开，让平台按 source_Id 判定存在性，避免重复创建。

映射层采用「编码映射集中管理」的模式：把钉钉的支付方式选项维护到轻易云的全局编码集合里，未来目标端编码体系变了，只改一处映射，不必动 SQL。空值兜底用 _function 表达式在映射层处理，SQL 保持干净。

实施步骤

第一步先做「增量起点」：在源端 metadata 里把 createFromTimeGMT 从固定值改成 {{LAST_SYNC_TIME|datetime}}，实现真正增量；首次上线前手工回灌一次历史数据。第二步做「全量触发」：用一次性的全量回刷脚本把存量审批单补齐到目标表，同时把 LAST_SYNC_TIME 锚定到上线时间点。第三步上线「错峰调度」：源端 crontab 设在 20 1-8 * * *，目标端设在 55 1-8 * * *，两端错开 35 分钟，给对账系统留出事务提交与索引更新的窗口。第四步接入监控告警，看「拉取条数 / 写入条数 / idCheck 命中条数」三个指标，任一指标偏离基线就告警。

踩坑复盘

第一，空值兜底写在 SQL 里是典型错误。某次客户把 case when 直接拼到 main_sql 里，结果账号名称带单引号就把整条 SQL 截断了。稳妥做法是用 _function 在映射层做兜底，SQL 只接干净的参数。

第二，idCheck 必须按业务唯一键配。一次我们图省事用了自增 id，结果同一审批单重跑时反复插入新行。正确做法是用 source_Id（即 processInstanceId）作为业务唯一键去重。

第三，子表数据容易漏掉。钉钉「付款信息」是子表 tableField_ks8du8cn，如果忘了开 buildModel，所有账号会被合并成一条。配置子表展开后，要用子表路径语法逐行生成账号记录。

第四，增量起点用固定时间是常见翻车点。客户最初把 createFromTimeGMT 写死成上线日期，跑了一周后做了一次数据修复，结果修复数据被漏掉。改用 {{LAST_SYNC_TIME|datetime}} 之后，平台会自动接续。

第五，源端过滤条件别只写在脚本里。AfterSourceInvoke 脚本里过滤虽然灵活，但拉取阶段已经把无效数据带回来了，浪费配额。尽量把 instanceStatus 和业务类型条件下沉到 searchFieldJson，从源头过滤。

适用场景与不适用场景

适用：审批即主数据、源端单一且字段稳定的供应商/客户主数据同步；需要按业务唯一键去重、对账回写明确的场景。不适用：源端字段频繁改动、子表结构未稳定、需要复杂合并冲突规则的场景——这些更适合走事件驱动的实时集成或双向同步方案。