工作流引擎是什么？

工作流引擎是用来实现工作流的一种组件化工具，它是一整套解决方案，比如说一般工作流引擎包含这些功能：流程节点管理、流向管理等，是为了减小开发成本而推出的。因为在软件开发过程中，如果是从零开始实现工作流，那开发成本很大。

上面讲到，工作流本质上是实现工作流的一种封装，那我们就有必要了解一下工作流是啥了。工作流其实是协同办公化的一部分，在日常办公中，工作都是有一套流程的，且各个流程都有相应的业务规则。

举个简单的例子：比如说请假，在任何一家公司中员工想要请假基本上都是有一个请假流程，而不是说你想来就来想不来就不来。你的请假先经过你的组长/主管审批 -》部门经理审批》行政报备》抄送财务等。

上面请假的例子就很好的说明了办公流程化，每一步操作都会涉及一些人和一些事的处理，传统的办公流程都是纸质化流程，效率极其低下。

而在信息化办公场景下，我们接入了工作流后，流程发起者只需要在系统上填写好表单提交后，流程就会按着预定的规则去执行，每一级审批者会自动接收到资料。工作流的好处就体现出来，比如说：

提升效率，避免了流程发起者到处跑现象；

流程及时性提高，纸质化流程审批者如果不在办公则无法审批，影响审批进度；而工作流的电子化场景使得审批容易；

流程便于管理，用了工作流后流程的查询、统计、打印等都很简单。

工作流是指在协作过程中通过限制任务状态的流转进行流程控制的一种方式。在工作流项目中，可以通过任务状态标记任务的完成情况。和传统项目相比，工作流项目对任务的状态描述更清晰。

普通项目任务只有「已完成」和「未完成」两种状态，工作流项目可以自定义任务状态来描述任务进展，比如「待处理」「进行中」和「已完成」；除此以外，还可以通过状态的流转设置进行简单的业务流程控制。

通过制造业工作流引擎平台，既可以帮助用户基于企业业务模式和管理模式，自行定义所需要的各种流程应用，快速构建企业自身的流程管控体系，同时也为建设企业整体协同平台夯实基础。

一、工作流

工作流（Workflow）指业务过程的部分或整体在计算机应用环境下的自动化，是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。在计算机中，工作流属于计算机支持的协同工作（CSCW）的一部分。后者是普遍地研究一个群体如何在计算机的帮助下实现协同工作的。

起源于生产组织和办公自动化领域，是针对日常工作中具有固定程序活动而提出的一个概念，目的是通过将工作分解成定义良好的任务或角色，按照一定的规则和过程来执行这些任务并对其进行监控，达到提高工作效率、更好的控制过程、增强对客户的服务、有效管理业务流程等目的。

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

Georgakopoulos给出的工作流定义是：

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

WFMC对工作流给出定义为：

工作流是指一类能够完全自动执行的经营过程，根据一系列过程规则，将文档、信息或任务在不同的执行者之间进行传递与执行。

二、工作流标准

1.⼯作流管理联盟（WFMC）

1993年⼯作流管理联盟(Workflow Management Coalition,WFMC)成⽴并颁布了⼀系列工作流管理系统相关的标准和规范，包括工作流术语表、工作流参考模型、工作流管理系统各部分间协作的五个接口规格、工作流产品的互操作性标准等。其中参考模型，如下图示：

WFMC 定义的 5 类接口的功能：

接口 1：过程定义输入输出接口，工作流服务和工作流建模工具间接口，包括工作流模型的解释和读写操作；
接口 2：客户端函数接口，工作流服务和客户应用之间的接口，这是最主要的接口规范，它约定所有客户方应用与工作流服务之间的功能操作方式；
接口 3：激活应用程序接口，工作流机和直接调用的应用程序之间的直接接口；
接口 4：工作流执行服务之间的互操作接口，工作流系统之间的互操作接口；
接口 5：系统管理与监控接口，工作流服务于工作流管理工具之间的接口；

主要应用场景：一般 OA 都内置有一个轻量级的审批流引擎，适用于办公协同领域。BPM 在中国主要适用于流程化信息化程度较高的制造业、零售业、房地产、金融业和政府事业单位，可以应用在企业战略、运营、管理等从上到下的各个场景。BPM 主要为这些行业中体量较大的公司客户服务。

其中接口一早期的标准为WPDL（Workflow Process Definition Language），后来这一接口的规范变更为XPDL（XML Process Definition Language）。

WFMC定义的XPDL(XML Process Definition Language)是至今工作流领域最为重要的一个标准，目前很多主流⼯作流产品都是依据这个标准和规则进⾏设计和开发的，因此大多数工作流引擎都是依据该标准设计开发的。

2.业务流程管理促进会（BPMI）

业务流程管理促进会(Business Process Management Initiative,BPMI)是⼀个致力于推广BPM(业务流程管理)标准和规范的组织。

BPMI的⽬标是将不同业务类型、不同⾏业的公司通过互联网等技术进⾏业务流程的整合，以实现管理的最优化、⽣产利益的最⼤化。

http://BPMI.org制定了许多开放标准，如业务流程建模语言（BPML－Business Process Modeling Language，业务流程建模的元语⾔，就像XML是业务数据建模的元语⾔⼀样）、业务流程查询语言（BPQL－Business Process Query Language）、业务流程建模标注（BPMN－Business Process Modeling Notation）等。

2002年6月26日BPMI联合WFMC宣布合作制定业务流程和⼯作流的标准和规范，即利⽤ BPML(Business Process Modeling Language)进⾏描述工作流过程，以及采⽤XPDL定义⼯作流业务模型。

现在，曾提出BPML语⾔的BPMI已经放弃对其的⽀持，转⽽推⼴BPEL4WS。这个转变是在BPMI被OMG收购后，为了参与到BPMN(Business Process Modeling Notation)领域⽽做出的，因为BPMN丰富了UML的流程符号，这⼀点对OMG⾮常有⽤。

3.业务流程建模符号（BPMN）

BPMN（Business Process Modeling Notation）是BPM及工作流的建模语言标准之一。是指业务流程建模与标注，包括这些图元如何组合成一个业务流程图（Business Process Diagram）。

由BPMI Notation Working Group超过2年的努力，于2004年5月对外发布了BPMN 1.0 规范，后BPMI并入到OMG组织，OMG于2011年推出BPMN2.0标准，对BPMN进行了重新定义(Business Process Model and Notation)。

BPMN的主要目标是要提供被所有业务用户理解的一套标记语言，从创建流程轮廓的业务分析到这些流程的实现，直到最终用户的管理监控，包括业务分析者、软件开发者以及业务管理者与监察者。BPMN也支持提供一个内部的模型可以生成可执行的BPEL4WS。因此BPMN的出现，弥补了从业务流程设计到流程开发的间隙，在业务流程设计与流程实现之间搭建了一条标准化的桥梁。

BPMN定义了一个业务流程图（Business Process Diagram），该业务流程图基于一个流程图（flowcharting），该流程图被设计用于创建业务流程操作的图形化模型。而一个业务流程模型（Business Process Model），指一个由图形对象（graphical objects）组成的网状图，图形对象包括活动（activities)和用于定义这些活动执行顺序的流程控制器（flow controls）。

BPMN有以下4个基本元素：

流对象（Flow Objects）：包括事件、活动、网关，是BPMN中的核心元素；
连接对象（Connecting Objects）：包括顺序流、消息流、关联；
泳道（Swimlanes）：包括池和道两种类型；
人工信息（Artifacts）：包括数据对象、组、注释。

4.工作流规范历程

20 世纪 70 年代中期，工作流出现并运用于办公自动化领域，使流程管理技术第一次有了系统的技术规范。20 世纪 80 年代初期，工作流伴随着 OA 系统走向商用，但是应用范围有限。至 80 年代后期，OA 系统的研究被群件和工作流管理系统所代替。20 世纪 90 年代以后，相关技术逐渐成熟，工作流管理联盟(WfMC)成立并发布了工作流参考模型。进入 21 世纪， BPM 更进一步发展。SOA 的出现使得流程管理技术从工作流转向业务流，基于此的一系列规范也相应被推出。

工作流的规范历程大致是从最初的XPDL、BPEL、BPML等走向BPMN2.0的过程。因此在目前的时间节点上，BPMN 规范最完善，现在主流工作流引擎产品，大多基于 BPMN2.0 规范实现的。

工作流规范历程的时间线如下：

大致梳理一下BPMN2.0逐渐成为规范的原因：

1.BPMN1.0在2004年5月由BPMI组织正式发布，但仅仅作为业务流程建模的一系列符号标准，对业务比较友好。不过BPMN1.x只是一些建模符号，不支持元模型，不支持存储和交换，也不支持执行。因此XPDL、BPEL和BPDM围绕着BPMN1.x的存储、交换和执行，产生了新的竞争。

2.XPDL作为WfMC提出的流程定义语言规范，本身就是一个元模型，可以存储，并且具备执行语义，因此理论上来讲，将BPMN转换为XPDL就可以解决存储、交换和执行的问题。XPDL2.0于2005年10月发布，在规范里，WfMC直接将XPDL的目标定义为BPMN的XML序列化格式。2008年4月23日发布的XPDL2.1规范，直接支持BPMN1.1到XPDL2.1的转换。XPDL是面向图的，BPMN也是面向图的，因此BPMN到XPDL的转换有着天然的优势。

3.BPEL-WS规范：BPEL的流行还在于Web正成为分布式系统架构的平台以及SOA的雄起，SOA强调服务的分解和解耦，而BPEL则对这些WEB服务进行编制，两者密不可分。但BPMN到BPEL的转换存在着先天上的缺陷，原因是BPMN是基于图的，而BPEL是基于块的，BPEL是一个结构化（块）和非结构化（控制链和事件）的混合体。这个缺陷导致有些BPMN建模的流程无法映射到BPEL，两者的双向工程更是存在问题。

4.BPDM（业务流程定义元模型，Business Process Definition Metamodel）则是OMG组织自己提出来解决BPMN存储和交换问题的规范。BPDM是一个标准的概念定义，用来表达业务流程模型。元模型定义了用来交换的概念，关系和场景，可以使得不同的建模工具所建模出来的流程模型进行交换。BPDM超越了BPMN和BPEL所定义的业务流程建模的要素，它定义了编排和编制。

5.BPMN2.0正式版本于2011年1月3日发布，BPMN2.0正式将自己更名为Business Process Model And Notation（业务流程模型和符号），相比BPMN1.x，最重要的变化在于其定义了流程的元模型和执行语义，即它自己解决了存储、交换和执行的问题，BPMN由单纯的业务建模重新回归了它的本源，即作为一个对业务人员友好的标准流程执行语言的图形化前端。至此工作流的标准规范竞争就结束了，XPDL、BPEL和BPDM也逐渐淡出历史舞台。

三、工作流引擎

目前主流的开源流程引擎有jbpm、activiti、flowable、camunda等。不过Jbpm4、Activiti、Flowable、camunda四个框架同宗同源，祖先都是Jbpm4。

几者之间的版本关系参考图如下：

时间线参考图如下：

工作流引擎是在开发低代码平台、OA系统、BPM软件等进行工作流可视化必不可少的一个内容。

1.JBPM

JBPM由JBoss公司开发，目前最高版本JPBM7，不过从JBPM5开始已经跟之前不是同一个产品了，JBPM5的代码基础不是JBPM4，而是从Drools Flow重新开始，基于Drools Flow技术在国内市场上用的很少，所有不建议选择jBPM5以后版本，jBPM4诞生的比较早，后来JBPM4创建者Tom Baeyens离开JBoss后，加入Alfresco后很快推出了新的基于jBPM4的开源工作流系统Activiti, 另外JBPM以hibernate作为数据持久化ORM也已不是主流技术。笔者在2012年开发某集团BPM平台时，选择的就是JBPM4.4版本，也是4系列的最后一个版本，进行了大量的扩展开发，才实现中国特色的流程需求。现在时间节点选择流程引擎，JBPM不是最佳选择。

官方网站：https://www.jbpm.org/

2.Activiti

activiti由Alfresco软件开发，目前最高版本activiti 7。activiti的版本比较复杂，有activiti5、activiti6、activiti7几个主流版本，选型时让人晕头转向，有必要先了解一下activiti这几个版本的发展历史。activiti5和activiti6的核心leader是Tijs Rademakers，由于团队内部分歧，在2017年时Tijs Rademakers离开团队，创建了后来的flowable, activiti6以及activiti5代码已经交接给了 Salaboy团队, activiti6以及activiti5的代码官方已经暂停维护了, Salaboy团队目前在开发activiti7框架，activiti7内核使用的还是activiti6，并没有为引擎注入更多的新特性，只是在activiti之外的上层封装了一些应用。结论是activiti谨慎选择。

Activiti在目前来看有点不思进取，核心功能和内核的优化并没有太大进步，着力点全在商业版和云上面，核心只支持BPMN2协议，跟6版本没有什么区别。如果你是一个老的Activiti使用者，并且只是用BPMN2协议，可以选用Activiti（非Cloud版本）。

官方网站：https://www.activiti.org/

3.flowable

flowable基于activiti6衍生出来的版本，flowable目前最新版本是v6.6.0，开发团队是从activiti中分裂出来的，修复了一众activiti6的bug，并在其基础上研发了DMN支持，BPEL支持等等，相对开源版，其商业版的功能会更强大。以flowable6.4.1版本为分水岭，大力发展其商业版产品，开源版本维护不及时，部分功能已经不再开源版发布，比如表单生成器（表单引擎）、历史数据同步至其他数据源、ES等。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）等模块。

Flowable不管是功能层面还是在代码层面来讲，都是这3个中最重的，当初跟Activiti分道扬镳的原因也是因为理念不一样，Flowable更注重其功能性、扩展性和性能。在上面表格中，历史异步归档和异步任务全局锁都是对性能的极大优化，特别是异步任务这一项，当年在使用Activiti的使用是一个极大的困扰，因为异步任务的吞吐反而会随着实例数的增加而加速恶化。Flowable比较臃肿，它支持了太多的东西，以致于如果想做POC或者Demo，环境搭建这一步都够呛。但是如果你本身就想做一个扩展性强的，性能高的工作流平台（SaaS\PaaS），Flowable是不二的选择。

官方网站：https://flowable.com/open-source/

4.Camunda

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

Camunda是这3个里面比较轻量的一个，但是它并没有去掉PVM这个性能较差的流程推动引擎，所以如果你对性能要求很高的话，PVM肯定是不能满足的（Activiti已经在6.X版本的时候放弃了PVM，Flowable亦是如此）。但是Camunda有一个好东西就是它的编辑器，它是基于http://bpmn.io的bpmn.js,cmmn.js,dmn.js来开发的，并且开源了自己的组件库，所以，如果你想做一个轻巧的、灵活的、定制性强的编辑器，工作流是嵌入式的，那么Camunda是一个好选择。

官方网站：https://docs.camunda.org/manual/7.15/

四、工作流设计器

对于低代码平台中的工作流可视化，工作流设计器是必不可少的，是非常重要的支撑工具，目前市场上比较主流的流程设计器有bpmn-js、mxGraph、Activiti-Modeler、flowable-modeler、bpmn2-modeler插件等。

1.bpmn-js

bpmn-js 是 BPMN 2.0 渲染工具包和 Web 模型。bpmn-js 正在努力成为 Camunda BPM 的一部分。bpmn-js 使用 Web 建模工具可以很方便的构建 BPMN 图表，可以把 BPMN 图表嵌入到你的项目中，容易扩展。bpmn-js是基于原生js开发，支持集成到vue、react等开源框架中。

官方网站：https://bpmn.io/

2.mxGraph

mxGraph是一个强大的JavaScript流程图前端库，可以快速创建交互式图表和图表应用程序，国内外著名的ProcessOne和http://draw.io都是使用该库创建的强大的在线流程图绘制网站。由于mxGraph是一个开放的js绘图开发框架，我们可以开发出很炫的样式，或者完全按照项目需求定制。

官方网站：http://jgraph.github.io/mxgraph/