老板让我搞一个请假审批流程，我一行代码搞定（Java版）
工作流审批功能是办公OA系统核心能力，如果让你设计一个工作流审批系统，你会吗？千万不要小瞧OA内部系统的复杂性，大家可以头脑风暴思考一下实现方案。
要明白工作流审批涉及多个用户的任务流转，多个流程分支跳转，虽然是办公内部系统，但是这个系统并不简单如果没有强大的工作流引擎，难以高效扩展旧流程，难以增加新流程，工作流审批将成为公司所有人的噩梦
但是在使用 activiti开源工作流引擎后，一切痛苦与噩梦均烟消云散~
activiti 支持新增流程非常简单，只需要两步
- 画个流程图
- 搭配前端页面
首先画一个流程图
将文章开头的需求，转化为 activiti 流程图，使用Idea 安装 actiBPM 插件，创建该流程图，文件命名apply.mpmn，实现请假流程的二级审批能力
- 一级主管审批
- 超过3天，二级主管审批。
测试流程图
首先创建工作流引擎，部署流程图
//创建工作流引擎
ProcessEngine engine = ProcessEngines.getDefaultProcessEngine();//RepositoryService用于部署流程图
RepositoryService repositoryService = engine.getRepositoryService();//部署请假流程图
repositoryService.createDeployment().addClasspathResource("processes/apply.bpmn").deploy();
部署流程图，这部分工作一般放在工作流的后台系统，开发创建好流程图以后，上传部署到系统中。无需开发修改代码
repositoryService.createDeployment().addClasspathResource("processes/apply.bpmn").deploy();这行代码负责部署流程图到流程引擎。工作流引擎会解析该流程图文件，创建流程模版，接下来就可以在使用该流程模版，发起流程实例了。
员工zhang3，发起新流程，设置审批人
Map<String, Object> variableMap = new HashMap<>();
variableMap.put("applyUser", "zhang3");
variableMap.put("supervisor", "li4");
variableMap.put("upperSupervisor", "wang5");
员工zhang3 提出请假申请，在发起新流程时，通过OA其他系统，查到zhang3的一级主管是li4，二级主管是wang5，于是设置上审批人。有人疑问，以下变量applyUser等，是系统默认的，还是在哪里指定的？在创建主管审批节点时，指定审批人变量 ${applyUser}
想象一下，如果请假类的流程均可能需要一二级主管审批，是不是可以在发起流程时，统一填充一二级主管 审批人变量。这部分代码是不是就是通用的，新增流程时无需二次修改了。
发起一个新流程
ProcessInstance instance = runtimeService.startProcessInstanceByKey("apply_processor_1", variableMap);
如上代码指定了全流程审批人，发起了一个新流程。有人会疑问apply_processor_1 是什么？在哪里指定的，这是流程模版的 Key，在使用Idea插件画流程图时，需要指定流程图的Key
申请人设置请假天数
TaskService taskService = engine.getTaskService();
Task firstTask = taskService.createTaskQuery().taskAssignee("zhang3").singleResult();taskService.complete(firstTask.getId(), Maps.newHashMap("day", 4));
创建并开启流程实例后，工作流引擎相当于帮你执行了 流程图的 开始节点，然后流程执行到 请假申请节点，此时通过 taskService 查询 zhang3的 处理任务。TaskService是通过第一步ProcessEngine 获取到的，主要用于任务查询。
有人会疑问，为什么要区分创建流程、处理申请人审批任务两个步骤，我们在提请假申请时，只需要提申请一步就完成了。实际上 提请假申请时，系统会帮你创建好流程，然后自动替你完成审批。
为什么工作流引擎要区分为两步呢？所有的流程图都需要经过 开始节点，也都需要结束节点，如此设计方式，可以让工作流引擎的抽象层次更高。它可以在开始和结束时点建立事件通知，维护流程状态的完整性。
接下来，zhang3 通过 taskService完成该任务，并且设置变量 day=4，即请假天数是4天。
一级主管审批任务
Task secondTask = taskService.createTaskQuery().taskAssignee("li4").singleResult();taskService.setVariable(secondTask.getId(), "result1", true);
接下来，zhang3和 领导li4 说，”我家里有事要请假，辛苦4哥审批一下“，领导在自己的审批后台查询 审批任务，查到后，通过了审批任务。
有人会疑问，怎么标识 审批通过和不通过呢？result1 是什么东西？系统默认的，还是在何处甚至的变量? 在流程图上配置的
工作流引擎没有审批通过不通过的概念。当流程上存在 A 和 B 两个分支时，流程图上可以使用排他网关进行分支判定。如请假流程图中，一级审批结果就是一个排他网关。在网关的下游分支上配置如果要走A分支，应该满足哪些条件；走B分支，要满足哪个条件；
而排他网关上并没有配置路由条件。例如在一级主管审批后，流程上设置新的变量 result1，经过排他网关时，A分支 是 #{result1==true} 判定通过，于是走了A分支。工作流引擎负责检查网关的下级分支的条件是否满足，哪个条件满足走哪个分支。
也就是说上一个任务在处理时，并不知道接下来走哪个分支，也没有指定走哪个分支，而是将自己的处理结果放到流程变量中，在排他网关的下游分支条件上根据流程变量进行判断，接下来走哪个分支，这就是工作流引擎对于流程的抽象。
工作流引擎负责驱动流程到排他网关，至于走哪个分支，由分支上的条件决定！这个思维一定要记住哦~
继续剩余的流程
一级主管审批通过后，需要判断是否需要二级审批，这时又有一个排他网关，使用的条件就是 #{day>3}，或者 #{day<=3}
在第2步中，zhang3 申请了 4天的假期，于是走到了二级主管审批页面。二级主管wang5 在审批任务列表中，找到了zhang3的请假申请，然后点击了通过。
Task thirdTask = taskService.createTaskQuery().taskAssignee("wang5").singleResult();
if (thirdTask != null) {taskService.setVariable(thirdTask.getId(), "result2", true);log.warn("用户任务完成，流程ID:{}, 任务名称:{}, id:{}, assignee:{}", thirdTask.getProcessInstanceId(), thirdTask.getName(), thirdTask.getId(), thirdTask.getAssignee(), thirdTask.getDelegationState());taskService.complete(thirdTask.getId());
} else {log.warn("没有查到二级主管审批任务");
}
接下来流程上没有其他审批任务，但是引擎依然会继续驱动流程，如下图中二级主管审批结果通过或拒绝，分别进入到两个不同的终点。
值得一提的是，上面的代码仅仅是各个审批人在处理审批任务时，必要的代码、通用的代码。如审批是否通过这一流程变量，完全可以统一规范，无需二次开发。例如 二级主管审批通过设置了 result2，实际上可以使用 二级主管审批这个节点的id 后缀，如 result_10来代表执行结果，规范以后，流程审批代码更为统一。新增流程模版时，在审批任务节点，审批通过或审批拒绝均不需要再次开发代码。
惊喜的事情是：我们没有开发任何一行流程驱动和分支判定相关的代码。
但是我们依然需要处理前端页面。因为请假申请页面上，不同的假期类型需要的表单参数不同，需要新增前端页面，新增发起流程的后端接口。
相比整体的流程控制代码，这部分开发工作量大大降低，难度更是大大降低。
接下来，我提出一个问题，如果新增一个需求，要求请病假的时候，需要HR审批，你知道如何修改流程图，支持新的处理流程吗?
很简单，在审批通过终节点的前面，再加一个排他网关，判断请假类型== ”带薪病假“，如果条件通过则增加HR审批节点，如果条件不通过，则直接走到 审批通过的 终点。不需要开发一行代码就能支持需求哦~
有了工作流引擎 activiti ,新增和修改流程 都变得非常简单，它帮我们完成了所有的流程驱动和分支判定工作。这就是工作流引擎的价值之一。
如何查看完整的执行流程图
通过流程引擎 ProcessEngine获取HistoryService；通过流程实例id，拿到流程执行的所有节点。执行记录如下图，可完整看到流程执行的完整过程。
List<HistoricActivityInstance> activityInstanceList =
historyService.createHistoricActivityInstance
