第一部分 准备篇

工作流（Work Flow）引擎被广泛应用于各种信息化系统中，将原本散乱甚至混乱的业务梳理后制定成业务规范流程，进而约束业务的规范化处理和运转。需求人员、开发人员共同协作制定了符合BPMN 2.0规范的流程定义，之后将其部署到工作流引擎中，由它自动驱动业务流程的进行。

本部分作为准备篇，第1章先介绍了什么是Activiti及其历史背景，然后介绍工作流、BPM、BPMN等概念，使初次接触工作流的读者能快速认识相关概念及各种规范。第2章内容从搭建开发环境开始，之后又介绍了Activiti的Hello World，帮助读者快速入门。

很多人对工作流（Workflow）应该不陌生。生活中到处都是活生生的“流”：在单位要请假，首先要找领导审批，在领导审批通过之后申请才获准；从网上购物，下单的那一刻就已经触发了一条工作流，此时可以跟踪购物流程，什么时间下单、什么时间付款、什么时候发货、什么时候收到货，在快递单上签字的时候才等于一条工作流程结束了。

工作流应用广泛，在由任务驱动的各种系统中都能见到它的身影，例如，CRM、ERP、ECM、BI、OA等。在企业应用中还有很多产品或平台集成工作流引擎，用来处理系统运行过程中发起的业务流程。

工作流总是以任务（Task）的形式驱动人处理业务或者驱动业务系统自动完成作业。有了工作流引擎之后，我们不必一直等待其他人的工作进度，直白地说，我们只需要关心系统首页的待办任务数即可，由系统提醒当前有多少待办任务需要处理。

1.1 什么是Activiti

大家第一次接触Activiti的时候不理解它为什么要叫这个名字，从词典中也没有找到对它的解释。可能有人会想到另外一个单词Activity（活动），与Activiti仅一个字母之差。在工作流方面有些基础的读者或许能很快理解，业务流程由多个环节串联起来并且每个环节被赋予任务，而每个任务又可以分为多个活动。举个日常的例子—网上购物的下单环节，首先需要搜索到要购买的商品，然后将其加入到购物车，最后下单填写邮寄地址并付款。这个例子中的每一动作都可以称为活动（Activity），也就是业务流程中最小的组成部分。多个活动在英文中肯定要用复数形式，即Activities；最后以复数化简的方式标示活动的集合，以此来诠释Activiti与工作流的目的与设计。

此项目是Tom Bayen（jBPM创始人）自2010年离开jBoss加入Alfresco公司后的又一力作：第一版在2010年5月发布，当时仅支持最简单的流程处理，之后的版本陆续完善了对BPMN 2.0规范的支持。

值得一提的是，参与项目开发的除了Tom Bayen和十几位核心开发人员之外，还有其他公司的员工参与，例如，SpringSource、MuleSoft、Salves、Signavio、FuseSource、NextLevel等。

Activiti是一个针对企业用户、开发人员、系统管理员的轻量级工作流业务管理平台，其核心是使用Java开发的快速、稳定的BPMN2.0流程引擎。Activiti是在ApacheV2许可下发布的，可以运行在任何类型的Java程序中，例如服务器、集群、云服务等。Activiti可以完美地与Spring集成。同时，基于简约思想的设计使Activiti非常轻量级。

Activiti有着活跃的社区，而且越来越多的企业都选择Activiti作为自己的流程引擎或者将其嵌入到自己的系统平台中（例如ESB）。

1.2 工作流基础

1.2.1 什么是BPM

BPM是Business Process Management的缩写，中文含义是业务流程管理，是一套达成企业各种业务环节整合的全面管理模式。

BPM是为了实现一定的经营目的而执行的一系列逻辑相关的活动的集合。业务流程的输出是满足市场需要的产品或服务。根据功能、管理范围等的不同，企业流程管理一般分为生产流程层、运作层、计划层和战略层四个层次。BMP是根据业务环境的变化，推进人与人之间、人与系统之间，以及系统与系统之间的整合及调整的经营方法与解决方案的IT工具。

BPM最早是由工作流和企业应用集成（Enterprise Application Intergration）逐步融合而发展起来的，当时是为了满足无纸化办公需求（这也是最早的需求之一）。笔者早期参与OA系统开发时曾经见到过“原始的”工作流—没有工作流引擎，整个流程均使用一系列单独为不同任务节点设计的页面串联起来，完成一个节点后在数据库标记当前任务的名称，以此做到“流程驱动”。

随着时间的推移，BPM的定义范围逐步扩展，不仅用来满足无纸化办公需求，现在BPM是一种企业集成技术，作为对面向服务系统架构SOA（Service-Oriented Architecture）、企业应用集成EAI (Enterprise Application Integration)、企业服务总线ESB（Enterprise Service Bus）的补充。

从概念上来说，BPM包含两个不同方面的意思：管理规范和软件工程。各大BPM供应商长期以来试图抽象这两个不同的方面，但是依然混乱。

作为管理规范，BPM是每一个战略管理者的责任。BPM是组织必须执行的核心业务流程，包含了企业价值和如何提供其实现。作为日常工作的一部分，业务系统可以借助模型和流程规范地定义业务流程。BPM流程图表达的是执行流程的步骤，已完成特定目标。特别说明的是这些模型用于人与人的沟通。这些都是诠释未决的，这意味着它们可以包含更高级别有价值的信息而不包括不必要的细节。这种诠释未决的过程模型也被称为抽象业务流程（Abstract Business Processes.）。

BPM作为软件工程时可以由BPM系统（BPMS）执行可执行的业务流程。可执行的业务流程是在一个流程基础上表示不同的流程顺序。流程图完全可以看做一个抽象的业务流程。可执行流程不同于抽象业务流程，因为它总是以最简单的方式运行。这部分内容也是被大多数厂商认同并接受的。

1.2.2 工作流生命周期

一个完整的工作流生命周期会经过5步，并且迭代循环，如图1-1所示。

定义：工作流生命周期总是从流程定义开始。此阶段的任务主要是收集业务需求并转化为流程定义。一般由业务需求人员进行，然后交由开发人员加工转化为计算机可以识别的流程定义。

发布：由开发人员打包各种资源，然后在系统管理（平台）中发布流程定义。在具体的流程引擎中包括流程定义文件（bpmn20.xml结尾）、自定义表单、任务监听类。

执行：具体的流程引擎（例如，Activiti）按照事先定义的流程处理路线以任务驱动的方式执行业务流程。

监控：此阶段是依赖执行阶段。业务人员在办理任务的同时收集每个任务（Task）的结果，然后根据结果做出相应处理，例如，在采购办公用品流程中，在通过领导审批之后，采购人员就要根据申请单外出采购。

优化：在此阶段，一个完整的流程已经结束，或许能满足业务需求，或许需要优化，而糟糕的情况是需要重新设计（流程没结束就异常终止），优化与设计正是此阶段需要处理的。根据整个流程的运行过程结果分析问题的根源，然后在此基础上进一步改进，并再次开始一个新的周期。

1.2.3 什么是BPMN

Business Process Modeling Notation，简称BPMN，中文译为业务流程建模标注，是由BPMN标准组织发布的，其第一版BPMN 1.0规范于2004年5月发布。经过多年的改进新的规范BPMN 2.0于2011年发布。之后各大厂商、开源社区均基于2.0规范设计自己的流程引擎，结束了各个厂商“各自为政”的局面，相应地统一了标准，从而利于以后的产品迁移。

BPMN定义了业务流程图，其基于流程图技术，同时对创建业务流程操作的图形化模型进行了裁减。业务流程的模型就是图形化对象的网图，包括活动（也可以说工作）和定义操作顺序的流控制。

在BPMN 1.x版本中的一些概念，如人工任务、可以执行脚本、自动决策等，都是独立于供应商的可视化标准化的方式。在BPMN 2.0规范中重点聚焦在如何执行语义和一个被业界认可的通用交换格式。这意味着基于BPMN 2.0的流程建模不仅在流程设计器上可以通用，还可以在任何符合BPMN 2.0规范的流程引擎上执行。

关于BPMN的细节内容有很多，官方文档足足有500多页，本书会在第4章介绍Activiti支持的BPMN 2.0规范以及Activiti在BPMN 2.0规范基础上的扩展。关于BPMN的其他内容本书就不一一列举了，有兴趣的读者可以仔细阅读官方文档。

1.3 Activiti的特点

1. 数据持久化

Activiti的设计思想是简洁、快速。有过应用开发经验的开发人员都知道应用的瓶颈体现在和数据库交换数据的过程中，针对这一点Activiti选择了使用MyBatis，从而可以通过最优的SQL语句执行Command，仅凭如此就能让引擎在速度上保持最高的性能。

2. 引擎Service接口

Activiti引擎提供了七大Service接口，均通过ProcessEngine获取，并且支持链式API编程风格。表1-1简单列出七个Service接口及其作用，具体使用会在后面的章节陆续介绍。

表1-1Activiti引擎的七大Service接口

3. 流程设计器

在jBPM4时代有专门的Eclipse插件可以用来设计jPDL，同样Activiti团队也专门设计了用来设计BPMN 2.0规范的流程设计器—Eclipse Designer。此外还有Signavio公司为Activiti定制的基于Web的Activiti Modeler流程设计器。

4. 原生支持Spring

Activiti原生支持Spring，这一点对企业应用来说尤为重要：可以很轻松地进行Spring集成，非常方便管理事务和解析表达式（Expression）。

5. 分离运行时与历史数据

Activiti继承自jBPM4，在表结构设计方面也遵循运行时与历史数据的分离，这样的设计可以快速读取运行时数据，仅当需要查询历史数据时再从专门的历史数据表中读取。这种设计方式可以大幅提高数据的存取效率，尤其是当数据日积月累时依然能够快速反应。

1.4 Activiti的应用

目前Activiti在国外已被很多厂商所使用，甚至有人专门成立了公司来培训Activiti的使用。Activiti在国内的发展正在呈直线趋势上升，已经成立了由很多热心的技术爱好者参与的技术社区。目前，很多新项目、新产品都开始采用Activiti作为新一代工作流引擎。

1. 在系统集成方面应用

与ESB（Enterprise Service Bus，企业服务总线）整合，例如Mule。

与规则引擎（Rule Engine）整合，例如JBoss Drools。

嵌入已有系统平台，例如，很多公司都开发了自己的系统平台，在其中嵌入Activiti作为平台的一部分。

2. 在其他产品中应用

Alfresco公司的ECM（Enterprise Content Management）产品Alfresco在企业中应用广泛，主要涉及文档管理、协作、记录管理、知识库管理、Web内容管理等。

如果企业或客户正在使用Alfresco管理文档，那么针对文档管理流程设计的流程定义可以直接部署在Alfresco上使用；如果之前没有接触过jBPM而现在学会了使用Activiti，那么不用再去学习其他的流程引擎。关于Activiti与jBPM的区别在1.6节会提到。

在Activiti没有发布之前一直使用jBPM作为流程引擎，在Activiti成熟以后Alfresco同时支持两者，当然在以后的某个时间可能会取消对jBPM的支持。

1.5 Activiti架构与组件

Activiti架构中最重要的肯定是引擎，当然还有刚刚提到的外部工具和组件，如图1-2所示。

下面依次介绍Activiti架构图中的各个组件。

Activiti Engine：作为最核心的模块，提供针对BPMN 2.0规范的解析、执行、创建、管理（任务、流程实例）、查询历史记录并根据结果生成报表。

Activiti Modeler：是模型设计器，其并非由Activiti公司所开发，而是由业界认可的Signavio公司赠送的（Signavio原本是收费的产品，现在被免费授权给Activiti用户使用）。适用于业务人员把需求转换为规范流程定义。

Activiti Designer：功能和Activiti Modeler类似，同样提供了基于BPMN 2.0规范的可视化设计功能，但是目前还没有完全支持BPMN规范的定义。适用于开发人员，可以把业务需求人员用Signavio设计的流程定义（XML格式）导入到Designer中，从而让开发人员将其进一步加工成为可以运行的流程定义。

Activiti Explorer：可以用来管理仓库、用户、组，启动流程、任务办理等。此组件使用REST风格API（目的在于让开发人员快速入门），提供一个基础的设计模型。如果业务简单，也可以直接使用无需开发。还可以作为后台管理员的流程、任务管理系统使用。

Activiti REST：提供Restful风格的服务，允许客户端以JSON的方式与引擎的REST API交互，通用的协议具有跨平台、跨语言的特性。

1.6 Activiti与jBPM5比较

目前流行的工作流引擎有Activiti和jBPM5，而在jBPM5发布以前大多数项目、平台都是基于jBPM3、jBPM4开发的。本节内容从技术和实际应用上对Activiti和jBPM5进行比较。表1-2从技术层面比较了两者的区别。

表1-2Activiti与jBPM5的技术层面对比

Activiti是基于jBPM4设计的衍生版本，如果选择Activiti可以继续沿用jBPM的思想理念设计、整合Activiti到项目或平台中，这也是相对于jBPM5来说的一个优势；相反，对于jBPM5来说要花点时间重新接受开发者的设计思想。

在各个流程引擎社区中有很多关于该如何选择Activiti和jBPM5的讨论，这两者有着很多相似的地方，争论主要是对规则引擎的支持：jBPM5是基于Drool Flow所有自然深度继承而来的规则引擎Drools；早期的Activiti功能比较简单，后来陆续添加的新特性也支持规则引擎Drools，开发人员只要简单配置规则接口即可达到与jBPM5一样的效果。