关于java:极简-Java-工作流概念入门

对于 Flowable 松哥曾经更新了好几篇文章了，不过思考到有的小伙伴可能还素来没接触过流程引擎，因而有一些根底的内容我再来和小伙伴们梳理一下。

1. 为什么须要工作流

松哥将之前的文章转发到朋友圈后，有小伙伴评论说始终不了解为什么须要工作流，明天咱们就先来说说这个话题。

假如我有一个销假需要，流程如下：

销假能够提交给我的下属，下属能够抉择批准或者回绝，无论批准还是回绝，都会给我一个告诉。

这个流程比较简单，咱们很容易想到解决方案，不必工作流也能解决，有一个专门的销假表，当 A 要销假的时候，就往销假表中增加一条记录，这条记录的内容蕴含了销假的天数、起因、销假的审批人 B 以及一个名为 status 的字段，这个 status 字段示意这个销假申请目前的状态（待审批、已批准还是已回绝），而后 B 登录零碎之后，在销假表中查问到了 A 的销假信息，而后抉择批准，此时将 status 字段的值改一下就行了。

这个流程很简略，置信小伙伴们都能想到。

然而，这是一个非常简单的流程，对于这样的流程，一般来说也的确没有必要应用工作流，然而事实中，咱们波及到的工作流往往都是非常复杂的，我举个例子，就说报销审批吧，这个可能很多小伙伴都经验过。

小伙伴们看到，这个流程相对来说还是比较复杂的，此时你再用一个 status 字段去形容，就很难说的请到底是怎么回事了。每一步审批，都有可能批准也有可能回绝，回绝并不意味着流程完结，员工批改报销材料之后，还能够持续提交。此时如果还用 status 去形容，那么 status 将有 N 多个值去示意不同的状况，这个保护起来十分不便。

这就简单了吗？非也非也，咱们再来看一个生产笔记本电脑的例子，假如公司研发了一款新型笔记本电脑，整个研发到生产的流程可能是这样：

相比下面两个，这个就更简单一些了，不仅有串行工作还有并行任务，如何去设计这样一个零碎？单纯的通过状态字段去形容显然曾经不够用了，此时咱们就得思考一种通用的、更易保护的计划来实现这样的零碎了，这种通用的、易保护的计划，也就是工作流。

2. 三大工作流

一个比拟早的工作流是 jBPM，这是一个由 Java 实现的企业级流程引擎，是 JBoss 公司开发的产品之一。

jBPM 的创建者是 Tom Baeyens，这个大佬起初来到了 JBoss，并退出到 Alfresco，并推出了基于 jBPM4 的开源工作流零碎 Activiti，而 jBPM 则在后续的代码中齐全放弃了 jBPM4 的代码。从这个过程中也能看进去，jBPM 在倒退过程中，因为意见相左，起初变成了两个 jBPM 和 Activiti。

然而戏剧的是，Activiti5 没搞多久，从 Activiti 中又分进去一个 Camunda，Activiti 持续倒退，又从中分进去一个 Flowable。。。

因为开发 jBPM、Activiti、Camunda 以及 Flowable 的人多多少少有一些关联性，让人不得不猜想意见相左拉一票人进去单干是他们的企业文化。

所以当初市面上支流的流程引擎就一共有三个：

• Activiti
• Flowable
• Camunda

这三个各有特点：

1. Activiti 目前是偏重云，他目前的设计会向 Spring Cloud、Docker 这些去聚拢。
2. Flowable 核心思想还是在做一个功能丰富的流程引擎工具，除了最最根底的工作流，他还提供了很多其余的扩大点，咱们能够基于 Flowable 实现出许多咱们想要的性能（当然这也是小伙伴们感觉 Flowable 应用简单的起因之一）。
3. Camunda 绝对于前两个而言比拟轻量级，Camunda 有一个比拟有特色的性能就是他提供了一个玲珑的编辑器，基于 bpmn.io 来实现的（松哥之前曾经发文讲过了）。如果你的我的项目需要是做一个笨重的、灵便的、定制性强的编辑器，工作流是嵌入式的，那么能够抉择 Camunda。

如果认真比拟起这三个的差别，能列一个长长的表格，这个网上也有不少人都总结过了，松哥这里也就不啰嗦了。

3. 流程图

既然有三个不同的工作流，那么三个不同的工作流画进去的流程图是否都各不相同呢？

不是的。

工作流程图这块其实有一个对立的规范，那就是 BPMN。BPMN 全称是 Business Process Model and Notation，中文译作业务流程模型和标记法，这个中文太绕口了，还是简称 BPMN 吧。

这是一套图形化表示法，用图形来示意业务流程模型。BPMN 最后由业务流程治理倡导组织（BPMI, Business Process Management Initiative）开发，BPMI 于 2005 年与对象治理组织（OMG, Object Management Group）合并，并于 2011 年 1 月 OMG 公布 2.0 版本，同时改为当初的名称。

一句话，就是流程图这块有一个特地古老的标准，那就是 BPMN，而咱们后面所说的无论是 Activiti、Flowable 还是 Camunda，都是反对这个标准的，所以呢，无论你应用哪一个流程引擎，都能够应用同一套流程图。

那么这个标准到底都说了些什么事件呢？

咱们以下面生产笔记本的流程图为例，来和小伙伴们做一个简略介绍：

从上图中能够看到，一个流程图中次要蕴含四方面的内容：

• 事件
• 连线
• 工作
• 网关

咱们一个一个来说。

事件

首先在一个流程图中应该有开始事件和完结事件，也就是上图大家看到的两个圆圈。另外还有一些两头事件、边界事件等。举个两头定时事件的例子，比方用户下单之后，能够有一个两头定时事件，提早 5 分钟发货。

连线

连线就是将事件、工作、网关等连在一起的线条，个别状况下就是一般连线，有的时候连线会有一些条件，例如松哥之前文章和大家分享的销假，如果经理批准销假申请，就走哪一个线条，如果经理不批准销假申请，就走哪一个线条。对应上图的笔记本生产，如果经理审批通过，就载入图纸筹备生产，如果经理审批不通过，就从新设计。

工作

工作这块其实有很多分类。

如果细分大抵上能够分为如下几种：

• 接管工作

在下面的流程图中，期待筹备工作实现这一项就是一个接管工作。这个工作里并不需要额定做什么事件，流程到这一步就主动停下来了，须要人工去点一下，推动流程持续向下执行。

• 发送工作

这个个别用来把音讯发送给内部参与者。

• 服务工作

这个个别由零碎主动实现，其实说白了就是咱们的一个自定义类，能够在一个自定义类里边实现想要做的事件。

• 脚本工作

一个自动化流动。当流程执行到脚本工作时，主动执行相应的脚本。

• 业务规定工作

BPMN2.0 新引入用来对接业务规定引擎，业务规定工作用于同步执行一个或多个规定。

• 用户工作

用于为那些须要由人工参与者实现的工作建模。

尽管细分类别很多，然而认真看，其实这几种又能够归为两大类：

1. 用户工作：示意人工要染指做的事件。比方批准与否，或者输出一些参数，要让人工实现工作，就须要一个表单零碎，让人工输出数据，或者显示数据给人看，这也是为什么用户工作和表单零碎联合在一起的起因，用户工作须要用户向引擎提交一个实现工作的动作，否则流程会暂停在这里期待。
2. 服务工作：示意机器主动做的事件。调用服务的工作，这个服务能够是一个 Spring JavaBean，也能够是一个近程 REST 服务，流程会主动执行服务工作。

流动

流动能够算是一种非凡的工作。流动能够调用另外一个流程使之作为以后流程的子流程去运行。流动也能够分为用户流动、脚本流动等等。从显示上来说，流动比工作边框深一些。仅此而已。

网关

网关要是细分起来，也有很多不同类型的网关。

• 互斥网关

这种网关也叫排他性网关，咱们之前销假流程中的那个网关，就是互斥网关。这种网关有且仅有一个无效进口。

• 相容网关

这种网关会有多个进口，只有条件满足，都会执行。

• 事件网关

事件网关是通过两头事件驱动，它在期待的事件产生后才会触发决策。基于事件的网关容许基于事件作出决策。

• 并行网关

并行网关个别是成对呈现的，下面生产笔记本的那个流程中，生产屏幕、键盘等并行操作，就是通过并行网关来实现的。

好啦，这就是对于流程引擎的一些基本概念，捋顺了这些基本概念，在回过头看咱们后面几篇对于流程引擎的文章，应该会有一些不一样的了解：

• Spring Boot 整合流程引擎 Flowable，so easy！
• SpringBoot+Vue+Flowable，模仿一个销假审批流程！
• 49 张图率领小伙伴们体验一把 Flowable-UI
• Spring Security + Vue + Flowable 怎么玩？