jBPM4入门

jBPM4是一个可扩展的、灵活的流程引擎,可以作为一个独立的服务器运行或嵌入到任何Java应用程序中。jBPM项目不支持从jBPM3到jBPM4的迁移。jBPM4的运行环境需要jdk5或者以上版本；如果需要执行一些ant脚本，则需要在apache ant1.70或者以上的版本。

         

jBPM4有两个核心对象Configuration和ProcessEngine。ProcessEngine是一个服务工厂，负责创建jBPM的每个服务（类似于Hibernate中的SessionFactory）。在ProcessEngine接口里面有如上图中的六个服务的定义：RepositoryService（知识仓库）、ExecuteService（执行）、TaskService（任务）、HistoryService（历史）、ManagementService（管理）和IdentityService（身份）。

Configuration是jBPM的配置文件管理对象，即资源加载对象。负责加载jBPM的各种配置如：数据库连接配置、事务配置、身份认证、jpdl等相关配置，即加载jBPM项目中的jbpm.cfg.xml和jbpm.hibernate.cfg.xml配置文件中的各种配置信息。

在Configuration中以单例的形式创建ProcessEngine对象，ProcessEngine是线程安全的，所有的线程和请求都使用同一个ProcessEngine对象。

一、服务简介

          

RepositoryService是流程资源服务接口。提供对流程定义部署信息的更新与查询操作、以List或Spring方式返回查询所有开始活动的名称、以流或set集合的方式获得资源名等服务；

ExecutionService是流程执行接口。提供一系列对流程实例的操作，主要以byId或byKey两种对称的方式提供，另外提供一些signal方法，与jBPM3中的signal方法功能完全类似。此外，执行接口还提供一些流程变量的查询，查询创建实例时添加一些信息。

TaskService是人工任务接口。提供任务的一些操作。

HistoryService是流程历史服务接口。提供对已完成流程的操作。

ManagementService是流程管理接口。操作针对系统运营商,需要保持流程引擎启动并运行。这个功能通常通过web控制台管理公开

IdentityService是身份认证服务接口。jBPM提供的一些关于用户和用户组的操作。

二、流程变量

jBPM4的流程变量有两个：流程实例变量和任务变量。

对流程实例和任务的操作时完全类似：

流程实例有的流程Id、流程名称以及他们的对应关系，任务也有任务Id、任务名称以及他们的对应关系；

流程实例有流程实例变量，任务也有任务变量；

…………

在启动流程实例时，有ByKey和ById两种方式，一般使用ByKey的方式，因为在开发期间可能会重复部署同一个流程，每一个新的版本都会对应一个唯一的Id，而ByKey的方式会默认选择最高版本的流程，非常方便。

流程实例跟任务其实很好区分：办一件事儿肯定是分为第一步，第二步……的。第一步交给A去做，第二步交给B去做，每一个步骤都是一个任务，所有的任务就组成了一个流程实例。所以，流程实例的变量的范围是大于任务变量的范围的，故在jBPM4中，流程实例不能拿到任务的信息，任务的变量能够拿到流程实例的信息，并且不同的流程实例，不同的任务变量不能互相访问。

对于执行中的任务，如果需要修改执行任务人，必须在任务执行前进行修改，任务一旦执行就不能再进行修改，否则报错。

三、jPDL

全称是jBoss jPBM Process Definition Language，这种一种构建于jBPM架构之上的流程语言之一。jPDL提供了图形化处理的界面，跟VB语言差不多，拖拖拽拽就能做出个东西来，非常直观。这里面提供了很多图形化节点：

start和end节点在每个jBPM项目中都会用到，分别为开始节点和结束节点；

state节点

状态节点，它在使用特别简单的任务的情况下适用。比如就等待一个人确认一下，就往下走，这时候就可以使用state节点。state节点的使用也较为简单，一般就是包括那些必须的步骤：部署流程、创建流程实例、查看流程、完成流程等。

task节点

人工任务节点，使用任务节点，一般是相对复杂的操作，在任务节点需要做一些操作：做一个表单的处理呀，角色的处理呀之类的处理。对task节点的操作也相对复杂：

task任务分配有四种方式：Assignee、Swimlanes、assignmentHandler和Candidate-groups。

Assignee方式最常用，也最经典，这种方式能够直接分配。如在任务中设置assignee="A"属性，获取任务是根据A标识进行获取；

AssignmentHandler方式为动态分配任务。这种方式将配置该到了Java代码中。在每个task标签里面设置assignment-handler子标签，并配置其class属性，每个class对应一个handler，在handler里面配置相应的任务标识信息。该handler需要继承import org.jbpm.api.task.AssignmentHandler。获取任务时，根据在handler中的标识获取任务；

swimlanes是泳道方式，泳道顾名思义，完全类似于UML中的活动图的泳道的定义。这种方式使用时，泳道就类似于变量的概念。如果该流程实例的某些任务需要多次用到某个用户，那么就在任务开始前定义一个泳道，然后任务中用到该用户的，则设置上用到标记。

candidate-groups方式有一个中间传递的过程。这种方式适用于一个任务分配给一个部门，然后该部门经理制定一个人去完成该任务的情况。这种方式不直接分配给个人。它将一个任务同时分配给一组人，然后该组的所有人都能通过组的方式（也就是在组里）看到该任务。然后将任务分配给某人之后，只有获得任务的人能够通过个人的方式看到该任务。

decision节点

这是条件判断的分支节点。如下面一个请假流程：

       

对于decision节点，有三种方式实现。第一种设置decision节点的expr属性，如expr="${node}"，绑定流程实例时，通过map的方式将transition（即连线）的name属性值与流程实例进行绑定。第二种不在decision节点中进行设置，分别在transition节点的子节点condition中设置条件，如：

<transition name="小于2天" to="组长" g="-52,-22">
      	<condition expr="${days lt 2}"/>
      </transition>

第三种方式在decision节点下设置handler子节点，在java代码中进行判断去向。

fork-join分支活动节点

fork与join节点是对应出现的，也就是说有fork节点，就会有join节点。该节点的特点是流程刚开始时，会同时流转到fork的下一级的所有节点。有且只有所有任务都完成时，才会流转到join的下一节点。

关于节点，当然还有很多，但是常用的就这些。了解了本文所讲的内容，那么恭喜你，jBPM4你就算是入门了。至于流利的上手做开发，还需要在日后慢慢理解深入。