java工作流框架、java常见的工作流引擎 收藏 0

JAVA工作流「java工作流引擎框架」

以请假为例，现在大多数公司的请假流程是这样的

员工打电话（或网聊）向上级提出请假申请——上级口头同意——上级将请假记录下来——月底将请假记录上交公司——公司将请假录入电脑

采用工作流技术的公司的请假流程是这样的

员工使用账户登录系统——点击请假——上级登录系统点击允许

就这样，一个请假流程就结束了

有人会问，那上级不用向公司提交请假记录？公司不用将记录录入电脑？答案是，用的。但是这一切的工作都会在上级点击允许后自动运行！

这就是工作流技术。

Georgakopoulos给出的工作流定义是：工作流是将一组任务组织起来以完成某个经营过程：定义了任务的触发顺序和触发条件，每个任务可以由一个或多个软件系统完成，也可以由一个或一组人完成，还可以由一个或多个人与软件系统协作完

从上面的例子，很容易看出

工作流系统，实现了工作流程的自动化，提高了企业运营效率、改善企业资源利用、提高企业运作的灵活性和适应性、提高量化考核业务处理的效率、减少浪费（时间就是金钱）。

而手工处理工作流程，一方面无法对整个流程状况进行有效跟踪、了解，另一方面难免会出现人为的失误和时间上的延时导致效率低下，特别是无法进行量化统计，不利于查询、报表及绩效评估。

在Java领域，JBPM和Activity是两个主流的工作流系统，而Activity的出现无疑将会取代JBPM（Activity的开发者就是从Jbpm开发者出来的）。

1. 1个插件

在Eclipse中安装Activity插件，让你可以在Eclipse中绘制Activity工作流图

2. 1个引擎

ProcessEngine对象，Activity工作流引擎。这是Activiti工作的核心。负责生成流程运行时的各种实例及数据、监控和管理流程的运行。

所有的操作都是从获取引擎开始的，所以一般会把引擎作为全局变量

ProcessEngine processEngine =ProcessEngines.getDefaultProcessEngine();

3. 1个配置文件

activiti.cfg.xml。Activiti核心配置文件，配置流程引擎创建工具的基本参数和数据库连接池参数

4. 5种数据库表

Activiti的后台是有数据库的支持，所有的表都以ACT_开头。 第二部分是表示表的用途的两个字母标识。用途也和服务的API对应。

ACT_RE_*: \’RE\’表示repository。 这个前缀的表包含了流程定义和流程静态资源（图片，规则，等等）。

ACT_RU_*: \’RU\’表示runtime。 这些运行时的表，包含流程实例，任务，变量，异步任务，等运行中的数据。 Activiti只在流程实例执行过程中保存这些数据，在流程结束时就会删除这些记录。 这样运行时表可以一直很小速度很快。

ACT_ID_*: \’ID\’表示identity。 这些表包含身份信息，比如用户，组等等。

ACT_HI_*: \’HI\’表示history。 这些表包含历史数据，比如历史流程实例，变量，任务等等。

ACT_GE_*: 通用数据，用于不同场景下，如存放资源文件。

5. 23张表

不同的表存放不同方面的数据，有流程定义表、任务结点表、流程变量表、任务历史表等等。

6. 5项Service

不同的Service类对应不同的功能。

比如TaskService，是activiti的任务服务类。可以从这个类中获取任务的信息。

而HistoryService，则是activiti的查询历史信息的类。在一个流程执行完成后，这个对象为我们提供查询历史信息。

7. 7项基本操作

设计流程图（各种组件，如连线、用户任务、网关）

流程定义增删改查

流程变量增删改查

启动流程定义

任务增删改查

完成任务

历史信息查询

学习7项基本操作时只需在JavaSE下执行即可，当然，做web项目的时候就要考虑和SSH等开发框架结合的问题。当然，只有基本操作学会了，综合开发并不难。

工作流引擎架构设计

最近开发的安全管理平台新增了很多工单申请流程需求，比如加白申请，开通申请等等。最开始的两个需求，为了方便，也没多想，就直接开发了对应的业务代码。

但随着同类需求不断增多，感觉再这样写可要累死人，于是开始了工作流引擎的开发之路。查找了一些资料之后，开发了现阶段的工作流引擎，文章后面会有介绍。

虽然现在基本上能满足日常的需求，但感觉还不够智能，还有很多的优化空间，所以正好借此机会，详细了解了一些完善的工作流引擎框架，以及在架构设计上需要注意的点，形成了这篇文章，分享给大家。

先看一下维基百科对于工作流的定义：

工作流（Workflow），是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。工作流建模，即将工作流程中的工作如何前后组织在一起的逻辑和规则，在计算机中以恰当的模型表达并对其实施计算。

工作流要解决的主要问题是：为实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。

简单来说，工作流就是对业务的流程化抽象。WFMC（工作流程管理联盟） 给出了工作流参考模型如下：

举一个例子，比如公司办公的 OA 系统，就存在大量的申请审批流程。而在处理这些流程时，如果每一个流程都对应一套代码，显然是不现实的，这样会造成很大程度上的代码冗余，而且开发工作量也会骤增。

这个时候就需要一个业务无关的，高度抽象和封装的引擎来统一处理。通过这个引擎，可以灵活配置工作流程，并且可以自动化的根据配置进行状态变更和流程流转，这就是工作流引擎。

那么，一个工作流引擎需要支持哪些功能呢？

这个问题并没有一个标准答案，需要根据实际的业务场景和需求来分析。在这里，我通过一个工单流程的演进，从简单到复杂，循序渐进地介绍一下都需要包含哪些基础功能。

最简单的一个流程工单，申请人发起流程，每个节点审批人逐个审批，最终流程结束。

在这个过程中，节点分成了两大类：简单节点和复杂节点。

简单节点处理逻辑不变，依然是处理完之后自动到下一个节点。复杂节点比如说会签节点，则不同，需要其下的所有子节点都处理完成，才能到下一个节点。

同样属于复杂节点，其任何一个子节点处理完成后，都可以进入到下一个节点。

需要根据不同的表单内容进入不同的分支流程。

举一个例子，比如在进行休假申请时，请假一天需要直属领导审批，如果大于三天则需要部门领导审批。

审批节点的审批人需要动态获取，并且可配置。

审批人的获取方式可以分以下几种：

1. 固定审批人
2. 从申请表单中获取
3. 根据组织架构，动态获取
4. 从配置的角色组或者权限组中获取

节点状态变更可以有申请人撤回，审批人同意，审批人驳回。那么在驳回时，可以直接驳回到开始节点，流程结束，也可以到上一个节点。更复杂一些，甚至可以到前面流程的任意一个节点。

有一些节点是不需要人工参与的，比如说联动其他系统自动处理，或者审批节点有时间限制，超时自动失效。

节点审批之后，可以配置不同的通知方式来通知相关人。

以上是我列举的一些比较常见的需求点，还有像加签，代理，脚本执行等功能，如果都实现的话，应该会是一个庞大的工作量。当然了，如果目标是做一个商业化产品的话，功能还是需要更丰富一些的。

但把这些常见需求点都实现的话，应该基本可以满足大部分的需求了，至少对于我们系统的工单流程来说，目前是可以满足的。

既然这是一个常见的需求，那么需要我们自己来开发吗？市面上有开源项目可以使用吗？

答案是肯定的，目前，市场上比较有名的开源流程引擎有 Osworkflow、Jbpm、Activiti、Flowable、Camunda 等等。其中：Jbpm、Activiti、Flowable、Camunda 四个框架同宗同源，祖先都是 Jbpm4，开发者只要用过其中一个框架，基本上就会用其它三个了。

Osworkflow 是一个轻量化的流程引擎，基于状态机机制，数据库表很少。Osworkflow 提供的工作流构成元素有：步骤（step）、条件（conditions）、循环（loops）、分支（spilts）、合并（joins）等，但不支持会签、跳转、退回、加签等这些操作，需要自己扩展开发，有一定难度。

如果流程比较简单，Osworkflow 是一个很不错的选择。

JBPM 由 JBoss 公司开发，目前最高版本是 JPBM7，不过从 JBPM5 开始已经跟之前不是同一个产品了，JBPM5 的代码基础不是 JBPM4，而是从 Drools Flow 重新开始的。基于 Drools Flow 技术在国内市场上用的很少，所有不建议选择 JBPM5 以后版本。

JBPM4 诞生的比较早，后来 JBPM4 创建者 Tom Baeyens 离开 JBoss，加入 Alfresco 后很快推出了新的基于 JBPM4 的开源工作流系统 Activiti，另外 JBPM 以 hibernate 作为数据持久化 ORM 也已不是主流技术。

Activiti 由 Alfresco 软件开发，目前最高版本 Activiti7。Activiti 的版本比较复杂，有 Activiti5、Activiti6、Activiti7 几个主流版本，选型时让人晕头转向，有必要先了解一下 Activiti 这几个版本的发展历史。

Activiti5 和 Activiti6 的核心 leader 是 Tijs Rademakers，由于团队内部分歧，在 2017 年 Tijs Rademakers 离开团队，创建了后来的 Flowable。Activiti6 以及 Activiti5 代码已经交接给了 Salaboy 团队，Activiti6 以及 Activiti5 的代码官方已经暂停维护了。

Salaboy 团队目前在开发 Activiti7 框架，Activiti7 内核使用的还是 Activiti6，并没有为引擎注入更多的新特性，只是在 Activiti 之外的上层封装了一些应用。

Flowable 是一个使用 Java 编写的轻量级业务流程引擎，使用 Apache V2 license 协议开源。2016 年 10 月，Activiti 工作流引擎的主要开发者离开 Alfresco 公司并在 Activiti 分支基础上开启了 Flowable 开源项目。基于 Activiti v6 beta4 发布的第一个 Flowable release 版本为 6.0。

Flowable 项目中包括 BPMN（Business Process Model and Notation）引擎、CMMN（Case Management Model and Notation）引擎、DMN（Decision Model and Notation）引擎、表单引擎（Form Engine）等模块。

相对开源版，其商业版的功能会更强大。以 Flowable6.4.1 版本为分水岭，大力发展其商业版产品，开源版本维护不及时，部分功能已经不再开源版发布，比如表单生成器（表单引擎）、历史数据同步至其他数据源、ES 等。

Camunda 基于 Activiti5，所以其保留了 PVM，最新版本 Camunda7.15，保持每年发布两个小版本的节奏，开发团队也是从 Activiti 中分裂出来的，发展轨迹与 Flowable 相似，同时也提供了商业版，不过对于一般企业应用，开源版本也足够了。

以上就是每个项目的一个大概介绍，接下来主要对比一下 Jbpm、Activiti、Flowable 和 Camunda。只看文字的话可能对它们之间的关系还不是很清楚，所以我画了一张图，可以更清晰地体现每个项目的发展轨迹。

那么，如果想要选择其中一个项目来使用的话，应该如何选择呢？我罗列了几项我比较关注的点，做了一张对比表格，如下：

如果选择使用开源项目来开发自己的引擎，或者嵌入到现有的项目中，应该如何使用呢？这里通过 Flowable 来举例说明。

使用 Flowable 可以有两种方式，分别是内嵌和独立部署方式，现在来分别说明：

先建一个普通的 maven 工程，加入 Flowable 引擎的依赖以及 h2 内嵌数据库的依赖，也可以使用 MySQL 数据库来做持久化。

接下来，我们就可以往这个引擎实例上部署一个流程 xml。比如，我们想建立一个员工请假流程：

此 xml 是符合 bpmn2.0 规范的一种标准格式，其对应的流程图如下：

接下来，我们就把这个文件传给流程引擎，让它基于该文件，创建一个工作流。

创建后，实际就写到内存数据库 h2 了，我们还可以把它查出来：

创建工作流实例，需要提供一些输入参数，比如我们创建的员工请假流程，参数就需要：员工姓名、请假天数、事由等。

参数准备好后，就可以传给工作流了：

此时，就会根据流程定义里的：

创建一个任务，任务有个标签，就是 candidateGroups，这里的 managers，可以猜得出，是给 managers 建了个审批任务。

基于 manager 查询任务：

审批任务：

这里就是把全局变量 approved，设为了 true，然后提交给引擎。引擎就会根据这里的变量是 true 还是 false，选择走不同分支。如下：

审批后，就会进入下一个节点：

这里有个 class，就是需要我们自己实现的：

最后，流程就走完结束了。

上面介绍的方式是其作为一个 jar，内嵌到我们的程序里。创建引擎实例后，由我们业务程序去驱动引擎的运行。引擎和业务代码在同一个进程里。

第二种方式，Flowable 也可以作为一个独立服务运行，提供 REST API 接口，这样的话，非 Java 语言开发的系统就也可以使用该引擎了。

这个只需要我们下载官方的 zip 包，里面有个 rest 的 war 包，可以直接放到 tomcat 里运行。

在这种方式下，如果要实现上面举例的员工请假流程，可以通过调接口来实现：

启动工作流：

其他接口就不一一展示了，可以参考官方文档。

截止到目前，创建工作流程都是通过建立 xml 来实现的，这样还是非常不方便的。因此，系统也提供了通过页面可视化的方式来创建流程，使用鼠标拖拽相应组件即可完成。

但是体验下来还是比较辛苦的，功能很多，名词更多，有很多都不知道是什么意思，只能不断尝试来理解。

既然已经有成熟的开源产品了，还需要自研吗？这算是一个老生常谈的问题了。那到底应该如何选择呢？其实并不困难，归根结底就是要符合自身的业务特点，以及实际的需求。

开源优势：

入门门槛低，有很多可以复用的成果。通常而言，功能比较丰富，周边生态也比较完善，投入产出比比较高。一句话总结，投入少，见效快。

开源劣势：

内核不容易掌控，门槛较高，通常开源的功能和实际业务并不会完全匹配，很多开源产品开箱即用做的不够好，需要大量调优。一句话总结，入门容易掌控难。

自研优势：

产品核心技术掌控程度高，可以更好的贴着业务需求做，可以定制的更好，基于上述两点，通常更容易做到良好的性能表现。一句话总结，量身定制。

自研劣势：

投入产出比略低，且对团队成员的能力曲线要求较高。此外封闭的生态会导致周边支持缺乏，当需要一些新需求时，往往都需要定制开发。一句话总结，啥事都要靠自己。

基于以上的分析，再结合我们自身业务，我总结了以下几点可供参考：

1. 开源项目均为 Java 技术栈，而我们使用 Python 和 Go 比较多，技术栈不匹配
2. 开源项目功能丰富，而我们业务相对简单，使用起来比较重
3. 开源项目并非开箱即用，需要结合业务特点做定制开发，学习成本和维护成本比较高

综上所述，我觉得自研更适合我们现阶段的产品特点。

如果选择自研，架构应该如何设计呢？有哪些比较重要的模块和需要注意的点呢？下面来详细说说。

BPMN 全称是 Business Process Model And Notation，即业务流程模型和符号。

可以理解成一种规范，在这个规范里，哪些地方用空心圆，哪些地方用矩形，哪些地方用菱形，都是有明确定义的。

也就是说，只要是基于这个规范开发的系统，其所创建的流程就都是可以通用的。

其实，如果只是开发一个内部系统，不遵守这个规范也没有问题。但要是做一个产品的话，为了通用性更强，最好还是遵守这个规范。

对于工作流引擎来说，流程设计器的选型至关重要，它提供了可视化的流程编排能力，决定了用户体验的好坏。

目前主流的流程设计器有 Activiti-Modeler，mxGraph，bpmn-js 等，下面来做一个简单介绍。

Activiti 开源版本中带了 Web 版流程设计器，在 Activiti-explorer 项目中有 Activiti-Modeler，优点是集成简单，开发工作量小，缺点是界面不美观，用户体验差。

mxGraph 是一个强大的 JavaScript 流程图前端库，可以快速创建交互式图表和图表应用程序，国内外著名的 ProcessOne 和 draw.io 都是使用该库创建的强大的在线流程图绘制网站。

由于 mxGraph 是一个开放的 js 绘图开发框架，我们可以开发出很炫的样式，或者完全按照项目需求定制。

官方网站：jgraph.github.io/mxgrap

bpmn-js 是 BPMN2.0 渲染工具包和 Web 模型。bpmn-js 正在努力成为 Camunda BPM 的一部分。bpmn-js 使用 Web 建模工具可以很方便的构建 BPMN 图表，可以把 BPMN 图表嵌入到你的项目中，容易扩展。

bpmn-js 是基于原生 js 开发，支持集成到 vue、react 等开源框架中。

官方网站：bpmn.io/

以上介绍的都属于是功能强大且完善的框架，除此之外，还有其他基于 Vue 或者 React 开发的可视化编辑工具，大家也可以根据自己的实际需求进行选择。

最后来说说流程引擎，整个系统的核心。引擎设计的好坏决定了整个系统的稳定性，可用性，扩展性等等。

整体架构如图所示，主要包括一下几个部分：

一、流程设计器主要通过一系列工具创建一个计算机可以处理的工作流程描述，流程建模通常由许多离散的节点步骤组成，需要包含所有关于流程的必要信息，这些信息包括流程的起始和结束条件，节点之间的流转，要承担的用户任务，被调用的应用程序等。

二、流程引擎主要负责流程实例化、流程控制、节点实例化、节点调度等。在执行过程中，工作流引擎提供流程的相关信息，管理流程的运行，监控流程的运行状态，并记录流程运行的历史数据。

三、存储服务提供具体模型及流程流转产生的信息的存储空间，工作流系统通常需要支持各种常见的数据库存储。

四、组织模型不属于工作流系统的建设范围，但流程设计器在建模的过程中会引用组织模型，如定义任务节点的参与者。还有就是在流程流转的过程中同样也需要引用组织模型，如在进行任务指派时，需要从组织模型中确定任务的执行者。

工作流引擎内部可以使用平台自身的统一用户组织架构，也可以适配第三方提供的用户组织架构。

五、工作流引擎作为一项基础支撑服务提供给各业务系统使用，对第三方系统开放标准的 RESTful 服务。

下面来说说我现在开发的系统支持到了什么程度，以及未来可能的发展方向。由于毕竟不是一个专门的工单系统，工单申请也只是其中的一个模块，所以在整体的功能上肯定和完整的工作流引擎有很大差距。

第一版并没有流程引擎，开发方式简单粗暴，每增加一个流程，就需要重新开发对应的表和业务代码。

这样做的缺点是非常明显的：

1. 每个流程需要单独开发，工作量大，开发效率低
2. 流程功能相近，代码重复量大，冗余，不利于维护
3. 定制化开发，缺少扩展性#

第二版，也就是目前的版本。

随着工单流程逐渐增多，工作量逐渐增大，于是开始对流程进行优化，开发了现阶段的工作流引擎。

在新增一个工单流程时，需要先进行工作流配置，配置其基础信息，自定义字段，状态和流转这些信息。还支持配置自动化节点，可以根据条件由程序自动完成相关操作并审批。

配置好之后，后端无需开发，由统一的引擎代码进行处理，包括节点审批流转，状态变更等。只需要开发前端的创建和查询页面即可，相比于第一版，已经在很大程度上提高了开发效率。

目前版本需要优化的点：

1. 缺少可视化流程设计器，无法做到拖拽式设计流程
2. 节点之间状态流转不够灵活
3. 缺少分布式事物支持，以及异常处理机制

针对以上不足，下一个版本准备主要优化三点，如下：

1. 需要支持可视化流程设计器，使流程设计更加简单，灵活
2. 根据流程配置自动生成前端页面，做到新增一种类型的工单，无需开发
3. 增加节点自动化能力，异常处理机制，提高系统的稳定性

如何实现工作流？有完整的项目案例

说起工作流，大多数没有接触过的同学或者刚接触的同学，是一头雾水，不知道如何学习、实战，看了一圈文档，引起了一堆疑问，感觉工作流太复杂了。

我之前也在微头条中聊过，什么是工作流，无非就是做一件事情不同角色参与，一起把这个事情完成，这个流程称为工作流

[what]思考：不借用现有框架，你是如何实现

​[酷]思路:

• 需要创建一个工作流的流程模型，每一步都要关联一个人或是多人去参与，最后要把这个流程模型图以二进制的方式保存下来
• 再创建一个工作表单，说明我要干什么，然后关联这个工作流模型图，这就组成一个完成流程模型
• 根据流程模型，发起流程，操作流程，完结流程

想到这，大家可能有点晕头转向，这需要多少开发量，还要考虑很多的边界条件。如果你想到了以上几个方面，说明你已经打开了工作流的大门，了解工作流的业务逻辑，之后，学习工作流框架，会更加容易上手。

https://github.com/CollectBugs/RuoYi-Flowable-Plus

• 介绍

这个项目很好的借用flowable工作流框架实现工作流功能

• 在线流程设计器
• 在线流程表单设计器
• 单节点配置表单
• 多实例会签任务
• 任务节点配置任务/执行监听器
• 动态配置任务候选人
• 其它流程相关功能点

• https://github.com/zc-libre/snakerflow-spring-boot-stater

Snaker是一个基于Java的轻量级工作流引擎，适用于企业应用中常见的业务流程。本着轻量、简单、灵巧理念设计，定位于简单集成，多环境支持。

• https://github.com/Activiti/Activiti

Activiti 是一个轻量级工作流程和业务流程管理 (BPM) 平台，面向业务人员、开发人员和系统管理员。其核心是一个超快且坚如磐石的 Java BPMN 2 流程引擎。它是开源的，并根据 Apache 许可证分发。Activiti 可以在任何 Java 应用程序、服务器、集群或云中运行。它与 Spring 完美集成，非常轻量级并且基于简单的概念。

• https://github.com/camunda/camunda-bpm-platform

Camunda Platform 7 是一个灵活的工作流程和流程自动化框架。其核心是在 Java 虚拟机内运行的原生 BPMN 2.0 流程引擎。它可以嵌入到任何 Java 应用程序和任何运行时容器中。它与 Java EE 6 集成，并且与 Spring 框架完美匹配。在流程引擎之上，您可以从一系列工具中进行选择，用于人工工作流程管理、操作和监控

对于项目案例，大家可以本地部署一下，操作一下整个工作流过程，再根据代码与库表，更加深入去了解，学习。有什么问题，都可以联系我，提供友情技术支持

每天不断更，精彩不停止，明天见，我是行者

创作不易，记得留个关注、点赞、评论哟，让我们一起去看星辰大海，品味代码人生

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com