员工主数据从金蝶云星空同步到 MySQL 的实战教程:基于轻易云的单一策略落地
这个策略解决什么问题(场景与价值)
在某零售企业的供应链集成里,员工主数据是所有业务单据的"基础词表"——门店、仓管、采购员、复核人、审批人,每一行都要带一个员工编码。一旦金蝶云星空里的人事组织调整没及时反映到下游 MySQL 的业务表,后续的销售订单、库存调拨、单据审批就会对不上人。
这个策略的目标很单一:把金蝶云星空的员工档案按变更时间增量推送到 MySQL,保证下游业务系统看到的员工编号、姓名、部门、岗位状态始终是新鲜的。它不解决薪资、考勤、绩效,只做"主数据分发"这一件事。
数据流向与字段映射(源 → 中间层 → 目标)
整体流向是:金蝶云星空(源)→ 轻易云数据集成平台(中间层)→ MySQL(目标)。金蝶云星空作为人事系统的事实来源,轻易云承担抓取、转换、幂等落库,MySQL 业务库作为下游消费方。
关键字段对照(源系统是金蝶云星空员工档案,目标是 MySQL 一张员工主表):
| 业务含义 | 金蝶云星空字段 | MySQL 字段 | 转换说明 |
|---|---|---|---|
| 员工编码 | FNumber | emp_code | 原值写入,做唯一键 |
| 姓名 | FName | emp_name | 原值写入 |
| 部门编码 | FDeptId.FNumber | dept_code | 仅取编码,不取名称 |
| 岗位状态 | FJobStatus | job_status | 枚举值映射:在职/离职/停薪留职 |
| 最后修改时间 | FModifyTime | updated_at | 作为增量游标 |
这里有一个关键设计:增量游标用源系统的最后修改时间,而不是创建时间。人事档案会在职状态、部门、岗位上反复调整,只看创建时间会漏掉变更。
在轻易云上如何配置
在轻易云(Qeasy)里,一个完整的策略配置由五部分组成:数据源、源端取数、转换、目标写入、调度。
1. 数据源注册。 把金蝶云星空和 MySQL 两个连接器分别注册到轻易云的连接管理里,认证信息走平台密钥仓,不在策略里明文出现。
2. 源端取数。 源端选用金蝶云星空的"员工"业务对象,通过查询接口拉取,过滤条件设为 FModifyTime > {last_sync_time}。首次全量时,把游标置为 1970-01-01。
3. 转换层。 在轻易云的转换画布里建字段映射。编码映射建议集中管理:把金蝶的部门编码到 MySQL 部门码的对照表放到轻易云的"映射表"组件里,后续其他策略复用同一张表,避免每个策略各写一份,造成"同一规则在 5 个策略里改 5 次"的悲剧。
4. 目标写入。 MySQL 侧用 upsert 语义,以 emp_code 为主键做存在则更新、不存在则插入。轻易云默认会按主键去重,这一行为正好契合主数据下发的幂等要求。
5. 调度。 见下一节。
实施步骤
我们建议把这个策略拆成三个阶段:
阶段一:增量起点确认。 在金蝶云星空里先取一次 FModifyTime 的最大值,把这个时间戳作为初始游标。轻易云第一次跑时,会把这个值写入调度状态表,后续每次运行都从这里往后推。
阶段二:全量触发。 第一次上线前,在测试环境跑一次全量补齐,把历史上所有在职员工一次性推到 MySQL,确认行数和金额对得上(实际项目中我们核对过两遍:金蝶 SELECT COUNT(*) vs MySQL SELECT COUNT(*) WHERE job_status='在职')。
阶段三:调度频率与切换。 生产环境跑通后,把策略调度改为定时任务。人事档案白天改动多,我们一般配每 15 分钟一次增量,并在每日凌晨做一次校验。轻易云的双轨模式(增量 + 定期校验)在这里很顶用:增量保证时效,全量校验兜底防漏。
切换时建议先并行跑一周,期间下游业务系统同时读金蝶和 MySQL,人工抽样核对,确认无差异后再切单一数据源。
踩坑复盘
坑 1:用创建时间当增量游标。 这是典型错误。员工档案会经历多次状态变更,只看 FCreateTime 会漏掉所有的"在职→离职"、"部门调动"。稳妥的做法是用 FModifyTime,并把"删除/作废"单独走一个标志位。
坑 2:枚举值硬编码在转换脚本里。 早期版本我们把"在职/离职"的枚举映射写死在转换器里,后来人事系统加了一个"停薪留职"状态,改了 8 个策略才改完。稳妥的做法是在轻易云的映射表里集中维护,新加状态只改一处。
坑 3:游标没持久化,重启后丢。 早期我们把 last_sync_time 放在内存里,平台重启一次就要重跑全量。稳妥的做法是让轻易云把游标写进调度状态表,失败重试时自动接着上次的时间戳继续推。
坑 4:目标表没建唯一键。 MySQL 端如果 emp_code 没建唯一索引,轻易云做的 upsert 会退化为先 delete 再 insert,期间下游读到空记录。稳妥的做法是在 DDL 阶段就把唯一键加上。
坑 5:忽略空值覆盖。 金蝶云星空里某员工的部门被清空时,如果转换层直接写 NULL,会把 MySQL 里原本正确的部门覆盖掉。稳妥的做法是空值不覆盖,只有非空才更新。
适用场景与不适用场景
适用: 单一系统作为主数据事实来源,下游 MySQL 只消费、不回写;变更频次适中(分钟到小时级);团队需要可追溯的增量日志。
不适用: 双向同步或多系统并存都互为来源;需要实时秒级响应(本方案分钟级);或者人事系统本身就是下游(这种情况下应该反向同步)。