如何用.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 权限,搞了一下午才发现是权限问题。
阅读全文