离职人员账号禁用告警:MySQL 多源汇总到钉钉消息推送的实战集成方案

这个策略解决什么问题(场景与价值)

某零售/制造企业里,HR、四化系统、金蝶、MOM、报价系统各自维护一份人员状态,「员工已离职、但对应系统的账号没禁用」是 IT 团队最常被审计挑出来的一类问题。过去靠人工每天跑 SQL 对比,漏报率高、追责链断。我们用轻易云数据集成平台(Qeasy)承接了一条策略:从 MySQL 多源联查出「账号已禁用但钉钉未同步」的离职人员,按条拼成 Markdown 消息,推到钉钉指定接收人。价值在于把「人找数据」变成「数据找人」,告警口径统一、可追溯。

数据流向与字段映射(源 → 中间层 → 目标)

整体流向是 MySQL → 钉钉。源端用 UNION ALL 把四化、金蝶、MOM、报价、离职人员五类记录汇总成统一结构;中间层在轻易云里完成字段名归一;目标端调钉钉 topapi/message/corpconversation/asyncsend_v2,以 Markdown 形式推送。

目标字段	源字段/规则	映射类型	说明
robotCode	钉钉机器人编码	CONSTANT	轻易云里直接写常量,集中放平台参数区,便于轮转
userIds	`{{userid}}`(SQL 内 JSON 数组)	DIRECT	按系统类型分别指定接收人,避免「一刀切群发」
msgKey	`sampleMarkdown`	CONSTANT	钉钉 Markdown 消息模板
msgParam	`_function CONCAT(...)`	TRANSFORM	拼接 Markdown JSON 字符串
msgParam.title	`IT管理-账号通知`	CONSTANT	消息标题
msgParam.text.system	`{{system}}`	DIRECT	来源系统标签
msgParam.text.时间	`now()`	TRANSFORM	推送时即时写入
msgParam.text.工号	`{{job_number}}`	DIRECT	员工工号
msgParam.text.姓名	`{{name}}`	DIRECT	钉钉侧姓名
msgParam.text.部门	`{{dept_tree_name}}`	DIRECT	部门树名称
msgParam.text.职务	`{{title}}`	DIRECT	职务
msgParam.text.系统账号	`{{user_name}}`	DIRECT	各业务系统登录名
msgParam.text.系统姓名	`{{real_name}}`	DIRECT	各业务系统显示名

注意,本策略不涉及 _findCollection 编码映射,所有映射都是 DIRECT / CONSTANT / TRANSFORM,这是「告警类同步」与「主数据同步」的最大区别。

在轻易云上如何配置

源端连接器:选 MySQL 的「WebAPI select」模式,把 main_sql 原样贴入。:limit 与 :offset 留作分页参数,绑定到 main_params 的入参字段,轻易云会在调度时自动注入。
目标端连接器:选钉钉「机器人/工作通知」API,robotCode、机器人编码用常量填入,不要散落在策略里——轻易云常见的应对模式之一就是「编码映射集中管理」,把这类常量放到平台级参数,策略只引用变量。
字段映射:除了 msgParam,其他都是 DIRECT。msgParam 用「表达式」类型,选 _function CONCAT,把多个 {{}} 变量与固定字符串拼成 JSON。
限流与分页:每条子查询里那个 < N 的 count 判定要保留,它保证单次推送不超过钉钉限频;轻易云再叠加 :limit :offset 做二次分页兜底。
可观测:在轻易云「运行日志」里把 system、job_number 标成关键字段,告警出问题能直接定位到是哪个系统哪条记录。

实施步骤

我们建议分三阶段推进,增量起点 → 全量触发 → 调度频率双轨运行:

第一阶段(增量起点,跑近 1 小时窗口):把源 SQL 里离职人员子查询的 date(update_time)>=CURDATE() and hour(update_time)=hour(now()) 当作「增量锚点」。第一次上线时,先把 update_time 窗口放宽到「近 24 小时」跑一次,验证消息体拼接、接收人列表与钉钉限频是否正常。
第二阶段(全量触发,核对基线):用轻易云的「手动触发」跑一次全量,逐条核对钉钉收到的 Markdown 是否字段完整、转义正常(JSON 内引号、双换行)。这里最容易翻车的是 Markdown 里的 \n 与 \n(两个空格 + 换行)被平台吃掉,务必在钉钉端真机验证。
第三阶段(调度频率):源端 28 12,18 * * 1-6,目标端 30 12,18 * * 1-6,工作日午、晚各一次。源比目标早 2 分钟,是轻易云里常用的「表头表体分阶段」思路的轻量化版本——给源端预留执行时间,目标端只负责推送,职责清晰,失败时也能区分是「查不到」还是「推不出」。

踩坑复盘

UNION ALL 各分支字段数对不齐,运行期才报列数不一致。稳妥的做法是在 SQL 末尾加一行注释,标注每个分支的标准列宽,并在轻易云「数据预览」里先跑一次,确认 5 个分支都返回 10 列。
JSON 数组里的钉钉 userid 硬编码在 SQL 里,接收人变更要改 SQL。更工程化的做法是把 userid 抽成「按系统类型」的配置表,SQL 用 JOIN 取,轻易云只负责按系统路由。
now() 直接拼进消息体,会出现「告警内容和推送时间不一致」的误会。建议把「事件时间」(源端 update_time)与「推送时间」分开,前者来自源数据,后者用 now(),不要混用。
Markdown 里的中文标点与两个空格的换行符被钉钉服务端转义。测试阶段一定要点开真机看,不要只看日志里拼好的 JSON。
钉钉机器人/应用编码泄露。robotCode 属于敏感凭据,轻易云里建议放进凭据中心,策略只引用变量名,避免日志里明文出现。

适用场景与不适用场景

适用:账号治理、离职流程合规、跨多业务系统的「状态不一致」告警,以及需要把数据库里的告警转成 IM 消息推送给指定责任人的场景。不适用:需要双向同步、需要保留历史版本、需要做编码映射的主数据同步(如物料、客户、供应商)。这类场景请走轻易云的「主数据同步」策略模板。