如何用.NET开发一套实用的飞书考勤系统?
摘要:去年给公司做 HR 系统选型,最终选择了飞书考勤。但用了两个月后发现——原生功能再强,也架不住企业那些奇奇怪怪的业务规则。 比如:我们公司的请假审批要过三级(直属领导→部门负责人→HR),但飞书考勤的审批流只支持两级。还有,我们的薪资系统需
去年给公司做 HR 系统选型,最终选择了飞书考勤。但用了两个月后发现——原生功能再强,也架不住企业那些奇奇怪怪的业务规则。
比如:我们公司的请假审批要过三级(直属领导→部门负责人→HR),但飞书考勤的审批流只支持两级。还有,我们的薪资系统需要实时同步考勤数据做工资计算,但飞书没有开放这种级别的 API 集成。
最后只能自己开发一个中间层,把飞书考勤和内部系统打通。这篇笔记就是这段时间踩坑总结下来的。
如果你也在做类似的事情,这篇文章能帮你避开几个坑。
系统架构设计
整体架构
在动手写代码前,先想清楚系统怎么搭。我们的架构是这样的:
flowchart TB
subgraph "内部系统"
A[HR 审批系统]
B[薪资系统]
C[考勤管理系统]
end
subgraph "中间层"
D[Mud.Feishu SDK]
E[业务服务层]
F[数据同步服务]
end
subgraph "飞书"
G[飞书开放平台 API]
H[飞书考勤系统]
end
A --> E
B --> F
C --> D
D --> G
E --> D
F --> D
G --> H
H --> G
style D fill:#e1f5ff
style H fill:#fff4e1
为什么要加中间层?
解耦:内部系统和飞书解耦,飞书 API 变了不用改核心业务代码
数据转换:两边数据结构不一样,中间层负责转换
统一认证:令牌管理、重试、限流这些脏活交给 SDK
灵活扩展:以后要对接其他系统(比如钉钉),加一层适配就行
数据流转
sequenceDiagram
participant 员工
participant 内部系统
participant 中间层
participant 飞书API
participant 飞书考勤
员工->>内部系统: 发起请假申请
内部系统->>中间层: 写入飞书考勤
中间层->>飞书API: CreateUserApprovalAsync
飞书API->>飞书考勤: 保存审批信息
飞书考勤-->>飞书API: 返回结果
飞书API-->>中间层: 返回审批ID
中间层-->>内部系统: 保存 OutId 映射关系
内部系统-->>员工: 显示提交成功
Note over 飞书考勤,内部系统: 审批流程
飞书考勤->>飞书API: 审批状态变更
飞书API->>中间层: Webhook 事件推送
中间层->>内部系统: 同步审批状态
内部系统->>内部系统: 更新内部审批状态
内部系统-->>员工: 通知审批结果
Note over 内部系统,飞书考勤: 薪资计算
HR系统->>中间层: 查询考勤统计
中间层->>飞书API: QueryUserStatsDataAsync
飞书API->>飞书考勤: 查询统计数据
飞书考勤-->>飞书API: 返回统计结果
飞书API-->>中间层: 返回数据
中间层->>中间层: 数据转换和计算
中间层-->>HR系统: 返回考勤数据
HR系统->>HR系统: 计算工资
快速上手
飞书开放平台配置
先说重点——权限别漏了。第一次开发时我漏配了 attendance:approval 权限,搞了一下午才发现是权限问题。
