简介一套支持自定义审批流程的 OA 系统源码面向需要搭建或二次开发办公自动化系统的开发者与团队可帮助企业按自身业务灵活设计请假、报销等审批环节。资源包为 ZIP 格式共 2000 个文件大小 43.54MB核心文件包括 C# 源码.cs、ASPX 页面、前端 JS/CSS以及大量 GIF 图示和文档并拆分为 MobileWeb、Web、DBUtility、BLL、Common 等模块分别对应移动端、Web 应用、数据访问、业务逻辑和公共工具。目前已有 6915 人浏览学习适合作为 OA 开发入门的参考项目。阅读这套源码可理解 OA 系统分层架构与审批流程的可视化配置思路掌握数据库操作、业务规则封装和移动端适配方法资源附带的示例数据、数据库备份和项目文档能帮助开发者快速部署运行并在此基础上扩展组织管理、任务分配、文档流转等功能。 说来也怪前几年聊OA系统大家最常问的是“哪个牌子便宜”“部署快不快”这两年问得最多的变成了“审批流程能不能我们自己改”。我接触过不少企业内部的IT负责人他们普遍反映市面上一堆OA产品功能看着挺全可真要落地卡在审批流上的情况十有八九。要么是请假、报销、合同审批的节点顺序写死了想加一级审批要提工单等厂商排期要么是表单字段没法自定义业务部门想加个“预算归属”栏得求着客服走二次开发。这时候一套完整、开放、可自己设计审批流程的OA系统源码就变得非常值钱。这篇文章我想围绕“源码级OA系统 自主设计审批流程”这件事把一个相对完整的实践路径梳理出来。不管你是公司IT还是要做产品方案的技术负责人或者单纯想研究工作流引擎如何落地的开发者这篇内容应该都能提供一些可以直接拿来用的思路。我会把重点放在审批流的底层设计、部署实操、源码二次开发这几个环节附带我实际踩过的一些坑尽量做到不只是“能跑”而是“好用”。1. 为什么OA系统的灵魂是“审批流可配置”先聊点偏理念的东西但这部分很重要直接决定了你选型的方向。很多传统OA系统的问题不在“功能不够”而在“流程太死”。一个审批流如果写死在代码里那每次组织结构调整、每回签批权限变更都是一场噩梦。1.1 固定审批流OA系统之痛所谓固定审批流说的是流程节点、审批人、条件分支全部在代码层写死用户只能在预设范围内做简单勾选。比如某套系统里请假流程默认就是“员工 → 部门经理 → HR”你想加一个“分管副总”节点对不起后台界面根本没有这个配置入口得改代码。我见过一个真实案例某公司有区域销售团队销售总监下面又分华东、华南两个大区大区经理需要审批本区销售人员的订单折扣。市售OA的审批流只支持按部门层级动态查找上级而他们的组织架构里“大区”并不是一个独立的部门层级结果这个需求整整拖了一个版本迭代周期才上线。业务部门的评价是“上个OA比走审批还慢”。1.2 可配置审批流到底解决了什么“可自己设计审批流程”本质上就是把流程定义的能力从厂商手里交还给使用者。业务部门提出的任何流程变更IT这边只需要定义一个流程模板谁发起的、按什么条件走分支、每个节点谁审批、超时怎么处理、要不要会签——这些全部可视化配置改完立刻生效不再需要发版。从开发角度看这套能力的底层是基于“流程模板 流程实例”的运行机制。模板是静态定义实例是每次真实业务发起的动态数据流。优秀的工作流引擎会把模板和实例彻底解耦让配置和管理分离。这也是我在源码选型时最看重的一点引擎的抽象程度决定了二次开发的成本。1.3 一套合格的源码OA应该长什么样如果你正在选型源码可以在拿到代码后先对照下面这几项做快速检查是否具备流程设计器支持拖拽节点、连线、设置条件分支流程模板是否可以版本化管理修改模板不影响正在运行的流程实例表单与流程是否分离表单字段是否可以动态绑定到流程节点审批动作是否可扩展同意、驳回、转办、加签、撤回等是否支持会签、或签、依次审批等人事场景这几条如果都满足那恭喜你这套系统的架构底子基本是靠谱的后面不管是做演示还是二次开发都有得玩。如果缺比如流程设计器只是一个摆设、表单绑死在前端代码里那源码价值就要大打折扣。2. 审批流引擎的核心原理与源码拆解拿到源码之后第一件事不是着急部署而是先搞懂它的工作流引擎是怎么设计的。我见过太多人部署完就在页面上点点点一旦遇到自定义需求就完全无从下手根子上就是没理解引擎的数据结构和运转逻辑。2.1 流程三要素节点、路由、表单一个审批流的本质可以压缩成三个词节点、路由、表单。节点Node例如“发起申请”“部门主管审批”“HR备案”每个节点承载不同的业务动作和状态。路由Route决定一个节点处理完之后下一步去哪儿。普通场景是顺序流转复杂场景是多条件分支比如“金额5000走总经理审批否则直接到财务”。表单Form承载业务数据比如请假天数、报销金额、合同条款。表单字段往往需要参与路由判断所以表单引擎和流程引擎必须联动。源码层面这三个要素分别对应不同的数据表。流程模板表存储节点和路由的配置信息流程实例表存储每次发起后的实时状态审批记录表则存每个节点的处理人、动作、意见和时间。理解这张表关系图是后续所有二次开发的基础。2.2 审批状态机的设计思路“审批流”从技术上说是一个典型的状态机。每个审批单在任意时刻都处于一个确定状态待提交、审批中、已通过、已驳回、已撤回、已作废。状态之间的跳转由“动作”触发——提交触发“待提交→审批中”同意触发当前节点结束并路由到下一节点驳回则会跳到指定节点或终态。我拿到一套源码之后第一件事就是找到状态机的定义。好的实现会把这些状态和事件集中在一个枚举或者配置类里逻辑清晰、便于扩展。而糟糕的实现则是状态的变更散落在各业务代码里边角情况极多改一处崩三处。特别提醒一点如果你后续要做加签、转办这类高级功能一定要确认源码里的状态机留了口子。有些系统表面上能做加签实际上是生成了一条“虚拟审批记录”不会真实改变流程走向这种就属于“表面支持”遇到复杂需求还是会翻车。2.3 版本管理的必要性流程配置不是静态的今天定义好的流程下周可能就要加一个节点。这里就有个核心概念流程版本。打个比方流程模板是“图纸”流程实例是“按图纸造的楼”。你修改了图纸已经建好的楼不会也不能自动跟着变。所以成熟的OA系统在做流程设计时每次修改都会生成一个新版本新发起的审批单走新版本历史审批单继续按老版本流转直到全部办结归档。在源码里这个机制通常表现为流程模板表带一个version字段流程实例在创建时快照当时的模板ID和版本号。我建议你在配置流程时养成发布前确认版本的习惯不然测试环境改了一次生产环境还是老流程排查起来特别费劲。3. 源码部署与自定义审批流的完整实操理论聊完进入正题。我以下面这套我实际跑过的技术栈为例展开实操后端采用Java Spring Boot MyBatis工作流引擎基于Activiti二次封装前端是Vue2 Element UI。如果你的源码不是这个技术栈思路可以照搬命令类细节需要自行调整。3.1 环境准备数据库、后端、前端三步走第一步准备数据库。大部分OA源码都会提供初始化SQL脚本里面会包含组织机构表、用户表、角色表、菜单表以及流程引擎相关的十几张表。执行时要注意数据库版本和字符集我建议统一使用UTF-8MySQL 5.7以上避免出现中文乱码这类基础问题。mysql -uroot -p init_oa.sql mysql -uroot -p add_demo_data.sql执行完建议马上确认一下是否生成了流程引擎的核心表比如ACT_RU_TASK运行时任务表、ACT_HI_PROCINST历史流程实例表。如果这些表一个都没有说明初始化脚本可能没有包含工作流引擎部分要回源码里找是不是漏了模块引入。第二步启动后端服务。以Spring Boot项目为例需要修改application.yml里的数据源配置。spring: datasource: url: jdbc:mysql://localhost:3306/oa_demo?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghainullCatalogMeansCurrenttrue username: root password: your_password activiti: database-schema-update: true history-level: full db-identity-used: false这里有个细节database-schema-update: true表示启动时自动建表或升级表结构第一次启动建议开启后续稳定运行后建议改成false或者validate防止误操作改动表结构。第三步启动前端。Vue项目常规操作npm install npm run dev前端界面起来之后用管理员账号登录大概率在“系统管理”或“流程管理”模块能看到流程设计器入口。3.2 可视化配置先跑通一条真实业务流部署完成之后不要急着写代码先用系统的可视化设计器把一条真实业务流跑通这会帮你检验系统能力边界。我建议拿“员工请假”练手因为它天然具备条件分支的典型特征。进入流程设计器拖出一个“开始事件”连到“填写请假单”任务节点再连到“部门经理审批”然后从这个审批节点拉出两条条件分支请假天数小于等于3天直接到“结束”大于3天加一个“总经理审批”再到结束。每个审批节点旁边再把审批人设置为“发起人的直属上级”或者指定角色这样一条标准流程就成型了。现在大部分源码级OA的设计器都支持直接配置节点属性。重点检查两件事一是条件分支的表达式是否支持表单字段比较比如days 3二是指定审批人时能否按发起人动态查找上级。这两点都支持的话基本能覆盖90%的常见业务场景。配置完成后保存并发布流程。然后去发起一个新的请假申请分别尝试提交3天以内和3天以上的申请验证分支是否正常走通。这是最核心的冒烟测试也建议你以后每次调整完流程都做一遍。3.3 二次开发实战自定义一个审批动作如果可视化配置解决不了你的需求那就进入源码级定制。我从实际经验出发挑一个典型诉求来讲新增一个“知会”动作。“知会”的意思是不需要对方审批但要让对方看到这个单据的流转进度。在数据库层需要新增一个审批记录类型标记比如通过type字段区分“审批”“知会”“加签”。在代码层核心要改三块定义动作枚举、实现动作处理逻辑、前端审批按钮区域增加入口。动作枚举在后端类中类似这样的定义public enum ApprovalAction { AGREE(agree, 同意), REJECT(reject, 驳回), TRANSFER(transfer, 转办), CC(cc, 知会); private String code; private String desc; }真正的逻辑核心在服务层。知会的实现思路其实很简洁拿到当前流程实例ID往流程实例变量中记录一批“知会人”的工号列表。等流程每次到达新节点、状态发生流转时系统把动态待办列表和知会列表合并查询知会人就会在“我知会的”列表里看到这张单据的最新状态。public void ccTask(String processInstanceId, ListString ccUserIds) { runtimeService.setVariable(processInstanceId, ccUsers, ccUserIds); }前端按钮就简单了在审批操作栏加一个“知会”按钮弹出选择人员弹窗选中后调用后端接口把参数传过去刷新列表即可。这块前后端动的地方不多属于比较典型的低成本高价值二次开发。3.4 活体测试与流程发布代码改完之后务必在测试环境把三类典型场景全部跑一遍正常路由、驳回后重新提交、多实例会签。尤其是驳回场景很多自定义动作在驳回逻辑里漏了状态回滚容易造成“审批单已经驳回了知会人还能看到待办”这种数据不一致问题。测试通过后发布到生产。如果你的系统部署了多套环境记得把数据库脚本纳入版本管理改了什么表、加了什么字段都要有完整的变更记录。这个习惯关键时刻能救命。4. 常见问题与排查技巧实录这一节我梳理几类实际运行中最高频的问题基本属于“没踩过不算搞过OA”的经典坑我把排查思路一并写出来。4.1 流程实例卡住、待办消失不见现象很典型上一节点审批人点了同意下一节点的待办列表却刷不出来。排查时我建议按顺序做三步先查流程实例当前节点SELECT * FROM ACT_RU_TASK WHERE PROC_INST_ID_ #{processInstanceId}看当前活跃任务在哪个节点。再查审批记录表确认上一个节点的完成动作有没有正确触发。最后查ACT_RU_EXECUTION看流程执行对象是不是走到了异常分支。这套组合拳基本能定位90%的“卡单”问题。最常见的根源是监听器里抛了异常事务回滚后节点状态没推进且错误信息被上层吞掉了。建议在你的全局异常处理器里把流程推进相关的异常单独记录日志做好告警。4.2 会签任务的并发与数据一致性会签意味着多个审批人同时处理同一个任务节点这时最容易出现“最后一个节点处理完了但流程没走”、或者“一个人驳回后其他人仍在审批”的并发问题。源码里如果用的是Activiti的multi-instance特性它本身支持同时满足或驳回即终但这依赖于对nrOfCompletedInstances和nrOfActiveInstances循环条件的正确判断。遇到会签流程推进异常优先检查流程模板里多实例参数配置是否正确重点核对结束条件completionCondition的表达式。4.3 流程模板修改之后的历史数据怎么办前面说过流程模板有版本控制。实操中经常遇到的是改了流程业务方问“之前的单子怎么还在走老流程”“能不能让历史单据按新流程继续审批”操作上必须明确一个原则正在流转中的实例永远走它发起时的模板版本。强制让存量实例绑定新模板极容易因为新旧节点、审批人字段不匹配而导致数据错乱。如果你确实需要让某些历史单据“无缝切换”到新流程正确做法是在代码里做实例迁移脚本逐条变更当前任务节点并做好每个节点的审批人映射而不是简单粗暴地覆盖模板ID。这个迁移操作我建议安排在业务低峰期且必须有数据库全量备份兜底。4.4 源码二次开发中常见的几个坑第一个坑是直接改工作流引擎的表结构。引擎表的关联关系非常紧密尤其Activiti这类成熟引擎很多API会直接按表结构查询随意加减字段很容易造成引擎内部API查询报错。我的建议是引擎表结构一概不动需要扩展信息就放到业务自己维护的扩展表里通过业务ID或者流程实例ID关联。第二个坑是忽略权限模型。有些同学拿到源码上手就把审批人写死成“员工12345”流程是跑通了但组织架构一变这个节点就成了僵尸节点。正确做法是走源码既有的“身份模型 关系解析器”让审批人按照发起人部门、角色动态获取。第三个坑是流程大而全导致性能劣化。我见过有人在一条流程上挂了几十个节点和上百条条件分支发起单子的时候接口响应直接飙到数秒。流程不是越复杂越好能用3个节点讲清楚的流程不要拆成8个。配置前先在纸上画一下节点图比在系统里堵半天再删强太多。5. 这套系统后续还可以怎么扩展流程能自定义只是OA系统的基础能力真正拉开体验差距的是它能否支撑更聪明的审批。从源码层级来看有几个方向非常值得投入精力。第一是消息通知集成。源码默认一般只做站内待办可以扩展接入企业微信、钉钉、飞书的消息机器人审批人不用登录OA就能收到待办提醒。实现上只要把流程事件监听器和消息推送服务对接好体验提升立竿见影。第二是审批时效分析。基于流程历史表做数据统计比如每个节点平均停留时间、各部门超时单据数量能帮管理层持续优化审批效率。这是典型的低成本高价值功能做出来之后业务部门对IT的口碑会明显改善。第三是数据权限隔离。当公司有多个独立事业部的时候A部门的流程模板不应该出现在B部门的菜单里。你可以在现有流程模板表上增加可见范围字段再通过数据权限拦截器控制前端展示从源码层面完整支持这种多租户场景。按照我个人的习惯做这类二次开发时会先在本地建一个独立的Git分支每次改动尽量小步提交注释写清楚“为什么这么改”。几年下来回头看这些注释比代码本身更有价值。如果你也是刚接触OA源码建议先用假数据多玩一阵子系统把节点、分支、表单、权限这些东西的联动关系摸透再动手改代码省得改到一半发现理解偏了返工。希望这篇文章能帮你少走一点弯路。本文还有配套的精品资源点击获取