工作流01

article/2025/8/25 16:37:14

工作流 workflow

18.1 状态机解决流程问题

工作流：就是一个可以处理复杂情况的状态机。

例如，员工请假这个流程：首先员工提交请假申请，假设有项目经理进行审批，审批有两种结果：通过或者拒绝。

实现上面这个需求：

1创建一张请假表，表中有员工的 id，请假的天数、请假的理由、项目经理的 id、请假的状态 status。

2当员工请假的时候，就自动向这张表中添加一条记录。

3然后，当项目经理登录到 OA 的时候，就来这张表中查询自己需要审批的请假申请，查到之后，可以选择批准或者拒绝。

4接下来，员工登录之后，就可以查询到自己的请假申请的审批结果。

在这样的实现思路中，请假的流程我们是通过 status 这个字段来控制的。例如：

●status=0 表示待审批

●status=1 表示审批通过

●status=2 表示拒绝

上面这个例子，status 就是状态码，通过这个字段的值来控制流程的状态，这种方式我们可以称之为使用状态机来解决流程问题，但是，这种思路，只能解决非常简单的流程问题。

18.2 一些复杂的流程

报销审批流程

大区经理审批

财务审批

提交报销申请

部门经理审批

自动打款

结束

一审批不通过,用户重新提交申请一

一审批不通过,用户重新提交中请

在这个流程中，已经没法使用 status 去描述这个请假走到哪一步了。如果非要用 status，那么 status 可能会有很多取值：

●0：表示员工提交报销申请

●1：表示部门经理审批通过

●2：表示部门经理审批不通过，员工需要重新提交

●3：表示大区经理审批通过

●4：表示大区经理审批不通过

●。。。

笔记本电脑生产流程

一审批不通过,重新设计

设计一台笔记本电

准备生产线

经理审批

载入生产图纸

脑

(子流程)

开始

生产屏幕

等待准备工作

完成

组装笔记本

生产键盘

结束

生产主板

这个流程中，不仅有串行任务，也有并行任务。虽然技术上来说，status 也还能做，但是，用 status 字段去描述这个流程，会非常非常复杂。

18.3 三大工作流

三大主流工作流，只要掌握其中一个，另外两个可以非常容易的上手。

最早的工作流是 jBPM，可以目前市面上大部分工作流的共同祖先。

●Activiti：当 jBPM 发展到 jBPM4 这个版本的时候，内部发生了分歧，然后一波人出来单干，基于 jBPM4 开发出来了 Activiti5；留下来的人，继续开发 jBPM5 的时候，几乎完全重写了 jBPM4 的代码。目前 Activiti 的设计侧重于云，即更靠拢 Spring Cloud、Docker、K8s 等。

●Flowable：Activiti5 在发展了一段时间之后，又从中分离出来一个团队，开发出来了 Flowable。Flowable 目前的核心思路还是做一个功能非常非常完善的流程引擎工具。除了常用的最最基本的工作流之外，Flowable 还提供了很多扩展点。

●Camunda：Activiti5 发展没多久，从 Activiti5 中分离中的团队，开发的 Camunda。在这三个主流的流程引擎中，Camunda 是最为轻量级的一个，如果我们的系统，当用户在使用的过程中，需要动态的绘制流程图，那么可以使用 Camunda，这是一个小巧的工具，可以非常的方便的嵌入到我们自己的系统中。Camunda 还提供了一个 bpmn.js 的工具，可以非常方便的实现流程图的绘制。

18.4 流程图

工作流执行的基础是流程图。

一个完整的流程，要干嘛，先得画出来一个完整的流程图。

上面介绍了三种不同的工作流，那么三种不同的工作流的流程图绘制方式是否一样？

其实，流程图的绘制，有一套统一的标准：BPMN（Business Process Model And Notation），中文译作业务流程模型和标记法。

BPMN 就是一套图形化表示法，用图形来绘制、梳理业务流程模型。就是说，BPMN 其实是一套非常古老的流程图规范，Activiti、Flowable 以及 Camunda 都是支持这个规范的。所以，无论使用哪一个流程图，都可以依照 BPMN 规范去绘制流程图。

虽然 BPMN 大家都支持，但是，在具体的使用细节上，不同的流程引擎还是有差别的。

18.5 BPMN 流程图绘制规范

一审批不通过,重新设计

设计一台笔记本电

准备生产线

经理审批