title: 01-工作流 workflow
date: 2023-7-19 22:06:43
tags:
- Flowable
状态机解决流程问题
工作流：就是一个可以处理复杂情况的状态机。
例如，员工请假这个流程：首先员工提交请假申请，假设有项目经理进行审批，审批有两种结果：通过或者拒绝。
实现上面这个需求：
- 创建一张请假表，表中有员工的 id，请假的天数、请假的理由、项目经理的 id、请假的状态 status。
- 当员工请假的时候，就自动向这张表中添加一条记录。
- 然后，当项目经理登录到 OA 的时候，就来这张表中查询自己需要审批的请假申请，查到之后，可以选择批准或者拒绝。
- 接下来，员工登录之后，就可以查询到自己的请假申请的审批结果。
在这样的实现思路中，请假的流程我们是通过 status 这个字段来控制的。例如：
- status=0：表示待审批
- status=1：表示审批通过
- status=2：表示拒绝
上面这个例子，status 就是状态码，通过这个字段的值来控制流程的状态，这种方式我们可以称之为使用状态机来解决流程问题，但是，这种思路，只能解决非常简单的流程问题。
一些复杂的流程
报销审批流程
在这个流程中，已经没法使用 status 去描述这个请假走到哪一步了。如果非要用 status，那么 status 可能会有很多取值：
- 0：表示员工提交报销申请
- 1：表示部门经理审批通过
- 2：表示部门经理审批不通过，员工需要重新提交
- 3：表示大区经理审批通过
- 4：表示大区经理审批不通过
- ...
笔记本电脑生产流程
这个流程中，不仅有串行任务，也有并行任务。虽然技术上来说，status 也还能做，但是，用 status 字段去描述这个流程，会非常非常复杂。
三大工作流
三大主流工作流，只要掌握其中一个，另外两个可以非常容易的上手。
最早的工作流是 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 的工具，可以非常方便的实现流程图的绘制。
流程图
工作流执行的基础是流程图。
一个完整的流程，要干嘛，先得画出来一个完整的流程图。
上面介绍了三种不同的工作流，那么三种不同的工作流的流程图绘制方式是否一样？
其实，流程图的绘制，有一套统一的标准：BPMN（Business Process Model And Notation），中文译作业务流程模型和标记法。
BPMN 就是一套图形化表示法，用图形来绘制、梳理业务流程模型。就是说，BPMN 其实是一套非常古老的流程图规范，Activiti、Flowable 以及 Camunda 都是支持这个规范的。所以，无论使用哪一个流程图，都可以依照 BPMN 规范去绘制流程图。
虽然 BPMN 大家都支持，但是，在具体的使用细节上，不同的流程引擎还是有差别的。