BPM平台与工作流系统的区别，参见本文档：3.2 章节

其中：Jbpm4、Activiti、Flowable、camunda四个框架同宗同源，祖先都是Jbpm4，开发者只要用过其中一个框架，基本上就会用其它三个。

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之外的上层封装了一些应用。

https://www.activiti.org/quick-start

开源社区活跃度(Github)：9.8K star / 7K fork

主要编程语言: Java

URL

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）等模块。

开源社区活跃度(Github)：7.2K star / 2.5K fork

主要编程语言: Java

URL

Camunda基于activiti5，所以其保留了PVM，最新版本Camunda7.15，保持每年发布2个小版本的节奏，开发团队也是从activiti中分裂出来的，发展轨迹与flowable相似，同时也提供了商业版，不过对于一般企业应用，开源版本也足够了，强烈推荐camunda流程引擎，功能和性能表现稳定。

在Camunda商业产品中还包括了流程监控预警工具（Optimize）、流程协同设计工具（Cawemo）。 这里重点先说一下Camunda流程设计器，支持两种模式，一种是富客户端的流程建模工具Camunda Modeler，需要在客户端安装；另一种是基于浏览器的流程设计器bpmn.io，这两款软件均开源。 有网友的公司选用了 Camunda Modeler 客户端来设计流程。

1）通过压力测试验证Camunda BPMN引擎性能和稳定性更好。 2）功能比较完善，除了BPMN，Camunda还支持企业和社区版本中的CMMN（案例管理）和DMN（决策自动化）。Camunda不仅带有引擎，还带有非常强大的工具，用于建模，任务管理，操作监控和用户管理，所有这些都是开源的。

推荐：使用 camunda（流程引擎）+ bpmn-js（流程设计器）组合，有网友在公司项目中经过实战验证，camunda在功能方面比flowable、activiti流程引擎强大，性能和稳定性更突出。

开源社区活跃度(Github)：3.8k star / 1.5k fork

主要编程语言: Java

URL

Osworkflow是一个轻量化的流程引擎，基于状态机机制，数据库表很少 Osworkflow提供的工作流构成元素有：

但不支持会签、跳转、退回、加签等这些操作，需要自己扩展开发，有一定难度。

如果流程比较简单，osworkflow是很好的选择，但该开源组件已过时，长时间没有版本升级了。

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

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

开源社区活跃度(Github)：1.6k star / 1.2k fork

主要编程语言: Java

URL

https://www.processmaker.com/ https://github.com/ProcessMaker/processmaker

https://www.bonitasoft.com/

http://orchestra.ow2.org/xwiki/bin/view/Main/WebHome 【已停止访问】

https://jsonic.org/ 【已停止访问】

此外，一些成熟的SAP与OA对接OA系统供应商，可以作为参考。 国内厂商，如：泛微、蓝凌、通达、金和、致远、华天动力、炎黄盈动、K2、自开发。

Apache DolphinScheduler 是现代数据编排平台。以低代码敏捷创建高性能工作流程。它还提供了强大的用户界面，致力于解决数据管道中复杂的任务依赖关系，并提供开箱即用的各种类型的作业

DolphinScheduler 的主要功能如下：

原理与架构

Homepage

Workflow Definition

Workflow Tree View

Data source

开源社区活跃度(Github)：11.7k star / 4.3k fork

主要编程语言: Java

URL

比如，用于企业办公的 OA 系统中，就存在大量的申请审批类的流程。 在生产制造业，有大量的从销售端的订单，到生产制造，再到签收回款的生产销售流程。 在机器学习/数据领域，有亚马逊 AWS Sagemaker 的大数据处理、机器学习的应用。 综上，流程是一个特定概念，在和具体实现结合时，就产生了不同的流程产品，如 DevOps、Spring Data Stream 等。

一般而言，引擎是一个程序或一套系统的支持部分。 常见的程序引擎有游戏引擎、搜索引擎、杀毒引擎等。 引擎是脱离具体业务场景的某一类业务场景的高度抽象和封装。

比如，某 OA 公司，封装了一套审批用的 workflow，实施人员只需要配置流程和表单即可交付项目。 再比如，美国某公司做了一个 AI 引擎做 NBA（Next Best Action）推荐，封装了推荐领域的常用算法，在不同的场景自动选择和组合多种算法，进行智能推荐。

流程设计器是流程和引擎的连接方，用户通过流程设计器，将某种 layout 和 rule 固化成某种流程，然后通过数据和数据上下文，使用流程引擎自动按照某种固化的流程进行执行。

有网友将目前见到的流程设计器的理论基础，分为以下三类：

1，自定义系 2，UML 中的活动图系 3，BPMN 系

如：用于 Sagemaker 等场景的 AWS Step Function（自定义流程节点）

如：Flowportal BPM 的流程设计器

业务流程建模标注（Business Process Modeling Notation）

如：activiti 的流程设计器

如：炎黄盈动的流程设计器

PS: 炎黄盈动的流程设计器，和 processon 中的流程设计器界面几乎一样，因为本质上是一家的。

国际工作流管理联盟 : https://wfmc.org/

工作流是指“业务过程的部分或整体在计算机应用环境下的自动化”，是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。

工作流可以很长，而且可以包含多个停止（节点），工作流还不一定是直线，可以设定不同的规划路径去到不同的站点。这就好比铁路的铁轨，走不同的轨道可能会走向不同的目的地，甚至相同的目的地之间可以有不同的轨道。

WFMC 联盟(工作流程管理联盟)：

该联盟成立于 1993 年 5 月，最初成员包括IBM、惠普、富士通、ICL、Staffware以及大约 300 家商业软件领域的软件和服务公司。 WfMC 认为其工作截至 2019 年已完成，现已解散，而所有 WfMC 支持的奖项现已结束。 其工作的成功体现在工作流和业务流程空间中的众多框架、标准和语言中。（工作流参考模型，便是其中之一）

工作流参考模型于 1995 年首次发布，至今仍构成当今使用的大多数【业务流程管理】 (BPM)和【工作流软件系统】的基础。 它是根据通用工作流程应用程序结构开发的，通过识别使产品能够在各种级别上进行互操作的接口。 所有工作流系统都包含许多通用组件，它们以一组定义的方式进行交互；不同的产品通常会在这些通用组件中表现出不同级别的功能。 为了实现工作流产品之间的互操作性，这些组件之间需要一组标准化的接口和数据交换格式。 然后可以通过参考此类接口构建许多不同的互操作性场景，识别适合市场上产品范围的不同级别的功能一致性。 其他 WfMC 标准参考了该模型。

例如，随着时代进步，要想实现货物在不同站点间运输转移，出了轨道外我们还要考虑很多其他的因素，比如火车得有车厢，BPM中也会有负责存储流程流转过程中业务单据信息的东西，我们称之为“表单”； 火车在运输途中会有不同状态，BPM中也会有查询和显示流程流转状态的东西，我们称之为“视图”…这些复杂的“运输业务”都不是单单工作流所能满足的，只有BPM平台才具备这样的体系化能力！

BPM，Business Process Management，中文翻译为业务流程管理，有时也被称为BPMS (Business Process Management Suite业务流程管理软件套件)，是一种融合了现代管理思想和技术的重量级企业管理工具。

BPM诞生于20世纪末，管理学家迈克尔·哈默(Michael Hammer)和詹姆斯·钱皮(James A.Champy)合著的《再造企业:经营革命宣言》一书中提出了有关企业再造的理论。他们认为——重新设计公司的流程、结构和文化能够带来绩效上的显著提高。后续全球企业的管理实践也证明了这一理论的正确性。

在现代，BPM理论通过软件技术演变为一种软件系统。 这类软件通过不断监控和跟踪生产、业务、行政、财务、人事、运营等流程数据，发现其中可以优化的部分，再把业务中各个关键节点连接整合起来，拆除企业信息墙，重构端到端的工作流程，将流程规范化、标准化、自动化，从而帮助员工摆脱重复性低价值工作，专注于更高价值的工作，不断提升组织绩效。

从传统意义上来说，ERP（企业资源计划）、CRM（客户关系管理）、OA( 办公自动化)、HRM（人力资源管理）等软件，也是业务流程管理的一部分。 它们面向生产、销售、行政等部门，是为了解决具体业务问题而生的软件系统。 比如，OA适用于行政部门审批，目标是为了解决人工审批流程慢的痛点问题，加速审批效率。 CRM软件则是为了解决销售过程中的客户归属、订单管理等问题，帮助销售提升成单率。

对比而言，BPM有几大特点：

但国内真正能为客户实施BPM项目的厂商极少，大部分都是打着BPM的旗号干着卖工作流的活！

T媒体发布的《2019年中国BPM市场行业洞察报告》显示：国产化BPM已形成对国外产品的反超，以天翎（Java）、易正（.Net）等为代表的国内BPM产品实现了技术、功能和场景的多重突破，大量进入国内企业客户采购名录；传统的OA和工作流纷纷为BPM让路，泛微、致远等OA厂商也意识到趋势所在并发出了明确进军BPM的信号，但在产品和技术上和专业BPM品牌相比依然有不小差距。

定义不同：工作流（Workflow）是指“业务过程的部分或整体在计算机应用环境下的自动化”，是对工作流程及其各操作步骤之间业务规则的抽象、概括描述；BPM（Business Process Management）即业务流程管理，是一种以规范化的构造端到端的卓越业务流程为中心，以持续的提高组织业务绩效为目的的管理工具和方法论；

作用不同：工作流主要为了实现某个业务目标，利用计算机在多个参与者（不同角色）之间按某种预定规则自动传递文档、信息或者任务；BPM主要通过流程梳理、流程建模、流程集成、流程执行、流程监控和流程优化等方法对企业流程进行全方位管控，不断提高组织的控制力和执行力，从而实现组织绩效的提升；

起源不同：

根据T媒体发布的《2019年BPM行业洞察报告》显示：

对 Workflow和BPM，没有严格的概念界限区分。

如果 Workflow是早期人们为了解决“办公自动化”“流程自动化”而诞生的应用技术和解决方案的话； 那么BPM则是为了“对全局性的业务分析、整合”，以及“能够基于这些分析提供对上层管理决策的支持”的一种应用技术和解决方案。

事实上，如何去描述业务过程 “Business Process”，一直还是个争论不休的话题，也因此存在几种标准:

虽然描述过程 “Process”的标准并不一样，但是在圈定以：过程定义、过程执行、过程监控、过程分析、过程优化这几个方面为核心的BPM Solution ，这一方面各家几乎都是相同的，只是实现技术不同。

因此，它用于管理工作流的信息。工作流管理不考虑【业务流程的优化】。 BPM真正控制整个流程，确保工作流能够按计划实施。

可以为 IT人员提供一个协同环境，来将业务人员创建的业务流程转换为可以执行的、与数据库、电子表格和业务规则相集成的代码。 当业务流程很复杂的时候，一个人是不够的，很多不同的人要一起工作，协同工具是有必要的，它使得业务人员和IT人员可以进行协作。

例如， ERP、PLM、财务软件等。这些系统可以通过ＢＰＭ平台进行集成。 此外，ＢＰＭ还用于处理流程执行过程中的意外和特殊情况，发布流程，并对流程进行版本控制。 另外有一种工具，可以从正在执行的流程中提取一系列的指标，生成各种形式的报告，使流程的拥有者能够管理流程的资源，实现流程的优化。 简而言之， BPM可以提供所有的流程控制功能，并实现与各类应用软件的集成，但工作流管理不能实现这些功能。

相比较于传统的BPM平台，【连接型智能BPM平台】支持表单设计、流程引擎搭建、智能报表统计分析、数据权限多维设置、第三方系统集成连接、多种模式（SAAS、二次开发、私有化部署）开发……甚至，能够支持移动端使用。于是，连接型智能BPM平台逐渐成为大小企业的首选。

本章节系统地描述了BPM 流程引擎的架构设计思路，摘自：聊聊流程引擎的架构设计 - Weixin/互联网后端架构

比如，对于 Human Node 需要配置审批人，配置审批环节的展示表单，审批环节能够修改哪些字段，哪些字段的修改要进行留痕等。

这种是按照表单相关数据表，生成出一个表单，然后对表单字段进行配置和数据绑定。

这种是 Drag&Drop 控件，然后配置控件的属性，如绑定字段等。

这种是 Drag&Drop 控件，无需关联数据库表字段的表单

数据表生成表单的概要流程如下图所示。

拖拽控件绑定数据表字段的概要流程如下。

拖拽控件无需绑定数据表字段的概要流程。使用 NoSQL 的 Document 记录或使用 RDS 提供的 JSON 类型进行保存会比较方便。

结合 Activiti 的接口设计，如下图所示

一些系统在创建一个流程任务的时候，要先按照流程模板先创建一个应用示例，再关联发起人和备注，调用 RuntimeService，执行到 StartNode，这类设计因人而异，这么做略显繁琐。

一般发起流程的时候，需要带出发起人拥有的 Member 列表，从而后续节点取合适的审批人。

所以在组织架构设计的时候，要使用插件的方式来做，具体使用哪种插件，可以在配置文件中进行配置。以下为一个商业产品的组织架构操作界面示例。

常见的组织架构操作还有组织架构同步，比如流程系统同步微信企业号、钉钉等，这里不再展开。

我们想象的流程，可能是向下面的这种简单流程。

而实际项目，碰到的流程，一般是如下图所示的情景。

初步看几个流程的模型文件是什么样的，先有个印象。

一个屏幕截图都截不完的流程，如果用代码去实现整个流程，其工作量和效率，可想而知。而实际做项目，使用基于流程引擎的产品来做项目的时候，只需要确定节点、节点配置、数据配置和权限即可。

问题：一般流程，都带有邮件通知的节点，如何实现邮件通知节点？请考虑以下情景。

流程流转和执行的时候，会遇到各种情况的错误，比如找不到审批人等，此时流程引擎要对数据做 rollback，而邮件通知节点的业务逻辑已经执行过了。

权限方面，对于流程资源，哪些部门可以申请，哪些角色不可申请，都应该做流程控制。而在流程执行过程中，流程数据、不是路程的相关人也都不应该看到流程，处理过流程的审批人，不可以再对流程进行处理等，都是权限方面要考虑的问题。

如下图所示的表单，可以分析以下，一个流程表单有多个主表信息和多个子表信息。 一般而言，如果是通过流程引擎做非流程的数据处理，子表通过主表 ID 来做关联，如果通过流程引擎做流程的数据处理，子表和主表通过 TaskId 来做关联。以下为示例。

流程系统需要表单设计器，一个流程的不同节点可以挂接不同的表单，以方便不同角色的人关注不同维度的流程信息。

一般而言，对于流程的发起、审批、历史记录等，都是通用的系统界面。而一些业务场景，需要单独做列表界面，以方便使用。对于已有门户系统的客户，需要融合其界面样式。以下为曾经做过的项目示例。

由于不是所有客户都有报表系统，所以流程系统需要具备一个基本的报表功能。下图为示例。

有报表系统的客户，可以使用其商业版报表系统，获取（直接取、数仓）数据进行展示。常见的报表系统有 FineReport、Tableau、PowerBI 等。

人工处理时，指定连线 text

Workflow Management Coalition - Wiki