JBPM工作流引擎研究
文 档 号：
当前版本： 1.0
作 者： 钟辉
完成日期： 2009-07-16
参考文档：
文档的阅读方法：加了红色标记的标题下的内容请重点阅读，没加的可以先不阅读
JBPM工作流引擎研究 1
1 jbpm相关概念 4
1.1什么是jbpm 4
1.2 需要了解的知识点 4
1.2.1 jBPM数据存储 4
1.2.2 工作流的基本构成 4
1.2.3工作流的工作方式 5
1.3 jbpm工作流执行步骤 5
1.4 JBPM中典型节点类型 6
1.5 一个简单的例子 6
1.5.1第一个流程定义文件 7
1.5.2流程调用 7
1.6 JBPM的事件(event)和行为(action) 7
1.7 JBPM的任务 8
1.8 任务分配 8
1.9 JBPM的任务管理 9
1.10 使用jBPM的优势 9
1.11 使用jBPM的问题 9
1.12 结论 10
2 jPDL简介： 11
2.1流程定义描述 11
2.2 流程的程序接口说明 12
2.2.1动作处理接口（ActioinHandler） 12
2.2.2判定处理接口（DecisionHandlder） 13
2.2.3委派处理接口（AssignmentHandler） 13
2.3 创建jBPM的数据库表 13
2.4 jBDL流程元素表 15
3 jBPM开发整理 16
3.1 概述 16
3.2 环境配置 17
3.3 开发步骤 18
3.3.1创建jBPM项目 18
3.3.2配置数据库 18
3.3.3 流程定义 18
3.3.4 JUnit测试 19
3.5 部署 19
4 jBPM APIs整理 19
4.1 ProcessDefinition 19
4.2 Configuration、Context 19
4.3 ContextInstance上下文实例 20
4.4 t.log变量日志管理 20
4.5 Task任务管理 21
4.6 Swimlane的整理 21
4.7 Token的整理 21
4.8 Node 22
5 jBPM 数据库表整理 23
5.1 jbpm_action表 23
5.2.jbpm_processdefinition表 23
5.3.jbpm_transition表 23
5.4.jbpm_ node表 24
5.5.jbpm_delegation表： 25
5.6.jbpm_event表： 25
6 Boss3.8.2中的集成分析 29
6.1.集成目的 29
6.2.集成思路分析 30
6.3.集成方案分析 31
6.4.集成类UML分析 31
6.5.改进的工作流集成方案研究 32
6.5.1 SpringModules（Spring与jbpm集成的桥梁）与JBPM的集成 32
6.5.2 JbpmTemplate的改写 37
1 jbpm相关概念
1.1什么是jbpm
jBPM，全称是Java Business Process Management，是一种基于J2EE的轻量级工作流管理系统。
jBPM的一个特色是采用了它自己定义的JBoss jBPM Process definition language (jPdl)。jPdl认为一个业务流程可以被看作是一个UML状态图。jPdl就是详细定义了这个状态图的每个部分，如起始、结束状态，状态之间的转换等。
jBPM的另一个特色是它使用Hibernate来管理它的数据库。Hibernate是目前Java领域最好的一种数据持久层解决方案。通过Hibernate，jBPM将数据的管理职能分离出去，自己专注于业务逻辑的处理。
从一个具体的示例，我们是看不出有jBPM的，也就是说jBPM在后台起着作用。从一个固定流程的项目中，我们看不出jBPM的优势。不过，如果在一个流程不确定，经常需要变动的项目中，jBPM的好处将会显然出来。应用jBPM后，改变流程只需改
变流程描述文件。
1.2 需要了解的知识点
1.2.1 jBPM数据存储
jBPM需要把初始化数据和工作流定义存储到数据库中，它定义了一套数据结构来存储这些数据，这也是该容器本身的特点。
JBPM 需要数据库支持，jBPM会把自己的一个初始化数据存储到数据库，同时工作流的数据也是存储到数据库中的。 jBPM 使用 Hibernate 来做为自己的存储层，因此只要是 Hibernate 支持的数据库， jBPM 也就支持。
注：在 JBoss 自带的示例中，并没有设置数据库，那是因为 jBPM 默认使用的是内存数据库 hsqldb 。
1.2.2 工作流的基本构成
jBPM作为一种工作流的实现, 从广义地来看, 工作流又都有哪些基本的构成呢? 一般来说, 一个工作流有如下的三个大构件:
1、流程定义. 通过这个构件来修改现有的流程或定义新的流程.
2、流程执行. 把前面定义好地流程在自己的系统中调用, 从而执行整个业务逻辑, 也就是让前面定义的的流程"流"起来.
3、流程执行监测. 记录流程执行过程中的相关数据, 以便于性能调优等.
一个流程实例是通过一个流程ID与一个业务实体进行绑定。所以每一个业务实体都包含一个流程实例ID。一个业务实体对应一个流程
1.2.3工作流的工作方式
1、我们首先需要定义一个流程(流程定义ProcessDefinition)。
2、该流程可能是多个人发起的，每个人发起的流程称为不同的流程对象(流程实例)(ProcessInstance)。
3、每个定义的流程都有许多的步骤我们称为节点(Node)。
4、每个执行中的流程的执行路径我们称为路径(Token) 。
1.3 jbpm工作流执行步骤
1、加载（发布）流程定义
这个意思是，我们通过jbpm的designer插件，或者是用其他工具，制定出processDefinition，然后将其加载到应用中的过程。这个加载可以是写入内存中，或者是直接写入数据库等。
2、启动流程
创建流程实例的过程。具体创建实例的方法有多种，可根据自己的需要自行选择。
3、处理任务
在流程流转的过程中，JBPM引擎会为我们生成任务的实例，我们就需要针对这些任务实例来进行处理，然后结束这些任务实例，并推动流程的流转。
4、记录流程的相关状态
记录流程状态这点包括且不限于以下内容：
1）流程实例的开启
2）任务实例的创建
3）任务实例的开始执行
4）任务实例的结束
5）流程实例的结束
1.4 JBPM中典型节点类型
1、start-state (开始状态)
2、end-state (结束节点 )
3、state(状态) State节点也叫手工节点，进入到这种节点，整个流程的执行就会中断。直到系统外参与者发起继续执行的命令，即调用signal或end方法，业务程序实例的执行才能够继续下去。
4、node(自动节点)
这种节点
和State相反，也称自动节点。当业务程序实例执行到这个节点，不会停止执行。而是会继续往下执行。如果该节点存在多个离开转向。那么，就会执行其中的第一个离开转向，在Node状态中，不需要
外部参与者的参与，业务流程的这个部分是自动的、即时完成的。
5、task-node (任务节点)
其性质和node节点一样，在没有task的时候，也都是自动执行，不等待。task-node被归类为一个等待节点，是指在task-node中的task列表中的task没有全部执行完之前，它会一直等待。Task可以在task-node节点下定义，也可以挂在process-definition节点下。最普遍的方式是在task-node节点下定义一个或多个任务。默认情况下，流程在task-node节点会处于等待状态，直到所有的任务被执行完毕。Task的执行是按顺序执行的，任务都完成后，token仍然不会指向后面的节点；需要自己手动调用processInstance.signal()才会驱动流程到下面的节点。
1.5 一个简单的例子
JBPM的流程定义采用XML的方式（实际绝大多数的流程引擎的流程定义都采用的是这种方式），作为测试XML定义我们既可以写在代码当中，也可以以一个独立的XML文件的形式存在。
1.5.1第一个流程定义文件
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns=":jpdl-3.2" name="Hello">
<start-state name="begin">
<transition to="mystate"></transition>
</start-state>
<state name="mystate">
<transition to="end"></transition>
</state>
<end-state name="end"></end-state>
</process-definition>
1.5.2流程调用
//定义流程
//以文件输入流的形式将流程定义文件读入内存
InputStream is = new FileInputStream("l");
ProcessDefinition pd = ProcessDefinition.parXmlInputStream(is);
//定义流程实例，流程的执行token定位在了start-state
ProcessInstance ps = new ProcessInstance(pd);
//执行流程
//获取根路径
Token root = ps.getRootToken();
//沿着“mystate”路径流向下一个节点
root.signal("mystate");
System.out.Node().getName());
//流程往下走
root.signal();
System.out.Node().getName());
}
1.6 JBPM的事件(event)和行为(action)
我们可以在流程执行过程中执行自己的代码， 象触发器一样，在特定的时候触发。
触发点：1.流程转向的时候;
2.流程节点中的某个事件发生的时候.
常用事件：
流程启动（process-start）
流程结束（process-end）
节点进入（node-enter）
节点离开 （node-leave）
任务创建（task-create）
任务分派（task-assign）
任务启动（task-start）等事件。
代码规范：处理触发行为的类必须实现ActionHandler接口
流程中含有事件和Action发布后的数据变化：
1.7 JBPM的任务
Task 是流程定义里的一部分，它决定了task instance的
创建和分配
任务分配: 当流程执行到某个Task的时候，将会引起流程引擎要调用相应的swimlane或assignment将当前的task分配（委派）给某个参与者，外部参与者可以是一个人也可以是某个系统等。
task-node的列子
<process-definition name='the baby process'>
<start-state>
<transition name='baby cries' to='t' />
</start-state>
<task-node name='t'>
<task name='change nappy'>
<assignment class='amples.taskmgmt.NappyAssignmentHandler' />
</task>
<transition to='end' />
</task-node>
<end-state name='end' />
</process-definition>
1.8 任务分配
任务分配有三种方式，我们可以将任务分配给个人或是某个群组
对于个人用户：
1.自己的代码中加入如下语句：TaskInstance.tActorId(String id);
2.在AssignmentHandler中加入assignable.tActorId(String id);
3.在流程定义中的任务定义中加入属性actor-id
取得某角色的任务列表只需要做：
TaskMgmtSession.findTaskInstances(String acotorId);
对于组用户：
1.自己的代码中加入如下语句：TaskInstance. tPooledActorIds(String[])
2.在AssignmentHandler中加入assignable. tPooledActorIds(String[])
3.在流程定义中的任务定义中加入属性pooled-actor-ids
取得某组的任务列表只需要做：
TaskMgmtSession.findPooledTaskInstances(String actorId)
TaskMgmtSession.findPooledTaskInstances(List actorIds)
通过任务管理，我们在开发流程的时候就可以在用户登陆的时候看到需要办理的任务，在你处理完任务后该任务就会从任务列表中删除。
1.9 JBPM的任务管理
我们将带有任务，并且任务有分配给相应的用户或用户组后的流程发布到数据库后，数据库中表数据的变化：
任务表 dbo.JBPM_TASK(任务的静态定义)
任务实例表JBPM_TASKINSTANCE(任务执行实例，动态)
任务参与者dbo.JBPM_POOLEDACTOR
参与者与任务实例之间是多对多的关系中间表：JBPM_TASKACTORPOOL
1.10 使用jBPM的优势
将业务流程复杂的系统结构清晰化，提供系统运行时的灵活性
1、解耦系统业务流程
流程独立，可以使用工具定义和建模，利于跟踪、监控、管理、调度、优化和重整
2、提高系统的灵活性
系统流程定义生产环境的修改和调整，用户和外部工具交互，任务的动态分派
1.11 使用jBPM的问题
1、对当前任务的条件查询
jBPM不提供灵活进行条件查询的api，如果需要，可以自定义hibernate查询，从jbpm相应的数据表中查询任务数据。但需要对jBPM机制比较了解，而且有些复杂条件难以用jBPM本身的信息查到。
2、当前任务的分页
在上一问题的基础上，使用hibernate分页。
3、 统计各个流程实例的状态
可以通过流程实例，在jbpm系统表中查询，也可以在业务表的相应数据上加上状态列来统计。前一个比较麻烦，后一个
比较直观，但不会因使用jBMP而使用工作量减少。
4、 工作流数据与业务数据结合
一般通过在流程实例中添加相应的一笔数据的标识作为变量来关联。也可以有针对性的扩展jbpm的系统表来实现与业务的关联性。
5、 修改流程后的历史数据兼容性问题
Jbpm工作流流程定义有版本的概念，修改流程后要重新发布，与旧的流程不是一个同一个版本。系统可以区别开新旧流程来。
1.12 结论
1、 工作量
初步的结论是：引入工作流技术不会明显减少系统开发工作量。相反，在一般情况下，会增加一部分工作量。
如果项目流程比较少，而且比较固定，则使用工作流技术会明显增加开发工作量。
如果项目流程多，而且比较复杂，则使用工作流技术会使项目结构层次更加清晰、更具有扩展性，根据需求有可能要修改和扩展现有开源工作流类库与数据库结构，也会增加额外的工作量。但权衡之下，利大于弊。
2、 关于业务数据与jBPM本身的数据
理论上说，如果使用jBPM，可以将所有业务数据放到jBPM的context中管理，不再维护业务数据表。但这样的结果是在流程之外的环境（比如在统计报表中）中无法容易的得到业务数据。所以一般会建立业务数据表，我不使用工作流时一样，然后让jBMP从业务数据表中得到业务数据，而不在jBPM中保留业务数据。因此，使用jBPM后，在业务数据方面基本不会减少工作
3、工作流学习成本
工作流本身的概念较复杂，使用jbpm，需要学习其工作流的定义和结构，流程定义工具和语言、了解其数据结构。与其它工作流产品（如Shark）相比，jBPM对Java开发人员来说学习较低成本，在做流程复杂的项目时，学习成本可以接受。
4、 系统用户和角色与工作流整合
流程的流转和任务的分派完成，都是用户在控制，所以需要将用户、角色和权限整合到jbpm工作流中。
5、 系统业务的整合和调整
将流程抽取后，原本连续的业务处理变成一个个的任务节点。需要在每个业务相关处理处添加工作流流程控制、在每个节点处实现相关的业务和流程切入点。
6、适用范围
Jbpm工作流适用于：
项目流程比较多，流程复杂的项目。
系统运行和维护、升级时，流程可能需要修改、调整和跟踪、控制的项目。
2 jPDL简介：
JPDL（JBPM Process Definition Language）是JBPM流程定义语言。JPDL详细定义了这个状态图的每个部分，如: 开始、结束状态，状态之间的转换等。这种语言的定义对于用户来说比较容易理解，也比较容易对其进行扩展。
2.1流程定义描述
除了开始和结束结点外，我们定义了三种类型的结点：
1、任务结点<task-node>
任务结点是一个需
