1       概述

这里对现阶段市面上的几个主流工作流引擎进行对比，同时将其与FixFlow进行功能和各方面的对比。这里选定的目标是JBPM和Activit，现在两者最新稳定版本分别是JBPM5以及Activiti5。

同时这里会讲讲FixFlow这个国产工作流引擎，对于国内用户来说，使我们在几个国外工作流之外又有了更多的选择。我们可以看到国内的开源流程引擎也可以做到国际级的水平，同时还可以支持加签、会签、回退等这样的“中国式工作流”。

2       JBPM和Activiti对比

首先先看看JBPM5和Activiti5，这两者现在可以说是国内外最常见到的开源工作流引擎。如果总管两者的发展史会发现两者的奠基人都是来自于一个叫Tom Baeyens的人。所以就会发现JBPM系列和Activiti系列的风格方面有很多相似，而Activiti看起来更像是JBPM的后续发展。

2.1  从JBPM3到Activiti5

从架构层面上来看JBPM3的架构为：

从这张图可以很清晰的看出JBPM的技术架构，可以说作为一个工作流引擎应该有的成分：设计器、控制台、流程引擎、引擎数据库这几者已经明显的标注之上，在后续的各个工作流引擎中这种架构都没有颠覆性的变化。

这里我们来看一下JBPM5的架构

他引入了规则引擎Drools，规则引擎负责了整个流程引擎的运转，而知识仓库的存在。让面向流程的知识管理有了更直观的认识，事实上JBPM的代码操作几乎都是从知识库类开始的。

       这张图很好的表现出了一个以BPMS为方向的流程产品应该是什么样的架构模式。

如果说JBPM是产品经理的造物的话，那么Activiti就是技术人员的杰作，Activiti更多的精力是放在了技术架构的精妙。其易用性方面是JBPM难以比拟的。集成一个Activiti的难度要远低于JBPM，同时JBPM业务化的api体系也着实让技术人员有些头疼。

这张图就是Activiti的架构图，可以看出这张图与其说产品架构图，更有点像技术架构图。在产品层面上，其知识库的概念还没有完全突出出来。

所以说对两者来说，JBPM的产品架构很不错，而Activiti的技术架构比之要强。两者可以说各有所长，不过他们之间有一些已经确定的共识。两者其实都在往BPMS的方向前进。

2.2     优势与共同点

1.      如何设计流程，在组织中高效地对设计出的流程进行沟通，取得共识？

·         提供跨越组织的流程标准标记符号与术语（BPMN已经成为标准）

·         流程及相关文档的可视化（流程/内容存储仓库）

·         提供在组织结构内进行不同层次之间的流程导航（流程存储仓库支持组织模型）

·         流程定义在各个层次/部门间的一致性，避免业务人员的流程建模转换到IT系统时受到损耗（流程引擎支持基于图的建模，支持扩展）

2.      如何更好地执行流程？

·         业务活动的实时监控，预警与控制（BAM）

·         流程执行的仿真

·         流程执行的统计分析与反馈（报表）

3.      如何更好地管理流程？

·         打破各个应用系统之间的界线，统一管理所有流程（EAI，与ESB的集成）

·         对业务人员友好的建模工具

4.      如何在执行流程过程中遵循业内最佳实践和规则？

·         面向流程的知识管理

·         规则引擎

3       FixFlow

JBPM和Activiti如此强大，那么国内也有很多厂商已经在使用了，但是在实际项目里得到的统一结果可能就是“不咋地”。这很简单，因为相比起SSH这样的框架，工作流与业务更贴近，因此对其灵活度的要求就更高。更高的灵活度就意味着更多可定制化成分。因此比如我们想造一辆汽车，SSH可以给我们的可能是生产线、发动机这样成品式的组件，而JBPM和Activiti给我们的则是油漆铁板这样的原材料。其主要问题主要在：

3.1  JBPM和Activiti的中国化

JBPM和Activiti已经被国内大量程序员所了解并加入到所使用的项目中。这两者也是国内架构人员的座上宾。

但是在使用中真的如此顺利么？笔者也曾用过这两者，也和用过两者的同行做过一些交流。我们认为这两者对于国产使用实际效果不佳。尤其在面对中国工作流需求时，两者不但没有提高更多帮助，反而使用户感觉掣肘。

3.1.1   API复杂，学习曲线高

正是由于业务的高可变性，开源的工作流引擎必须提供更多的api以供使用。这种复杂的API使程序员上手非常困难，使用者与其是被自己的业务捆住不如说是被困在寻找各种API的路上。

3.1.2   沟通成本高，反馈困难

大型的开源工作流产品无一例外是由国外团队维护，与其沟通并非容易的问题。

3.1.3   从引擎到应用必须经过二次开发

国外的工作流引擎在使用前一定会有架构师进行本地封装，有些是根据特定应用进行的封装，有些事通用的封装。这里JBPM的封装难度就比较大，而Activiti则稍小，不过依然是一件比较痛苦的事情。

3.1.4   国内只拿到引擎，而没有学会BPMS架构

之前也说过BPM最大的客户价值在于BPMS，这些正是各大工作流引擎所追寻的目标所在。客户为何要用工作流，工作流能为其带来什么好处？工作流绝不仅仅是对项目开发减少维护难度，更多是为各种切片分析提供详细的数据基础。市面上虽然有一些分析类的产品

3.1.5   中国式工作流

国外工作流引擎最大的一个问题还是无法适应中国式工作流，加签、会签、任意节点退回等等中国特有的管理模式，使国外的工作流无法原生支持这些内容，必须要经过复杂的二次开发才能支持起来。

3.2  FixFlow能带来什么

FixFlow是FixTeam带来的一款开源工作流引擎，这款工作流引擎有以下特点。FixTeam是方正国际旗下的BPMCS开发小组，其BPMCS开发平台以是国内极具影响力的主流开发平台。

FixFlow其技术架构上走的是Activiti路线，同时为了方便使用，采用了更符合程序员使用习惯的API体系。提供了完整的中文本地化支持，同时还支持了各种中国式工作流。该引擎源自方正国际的BPMCS开发平台，该项目已有大量项目在线稳定运行，保障了其运行效率和稳定性。其主要优势如下

3.2.1   数十年积淀，运行稳定

FixFlow流程引擎源自于BPMCS，BPMCS本身是一款已经发展数十年的开发平台。项目组人员把平台的流程引擎单独抽取出来成了FixFlow，他拥有BPMCS里所有的流程引擎功能。目前已有福田康明斯、世纪互联、邮政储蓄银行、华东勘测设计院等多加公司正在使用这款流程引擎。

3.2.2   优质的本地化支持

FixFlow现在在GIT Hub上存放源代码，使用者可以在上面提出自己的问题与bug。或者也可以加入QQ群152654373，同样可以获取最及时的交流帮助。

3.2.3   完整的BPMS支持

FixFlow不仅仅是一个简单的开源工作流引擎，对于企业级用户来说，可以以FixFlow为中心获取BI报表、业务活动监控BAM、开发平台等全方位的支持。

3.2.4   BPMN2.0标准化

FixFlow是国内首家全面支持BPMN2.0的开源工作流引擎。任何标准化设计器设计出来的BPMN配置文件，都可以直接拷贝至FixFlow里直接使用

3.2.5   Groovy脚本语言

FixFlow是国内首家使用脚本语言作为核心的开源工作流引擎。这样其流程运转的维护难度大大降低。

3.2.6   插件式图形设计器

FixFlow所有的流程和所有流程配置都可以在设计器上完成。通过配置就可以完成所有的可配置项。

3.2.7   嵌入式工作流

JBPM和Activiti的创始人Tom Baeyens曾说过独立式工作流已死。确实，其因有两个：一是独立部署的BPMS需要很高的安装使用成本，需要独立部署、需要用户支出大量的培训成本和维护成本；二是独立部署的BPMS与外部系统的交互方式是分布式，这使得很多问题变得复杂，例如分布式事务。Tom Baeyens代表了相当一部分人特别是开发人员的观点。

该观点实际上有些片面，其实应该更深入理解里面的内容。准确来说BPMS应该分成两部分来看，一部分是工作流引擎，一部分是工作流知识库和相关应用（BAM、BI）。Tom Baeyens提出的很多问题其实都是工作流引擎单独部署带来的，如果工作流引擎单独在外，那么所有的系统与其交互必然成本高昂，如果其他功能再有所问题则整套体系都显得脆弱不堪。可是如果每个系统各自为政，就会出现网状交织的系统部署情况，这种情况对于信息化后续发展来说无疑是一剂毒药。

所以该观点的准确理解是流程引擎嵌入化，流程引擎应该是嵌入到每个系统之中，这样对于程序开发人员来说无疑是福音。而流程的管理系统系统应该集中化，建立流程知识库，让知识库统一管理，做到集中化。同时多系统串联应该引入ESB，做到应用调用流程，流程调用ESB，然后ESB再去调用注册服务的应用这样的调用结构。

3.2.8   API简单易集成

嵌入式工作流引擎其优点就是可以集成到其他系统中，这个系统无论是已经开发完成的系统，还是架构中的系统都可以把引擎集中到里面。

该引起来自于开发平台，所以易用性是绝对有保障的，集成难度远低于各个开源工作流引擎。只要了解一些基本的Spring知识，就可以将其轻松完成集成工作。

FixFlow所有的API都是来自于FixFlowShellProxy这个类作为调用起始。学习周期很短。

3.2.9   商业化支持

FixFlow也有其商业版，如果使用者希望得到企业级的技术支持，可以从方正国际获取到商业版的FixFlow以及相关支持。

4       总结

如果你现在正在使用JBPM或者Activiti，那么你应该已经感觉到这两款引擎所带来的好处与坏处。此时有了一个新的选择FixFlow，再架构新项目的时候可以再也不用为“中国式工作流”进行复杂的逻辑封装。

这里附上关于FixFlow的几个地址

GIT地址：https://github.com/fixteam

官网地址：https://github.com/fixteam

下载地址：https://github.com/fixteam

第二篇：Activity初学

?1. 初识Activiti

?

?

?

?

?1.3.2. Activiti简介

?

?

?

?

?2.1.2. 其他准备

?

?

?

?

?3. 入门示例（参考手册中10分钟教程）

?

?

?

?

?3.5. 导入activiti-explorer

?

?

?

1. 初识Activiti

1.1. 工作流与工作流引擎

工 作流（workflow）就是工作流程的计算模型，即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。 它主要解决的是“使在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者促使此目标的实现”。（我的理解就是：将部分或者全部的工作流程、逻辑让计算机帮你来处理，实现自动化）

所谓工作流引擎是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。

例如开发一个系统最关键的部分不是系统的界面，也不是和数据库之间的信息交换，而是如何根据业务逻辑开发出符合实际需要的程序逻辑并确保其稳定性、易维护性和弹性。

比如你的系统中有一个任务流程，一般情况下这个任务的代码逻辑、流程你都要自己来编写。实现它是没有问题的。但是谁能保证逻辑编写的毫无纰漏？经过无

数次的测试与改进，这个流程没有任何漏洞也是可以实现的，但是明显就会拖慢整个项目的进度。

工作流引擎解决的就是这个问题：如果应用程序缺乏强大的逻辑层，势必变得容易出错（信息的路由错误、死循环等等）。

1.2. BPMN2.0规范

BPMN（Business Process Model and Notation）--业务流程模型与符号。 BPMN是一套流程建模的标准，主要目标是被所有业务用户容易理解的符号，支持从创建流程轮廓的业务分析到这些流程的最终实现，知道最终用户的管理监控。 通俗一点其实就是一套规范，画流程模型的规范。流程模型包括：流程图、协作图、编排图、会话图。详细信息请google。

1.3. Activiti概述

1.3.1. Activiti由来

学 习过Activiti的朋友都知道，Activiti的创始人也就是JBPM（也是一个优秀的BPM引擎）的创始人，从Jboss离职后开发了一个新的 BPM引擎：Activiti。所以，Activiti有很多地方都有JBPM的影子。所以，据说学习过JBPM的朋友学起Activiti来非常顺手。

由于本人之前没有工作流及JBPM的相关基础，刚开始学习Activiti的时候可以说是无比痛苦的，根本不知道从何下手，这里也建议大家先进行工作流及BPMN2.0规范的学习，有了一定的基础后，再着手学习Activiti。

1.3.2. Activiti简介

Activiti是一个开源的工作流引擎，它实现了BPMN 2.0规范，可以发布设计好的流程定义，并通过api进行流程调度。

Activiti 作为一个遵从 Apache 许可的工作流和业务流程管理开源平台，其核心是基于 Java 的超快速、超稳定的 BPMN2.0 流程引擎，强调流程服务的可嵌入性和可扩展性，同时更加强调面向业务人员。

Activiti 流程引擎重点关注在系统开发的易用性和轻量性上。每一项 BPM 业务功能 Activiti 流程引擎都以服务的形式提供给开发人员。通过使用这些服务，开发人员能够构建出功能丰富、轻便且高效的 BPM 应用程序。

1.4. 文档说明

以上部分对工作流、BPMN、Activiti的概念做了一个简单的介绍，目的是了解Activiti究竟是什么，能做些什么?及在学习Activiti之前需要了解的知识与

技术。其中大部分文字来自Copy网上的各种资料与文档，通过总结而来的。具体的更详细的内容需自己google，参考一些官方的文档与手册。

本文档之后内容如下：

1) 下载与使用

2) 核心组件与说明

3) 入门示例

4) Eclipse中的Activiti插件的使用

本文档旨在为初学Activiti的朋友提供入门级别的参考，不会对其原理及其结构进行深层次的探究（更多是因为目前自身理解还不是很透彻），只是为大家理清思路，方便以后更深层次的学习。本文档还有一个重要的特点，那就是根据自己看官方手册的经验，教大家如何看手册从而更有效率！由于是初学，很多术语或解释难免理解有偏差，所以一定要看官方提供的文档与手册，那才是学习的最佳途径！

2. 开始学习

2.1. 必要的准备

2.1.1. 下载与了解目录

下载Activiti：下载路径，也就是官方网站的地址：http://activiti.org/download.html。下载后解压（我所使用的是5.12版本的，Activiti更新速度飞快，几乎每两个月就会有一个更新的小版本），看到如下目录：

1) database： 里面存放的是Activiti使用到的数据库信息的sql文件，它支持的数据库类型如下图，使用时只需执行你自己的数据库类型的文件即可。如：你的数据库 是mysql，那么就执行activiti.mysql.create.*.sql即可。

2) docs：毫无疑问，api文档是也。

3) libs：使用Activiti所需要的所有的jar包和源文件。

4) wars：官方给我们提供的示例Demo，通过使用Demo可以更加快速的了解Activiti。

2.1.2. 其他准备

使用Activiti，首先当然要有jdk了！6+版本就可以了。其次，要有一款IDE，我们当然会使用Eclipse，这里使用Juno版本。然后，web容器当然也要有，这里使用Tomcat6.0版本。然后就是Activiti的Eclipse插件了，这个后面再介绍。

2.1.3. 一分钟入门（见用户手册）

所谓的一分钟入门就是通过运行你下载的包里的wars文件夹里的

activiti-explorer.war文件，以便更快的了解Activiti。将文件拷贝至Tomcat的webapps目录，启动tomcat，输入http://localhost:8080/activiti-explorer。然后你就可以开整了！总算是有一点微小的进展了。

这里需要说明的就是，这个Demo默认采用的是h2内存数据库，如果想用你自己的数据库，就需要修改web应用WEB-INF/classes目录下的db.properties。然后，按上面说的，把database里的create文件夹里的数据库文件导入你自己的数据库（如果没有修改db.properties，就不用导入了）。

Demo的具体解释与数据库配置的具体信息详见官方手册，手册已经说的很清楚了。这里需要重点了解activiti.cfg.xml的配置以及如何构建ProcessEngine（配置文件构建方式、代码构建方式）。

对Demo的使用介绍在官方文档的后面才开始介绍，这里建议应用跑起来之后，先自己试试手（可看后面介绍Demo如何使用的章节），看看如何跑一个流程、整个流程是怎么流的、并随时关注数据库表里的数据的变化等，对以后的学习很有帮助！

2.2. 核心组件介绍

2.2.1. 关键对象

1. Deployment：流程部署对象，部署一个流程时创建。

2. ProcessDefinitions：流程定义，部署成功后自动创建。

3. ProcessInstances：流程实例，启动流程时创建。

4. Task：任务，在Activiti中的Task仅指有角色参与的任务，即定义中的UserTask。

5. Execution：执行计划，流程实例和流程执行中的所有节点都是Execution，如UserTask、ServiceTask等。

2.2.2. 服务接口

1. ProcessEngine：流程引擎的抽象，通过它我们可以获得我们需要的一切服务。

2. RepositoryService：Activiti 中每一个不同版本的业务流程的定义都需要使用一些定义文件，部署文件和支持数据(例如BPMN2.0 XML文件，表单定义文件，流程定义图像文件等)，这些文件都存储在Activiti内建的Repository中。RepositoryService 提供了对 repository的存取服务。

3. RuntimeService： 在Activiti中，每当一个流程定义被启动一次之后，都会生成一个相应的流程对象实例。RuntimeService提供了启动流程、

查询流程实例、 设置获取流程实例变量等功能。此外它还提供了对流程部署，流程定义和流程实例的存取服务。

4. TaskService: 在Activiti中业务流程定义中的每一个执行节点被称为一个Task，对流程中的数据存取，状态变更等操作均需要在Task中完成。 TaskService提供了对用户Task 和Form相关的操作。它提供了运行时任务查询、领取、完成、删除以及变量设置等功能。

5. IdentityService: Activiti中内置了用户以及组管理的功能，必须使用这些用户和组的信息才能获取到相应的Task。IdentityService提供了对Activiti 系统中的用户和组的管理功能。

6. ManagementService: ManagementService提供了对Activiti流程引擎的管理和维护功能，这些功能不在工作流驱动的应用程序中使用，主要用于Activiti系统的日常维护。

7. HistoryService: HistoryService用于获取正在运行或已经完成的流程实例的信息，与RuntimeService中获取的流程信息不同，历史信息包含已经持久化存储的永久信息，并已经被针对查询优化。

现在至少要知道有这些对象和接口。并结合Activiti Api这一章节来看，你就会对部署流程、启动流程、执行任务等操作有一个基本的概念。之后编写一个简单的单元测试，主要为了测试activiti.cfg.xml配置的是否正确，流程是否可以被部署即可。

至于与Spring的集成，一定要熟悉基于Spring配置Activiti，以及事务的处理。

3. 入门示例（参考手册中10分钟教程）

3.1. 概述 下面开始编写一个示例。这个Demo为一个“月度报表申请”流程。由“sales(销售)”组的用户制作月度报表，提交给“management(经理)”组的用户，经理审批该报表，最后结束。流程图如下：

这个Demo完成之后，我们会进行两个测试。一个是代码中的单元测试，就是跑一遍流程，看一下流程在跑的过程中输出的信息；一个是我们将编辑好的 bpmn20.xml文件通过我们之前一分钟入门的示例activiti-explorer应用导入进去，查看它的流程图，并完整执行一遍流程。

在编写这个Demo之前，至少要了解Activiti与Spring如何集成、XxxService各自的任务与作用，并完成上一章的Demo。

3.2. 流程文件xxx.bpmn20.xml

首先，我们就来编写这个流程的bpmn20.xml文件。

<definitions id="definitions"

targetNamespace="http://activiti.org/bpmn20"

xmlns:activiti="http://activiti.org/bpmn"

xmlns="/spec/BPMN/20100524/MODEL">

<process id="financialReport" name="Monthly financial report reminderprocess">

<startEvent id="theStart" />

<sequenceFlow id='flow1' sourceRef='theStart' targetRef='writeReportTask' />

<userTask id="writeReportTask" name="Write monthly financial report" >

<documentation>

Write monthly financial reportfor publication to shareholders.

</documentation>

<potentialOwner>

<resourceAssignmentExpression>

<formalExpression>sales</formalExpression> </resourceAssignmentExpression>

</potentialOwner>

</userTask>

<sequenceFlow id='flow2' sourceRef='writeReportTask' targetRef='verifyReportTask' />

<userTask id="verifyReportTask" name="Verify monthly financial report" >

<documentation>

Verify monthly financial reportcomposed by the accountancy department.

This financial report is goingto be sent to all the

company shareholders.

</documentation>

<potentialOwner>

<resourceAssignmentExpression>

<formalExpression>management</formalExpression>

</resourceAssignmentExpression>

</potentialOwner>

</userTask>

<sequenceFlow id='flow3' sourceRef='verifyReportTask' targetRef='theEnd' />

<endEvent id="theEnd" />

</process>

</definitions>

这里对部分代码进行解释。

1) 文件的开头部分，这里的id对于Activiti来说，应该叫做key。创建流程实例时，会根据此id来得到这个流程。

2) 开始流程。

3) 顺序流（就是连接各个节点的指向线）

sourceRef和targetRef分别为起始节点和目标节点。

4) 描述用户任务

id为该用户任务的标识。

documentation为该用户任务的描述。

5) 分配用户

可以把任务分配给指定的用户，也可以分配给指定的组，并且可以有多个，详见用户手册。

3.3. Spring配置文件

这里配置了数据源、事务管理、流程引擎及几个必要的xxxService。这里数据源使用的是dbcp。数据库信息就配置成你自己本地数据库的信息，如果不会配置。

<bean id="dataSource" class="mons.dbcp.BasicDataSource" destroy-method="close">

<property name="driverClassName" value="com.mysql.jdbc.Driver" /> <property name="url" value="jdbc:mysql://localhost:3306/activiti"/>

<property name="username" value="root"/>

<property name="password" value="root"/>

<property name="initialSize" value="20" />

<property name="maxActive" value="50"/>

<property name="maxIdle" value="20"/>

<property name="minIdle" value="10"/>

</bean>

<bean id="transactionManager"

class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"></property>

</bean>

<bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration">

<property name="dataSource" ref="dataSource" />

<property name="transactionManager" ref="transactionManager" />

<property name="databaseSchemaUpdate" value="true" />

<property name="jobExecutorActivate" value="false" />

</bean>

<bean id="processEngine" class="org.activiti.spring.ProcessEngineFactoryBean"> <property name="processEngineConfiguration" ref="processEngineConfiguration" />

</bean>

<bean id="repositoryService" factory-bean="processEngine"

factory-method="getRepositoryService" />

<bean id="runtimeService" factory-bean="processEngine"

factory-method="getRuntimeService" />

<bean id="taskService" factory-bean="processEngine"

factory-method="getTaskService" />

<bean id="historyService" factory-bean="processEngine"

factory-method="getHistoryService" />

<bean id="managementService" factory-bean="processEngine"

factory-method="getManagementService" />

<tx:annotation-driven transaction-manager="transactionManager" />

注：bpmn20.xml 文件中用到了两个用户组（sales、management），是因为我们启动Tomcat运行activiti-explorer应用初始化时自动就会往数据库里添加一些数据，其中用户组的表中就会添加几条记录，其中就包括这两个组，所以不用管它怎么来的，总之数据库里有这两个组就对了。而应用默认使用的是内存数据库，服务一停止数据也就没有了。所以为了进行单元测试，需要按前面讲的修改数据库配置的方法：

把activiti-explorer应用的数据库配置改成你自己的本地数据库的信息，我使用的是Mysql数据库。再启动tomcat运行应用（目的就是为了让数据库有数据），这时你的本地数据库就有数据了，可以编写测试用例进行单元测试了。

3.4. 编写测试用例 1) 读取Spring配置文件，注入流程所需的Service

2) 编写测试方法

public void monthtest() {

// 部署流程定义

repositoryService.createDeployment().addClasspathResource("myProcess.bpmn20.xml").deploy();

// 启动流程实例

String procId

= runtimeService.startProcessInstanceByKey("financialReport").getId();

// 获得第一个任务

List<Task> tasks

= taskService.createTaskQuery().taskCandidateGroup("sales").list();

for (Task task : tasks) {

System.out.println("Following task is available for sales group: " +

task.getName());

// 认领任务这里由认领，因为是sales组的成员

taskService.claim(task.getId(), "fozzie");

}

// 查看

tasks = taskService.createTaskQuery().taskAssignee("fozzie").list();

for (Task task : tasks) {

System.out.println("Task for fozzie: " + task.getName());

// 执行(完成)任务

taskService.complete(task.getId());

}

// 现在0了

System.out.println("Number of tasks for fozzie: "

+ taskService.createTaskQuery().taskAssignee("fozzie").count()); // 获得第二个任务

tasks = taskService.createTaskQuery().taskCandidateGroup("management").list(); for (Task task : tasks) {

System.out.println("Following task is available for accountancy group:" + task.getName());

// 认领任务这里由认领，因为是management组的成员 taskService.claim(task.getId(), "kermit");

}

// 完成第二个任务结束流程

for (Task task : tasks) {

taskService.complete(task.getId());

}

// 核实流程是否结束,输出流程结束时间

HistoricProcessInstancehistoricProcessInstance

= historyService.createHistoricProcessInstanceQuery()

.processInstanceId(procId).singleResult(); System.out.println("Process instance end time: " +

historicProcessInstance.getEndTime());

}

3) 运行示例，Demo完成。这就是一个最简单的流程，通过这个流程，了解到Activiti中流程是怎么流的，我们怎么控制它。

3.5. 导入activiti-explorer 1) 单元测试完成后，我们可以将该bpmn20.xml文件导入之前我们部署的

activiti-explorer应用中：点击流程的流程设计工作区，点击导入，将刚才我们编写的文件导入进去。

2) 导入之后在右上角点击部署。

3) 在已部署流程定义中我们可以看到这个流程，及它的流程图。

4) 点击启动流程，该流程就会被启动，再点击任务中，列队就会有该任务了，而且是分配给sales的，这正是我们定义流程时所分配给的用户组啊。注意，现在只有sales组的用户才可以看到此任务！

5) sales组的用户进入之后点击“签收”，该任务就分配给该用户了，然后该用户就可以进行处理，也就是在代办任务和受邀里。

6) 进去之后点击完成任务，该任务就流到下一个节点，也就是流转到management组中去了，要由management组的用户去处理。

7) 于是这时候，队列中management组就有一个新的任务了，等待management组的成员来“签收”，并完成任务。该流程也就结束了。

8) 此时就可以查看历史任务了，就是我们这里的“已归档”。用户完成的任务会在这里显示。

这就是整个Demo的编写、测试过程。这样一个小小的流程基本能够体现出Activiti的功能及使用方法。

4. Eclipse中的Activiti插件

Activiti有一个Eclipse插件，Activiti Eclipse Designer，可用于图形化建模、测试、部署 BPMN 2.0的流程。这样就不用我们自己去编写繁琐的流程文件了。具体安装方法见手册。

4.1. 安装 打开 Help-> Install New Software.在如下面板中 , 点击 Add 按钮, 然后填入下列字段:

Name: Activiti BPMN 2.0 designer

Location:

然后一步步的安装就可以了。

4.2. 使用 至于如何使用，文档中介绍的非常详细，这里基于我初次使用的经验，强调几点：

1) 安装之后将“保存bpmn文件时创建图片文件”勾选上。这样你每次保存bpmn文件时，会为你自动创建图片文件。

2) 节点的所有属性可在properties控制台中设置。

3) 在使用设计器之前，先去钻研BPNM2.0规范吧，了解BPNM结构（可参看用户手册），才能画出符合逻辑且完美的流程图。

该例为使用Activiti Eclipse Designer设计的“请假”流程图。