摘录:学习JBPM工作流

注册于: 13/02/2007 00:00:00 帖子总数: 61 离线

三、学习JPDL
3.1 、简介
JPDL（JBPM Process Definition Language）是JBPM流程定义语言。JPDL详细定义了这个状态图的每个部分，如: 开始、结束状态，状态之间的转换等。这种语言的定义对于用户来说比较容易理解，也比较容易对其进行扩展。
一个JBPM的流程定义XML文件中包含一个< process-definition>元素，而一个< process-definition>元素又包含零个或一个< description>元素，零个或多个的< swimlane>元素，一个< start-state>元素，零个或多个的< state>元素或< decision>元素或< fork>元素或< join>元素，以及零个或多个的< action>元素，零个或多个<task-node>和<node>元素，一个< end-state>元素等等。此外，< process definition>元素有一个标示符，以“name”属性来表示，这个属性必须存在，用来表示该流程的名称。

3.2 、流程版本（Version）

我们的流程XML文件定义完成之后，接下来的工作就是要将其发布到对应的数据库中，当我们每次将我们的流程定义部署到数据库时，部署时流程的名称就是前面提高的<process definition>里定义的name”属性的值。
JBPM的版本机制允许在数据库中多个同名流程定义共存，流程实例以当时的最新版本来启动，并且在它的整个生命周期中将保持以相同的流程定义执行。当一个新的版本被部署，新的流程实例以新版本启动，而老的流程实例则以老的流程定义继续执行。
在部署的时候，jbpm 安排一个版本（version）号码（数字）给流程定义。为了实现安排version号码，如果它是第一个版本（version），JBPM采取1+或者1。从ProcessDefinition pd=JbpmContext.getGraphSession()
.findLatestProcessDefinition("processName")
中可以通过一个给定的processName查找最近的流程定义，这里的processName就是前面我们在定义流程的时候在<process definition>里定义的name”属性的值，这个属性就是用来表示该流程的名称。如我们的下列代码就是要列出JBPM数据库里的有所有最后一次发布的流程定义的版本：
JbpmContext context=JbpmContext.getCurrentJbpmContext();
List ls=context.getGraphSession().findLatestProcessDefinitions();
/*
这里返回的List是ProcessDefinition的集合
*/

3.3 、流程定义
3.3.1 process-definition(流程定义)
流程定义的根节点，是所有节点的父节点
名称类型多样性描述
name 属性可选的流程的名称。
swimlane 元素 [0..*] 流程中使用的泳道。泳道表示流程角色，它们被用于任务分配。
start-state 元素 [0..1] 流程起始状态。注意，没有起始状态的流程是合法的，但是不能被执行。
{end-state|state|node|task-node|process-state|super-state|fork|join|decision}
元素 [0..*] 流程定义的节点。注意，没有节点的流程是合法的，但是不能被执行。
event
元素 [0..*] 作为一个容器服务于动作的流程事件。
{action|script|create-timer|cancel-timer}
元素 [0..*] 全局定义的的动作，可以在事件和转换中引用。注意，为了被引用，这些动作必须指定名称。
task
元素 [0..*] 全局定义的任务，可以在动作中使用。
exception-handler
元素 [0..*] 一个异常处理器列表，用于这个流程定义中的委托类所抛出的所有异常。

3.3.2 node(自动节点)
这种节点和State相反，也称自动节点。当业务程序实例执行到这个节点，不会停止执行。而是会继续往下执行。如果该节点存在多个离开转向。那么，就会执行其中的第一个离开转向，在Node状态中，不需要外部参与者的参与，业务流程的这个部分是自动的、即时完成的。
名称类型多样性描述
{action|script|create-timer|cancel-timer}
事件 1 用于表示这个节点行为的定制动作。
普通节点元素
请参考普通节点元素。

3.3.3 start-state(开始状态)
start-state是我们整个流程的开始节点，所有的流程实例从这里开始。
名称类型多样性描述
Name 属性可选的节点的名称。
Task 元素 [0..1] 起始一个流程实例的任务，或者用来捕获流程发起者
Event 元素 [0..*] 支持的事件类型：｛node-leave｝。
transition 元素 [0..*] 离开转换，每个离开节点的转换必须有一个不同的名称。
exception-handler 元素 [0..*] 一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。

3.3.4 end-state(结束节点)
对于每一个流程定义都会有一个结束节点，与开始节点对应
名称类型多样性描述
Name 属性必需的结束状态的名称。
event
元素 [0..*] 支持的事件类型：｛node-enter｝。
exception-handler
元素 [0..*] 一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。

3.3.5 state(状态)
State节点也叫手工节点，进入到这种节点，整个流程的执行就会中断。直到系统外参与者发起继续执行的命令，即调用signal或end方法，业务程序实例的执行才能够继续下去。
名称类型多样性描述
name 属性必需的节点的名称。
async 属性 {true|false}，默认是false 如果设置为true，这个节点将会异步执行。请参考“第13章异步继续”。

transition
元素 [0..*] 离开转换。每个离开节点的转换必须有一个不同的名称，最多只允许所有离开转换中的一个没有名称。第一个转换被指定为默认转换，当离开节点而没有指定转换时，默认转换发生。
event
元素 [0..*] 支持的事件类型：｛node-enter|node-leave｝。
exception-handler
元素 [0..*] 一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。
timer
元素 [0..*] 指定一个定时器，用来监视节点中的一个执行所持续的时间。

3.3.6 task-node (任务节点)
其性质和node节点一样，在没有task的时候，也都是自动执行，不等待。task-node被归类为一个等待节点，是指在task-node中的task列表中的task没有全部执行完之前，它会一直等待。Task可以在task-node节点下定义，也可以挂在process-definition节点下。最普遍的方式是在task-node节点下定义一个或多个任务。默认情况下，流程在task-node节点会处于等待状态，直到所有的任务被执行完毕。Task的执行是按顺序执行的，任务都完成后，token仍然不会指向后面的节点；需要自己手动调用processInstance.signal()才会驱动流程到下面的节点。
名称类型多样性描述
signal 属性可选的 {unsynchronized|never|first|first-wait|last|last-wait}，默认是last。signal指定了任务的完成对流程执行继续的影响。
create-tasks 属性可选的 {yes|no|true|false}，默认是true。当需要在运行时通过计算来决定哪个任务将被创建时，可以设置为false，如果这样的话，在node-enter事件上加一个动作，在动作中创建任务，并且把create-tasks设置为false。
end-tasks 属性可选的 {yes|no|true|false}，默认是false。如果设置end-tasks为true，在离开节点时，所有打开的任务将被结束。
task
元素 [0..*] 当执行到达本节点时所应被创建的任务。
普通节点元素
请参考普通节点元素。

为了帮助读者理解task-node节点的signal属性，这里举例如下：

对于这样的流程定义：
<task-node name='a'>
<task name='laundry' />
<task name='dishes' />
<task name='change nappy' />
<transition to='b' />
</task-node>
a) 这里没有定义signal属性的值，这就表明当节点中的三个任务都完成后，流程才进入后面的节点

b) 当<task-node name='a' signal='unsynchronized'>表明token不会在本节点停留，而是直接到后面的节点

c) 当<task-node name='a' signal='never'>表明三个任务都完成后，token仍然不会指向后面的节点；需要自己手动调用processInstance.signal()才会驱动流程到下面的节点

d) 当<task-node name='a' signal='first'>表明只要有一个任务完成后，token就指向后面的节点

e) 当<task-node name='a' signal='first-wait'>表明当第一个任务实例完成时继续执行；当在a节点入口处没有任务创建时，token在a任务节点处等待，直到任务被创建或完成。

f) 当<task-node name='a' signal='last'>时，这是默认值，和不设置signal属性的情况相同。

g) 当<task-node name='a' signal='last-wait'>时，当最后一个任务实例完成时候继续执行下去。当a这个任务节点没有任务被建立时,任务节点等待直到任务被建立。

3.3.7 fork(分支)
一个fork把一个执行路线分割成多个执行路线. 默认分支的行为是为每个离开分支转换建立一个子令牌,在令牌要到达的分支之间建立一个父母-子女关系
名称类型多样性描述
name 属性必需的节点的名称。
async 属性 {true|false}，默认是false 如果设置为true，这个节点将会异步执行。请参考“第13章异步继续”。

transition
元素 [0..*] 离开转换。每个离开节点的转换必须有一个不同的名称，最多只允许所有离开转换中的一个没有名称。第一个转换被指定为默认转换，当离开节点而没有指定转换时，默认转换发生。
event
元素 [0..*] 支持的事件类型：｛node-enter|node-leave｝。
exception-handler
元素 [0..*] 一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。
timer
元素 [0..*] 指定一个定时器，用来监视节点中的一个执行所持续的时间。

3.3.8 join(联合)
默认联合(join)假设所有来自同一个父母的子令牌联合，当在上使用fork(分支)这个情形就出现了并且所有令牌分支建立，并且到达同一个联合(join)。当全部令牌都进入联合的时候联合就结束了，然后联合将检查父母-子女，当所有兄弟令牌到达联合(join)，父母令牌将传播(唯一的)离开转换，当还有兄弟令牌活动时，联合的行为将作为等待状态。
名称类型多样性描述
name 属性必需的节点的名称。
async 属性 {true|false}，默认是false 如果设置为true，这个节点将会异步执行。请参考“第13章异步继续”。

transition
元素 [0..*] 离开转换。每个离开节点的转换必须有一个不同的名称，最多只允许所有离开转换中的一个没有名称。第一个转换被指定为默认转换，当离开节点而没有指定转换时，默认转换发生。
event
元素 [0..*] 支持的事件类型：｛node-enter|node-leave｝。
exception-handler
元素 [0..*] 一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。
timer
元素 [0..*] 指定一个定时器，用来监视节点中的一个执行所持续的时间。
对于Join节点，我们知道默认是要等到所有分支都到了流程才能往下继续走，要改变这一情况，我们可以通过给该节点加Action的方法改变该Join节点的Discriminator，就可以使只要有一个分支到达流程就可以继续执行的效果了，如下面的Action:
package workflow.test.action;
//这里通过设置Discriminator可以实现只要有一个分支到达流程就可以继续了，它的默认值是false
import org.jbpm.graph.def.ActionHandler;
import org.jbpm.graph.exe.ExecutionContext;
import org.jbpm.graph.node.Join;
public class JoinAction implements ActionHandler{
public void execute(ExecutionContext arg0) throws Exception {
Join join=(Join)arg0.getNode();
join.setDiscriminator(true);
}
}
3.3.9 decision(决策)
一个decision用以决定在多个执行路径中哪个才可以被执行。如果你是一个程序员，把它可以理解成switch case结构即可，一个decision能够具有许多离开的transition。
名称类型多样性描述
handler
元素要么指定“handler”元素，或者在转换上指定条件。一个org.jbpm.jpdl.Def.DecisionHandler的实现名称。
transition
元素 [0..*] 离开转换。决策的离开转换可以被扩展为拥有一个条件，决策会查找条件计算为true的第一个转换，没有条件的转换被认为计算为true（为了建模“otherwise”分支）。请参考condition元素。

普通节点元素
请参考普通节点元素。

Handler所指定的DecisionHandler的实现类里的decide方法返回一个字符串，表示要执行哪个transition，如下例：
package workflow.qingjia.shenpi.common;
import org.jbpm.graph.exe.ExecutionContext;
import org.jbpm.graph.node.DecisionHandler;
public class ForkDecision implements DecisionHandler{
public String decide(ExecutionContext arg0) throws Exception {
String dayCount=(String)arg0.getVariable("dayCount");
String go="to boss approve";
if(Integer.parseInt(dayCount)>10){
go="to join";
}
return go;
}
}

3.3.10 transition(变迁)
变迁用来指定节点之间的连接。transition元素放在node里面，那么这个transition就会从这个节点出离开。
名称类型多样性描述
name 属性可选的转换的名称。注意，每个节点的离开转换必须有一个不同的名称。
to 属性必需的目标节点的分级名称，有关分级名称的更多信息请参考“第9.6.3节分级命名”。

{action|script
|create-timer
|cancel-timer}
元素 [0..*] 发生转换时将要执行的动作。注意，转换的动作无需放入事件（因为只有一个事件）。
exception-handler
元素 [0..*] 一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。

3.3.11 event(事件)
JBPM定义了一系列与工作流节点元素相关联的事件，例如，流程实例运行过程中，可以触发节点进入（node-enter)、节点离开（node-leave）、流程启动（process-start）、流程结束（process-end）、任务创建（task-create）、任务分派（task-assign）、任务启动（task-start）等事件。
在流程定义时，JBPM的事件均与action绑定。事件的触发将导致相应actions的执行。
名称类型多样性描述
type 属性必需的表示相对于事件要放置的元素事件类型。
{action|script|create-timer|
cancel-timer}
元素 [0..*] 在这个事件上将要执行的动作列表。

3.3.12 action(动作)
一个action是一段java代码。在流程执行期间在一些事件之上定义，这样会在相关事件触发时自动在工作流引擎上执行。

名称类型多样性描述
name 属性必需的动作的名称。当动作被指定名称后，它们可以在流程定义中被查出，这对于运行时动作以及仅一次声明动作是有用的。
class 属性或者用ref-name，或者用expression。实现org.jbpm.graph.def.ActionHandler接口的类的全名。
ref-name 属性或者用class。所引用动作的名称。如果指定一个引用动作，则本动作不需要再做处理。
expression 属性或者指定一个class，或者ref-name。一个解决一个方法的jPDL表达式。请参考“第16.3节表达式”。

accept-
propagated-events 属性可选的 {yes|no|true|false}，默认是yes|true。如果设置为false，则动作仅在本动作元素的触发事件上被执行。更多信息，请参考“第9.5.4 事件传播”。

config-type 属性可选的 {field|bean|constructor|configuration-property}。指定动作对象将被怎样创建以及本元素的内容怎样象配置信息那样被动作对象所使用。
async 属性 {true|false} 默认false，这意味着动作将在当前执行的线程中被执行。如果设置为true，一个消息将被发送到命令执行器，并且执行器组件将在一个独立的事务中同步执行动作。
{内容} 可选的 action的内容可以被作为你定制动作实现的配置信息，这是考虑到可重用的委托类的创建。有关委托配置的更多信息，请参考“第16.2.3节委托配置”。

3.3.13 script(脚本)
Script里是动作执行的beanshell脚本. 更多有关beanshell的的信息请参考Beanshell的网站： http://www.beanshell.org 。如下所示
<process-definition>
<event type="node-enter">
<script>
System.out.println("this script is entering node "+node);
</script>
</event>
...
</process-definition>
表格 16.16
名称类型多样性描述
name 属性可选的脚本动作的名称。当动作被指定名称后，它们可以在流程定义中被查出，这对于运行时动作以及仅一次声明动作是有用的。
Accept
-propagated
-events 属性可选的[0..*] {yes|no|true|false}，默认是yes|true。如果设置为false，则动作仅在本动作元素的触发事件上被执行。更多信息，请参考“第9.5.4 事件传播”。

expression 元素 [0..1] beanshell脚本。如果你没有指定variable元素，可以写表达式作为脚本元素的内容（忽略expression元素标签）。
variable
元素 [0..*] 脚本所需变量。如果没有指定变量，则当前令牌的所有变量将被装载到脚本，当你想要限制装载到脚本中的变量数量时使用variable。

3.3.14 expression（表达式）
Expression里可书写Beanshell脚本
名称类型多样性描述
{内容} 一个beanshell脚本。

3.3.15 variable(变量)
一个是变量是一种key-value对。它与过程实例（一次过程执行）相关联。Key是java.lang.string，value是任何java类型的任何pojo。所以任何是java类型，即使不给jbpm知道也能被应用到变量中。JBPM的流程变量在尽量模仿java.util.map的语义。这一点可以通过JBPM的API来了解。也就是说一个变量只能当它被插入时被赋值，任何java类型都可以作为变量中的value。

名称类型多样性描述
name 属性必需的流程变量的名称。
access 属性可选的默认是read,write，用逗号分割的一个访问列表。迄今为止，使用的访问仅为read，write和required。
mapped-name 属性可选的默认是变量的名称。用来指定变量名称被映射的名称，mapped-name的含义依赖于这个元素所被使用的上下文。对于一个脚本，将是一个脚本变量名称；对于一个任务控制器，将是任务表单参数的标签；对于一个process-state，将是在子流程中使用的变量名称。

3.3.16 handler(句柄)
Handler是在定义一个decision时需要为其定义一个DecisionHandler时采用。
名称类型多样性描述
expression 属性或者用class 一个jPDL表达式，返回结果被用toString()方法转换为字符串，结果字符串应该与某个离开转换匹配。请参考“第16.3 表达式”。

class 属性或者用ref-name 实现了org.jbpm.graph.node.DecisionHandler接口的类的全名。
Config
-type 属性可选的 {field|bean|constructor|configuration-property}。指定动作对象将被怎样创建以及本元素的内容怎样象配置信息那样被动作对象所使用。
{内容} 可选的 action的内容可以被作为你定制动作实现的配置信息，这是考虑到可重用的委托类的创建。有关委托配置的更多信息，请参考“第16.2.3节委托配置”。

3.3.17 timer(定时器)
定时器timer可以被用于decision fork join node process-state state super-state task-node，可以设置开始时间duedate和频率repeat，定t器动作可以是所支持的任何动作元素，如action或script，会运行我们设置的动作。
timer 还有一个很重要的属性cancel-event，这个是timer和task结合时使用的，任务定时器的cancel-event可以被定制。默认情况下，当任务被结束时（=完成）任务上的定时器将被取消，这是通过在定时器上使用cancel-event属性，流程开发者可以定制诸如task- assign或task-start。cancel-event支持多个事件，通过在属性中指定一个用逗号分割的列表，可以组合cancel-event 的类型。
名称类型多样性描述
name 属性可选的定时器的名称。如果没有指定名称，则采用外部的节点名称。注意，每个定时器应该有一个唯一的名称。
duedate 属性必需的所指定的定时器创建到定时器执行之间的期限（可以用业务时间来表示）。请参考“第14.1节期限”中的语法。
repeat 属性可选的 {duration|’yes’|’true’}当一个定时器在预期时间执行后，“repeat”可选项指定了在离开节点之前重复的执行定时器之间的期限。如果指定为true或yese，则与duedate相同的期限被使用。请参考“第14.1节期限”的语法。

transition 属性可选的当定时器执行、定时器事件触发后以及执行动作时时所使用的转换名称。
cancel-event 属性可选的这个属性只用在任务的定时器中，它指定了定时器将被取消的事件。默认是task-end事件，但是也可以被设置为如task-assign或task-start。cancel-event的类型也可以通过指定一个用逗号分割的列表被组合。
{action|script|
create-timer|
cancel-timer}
元素 [0..*] 当定时器被触发时所应被执行的动作。

3.3.18 create-timer(创建定时器)
Create-timer是定时器的创建
名称类型多样性描述
name 属性可选的定时器的名称。这个名称可被用于用一个cancel-timer动作取消定时器。
duedate 属性必需的所指定的定时器创建到定时器执行之间的期限（可以用业务时间来表示）。请参考“第14.1节期限”中的语法。

repeat 属性可选的 {duration|’yes’|’true’}当一个定时器在预期时间执行后，“repeat”可选项指定了在离开节点之前重复的执行定时器之间的期限。如果指定为true或yese，则与duedate相同的期限被使用。请参考“第14.1节期限”的语法。

transition 属性可选的当定时器执行、定时器事件触发后以及执行动作时时（如果要）所获取的转换名称。

3.3.19 cancel-timer(取消定时器)
Cancel-timer是定时器的取消
名称类型多样性描述
name 属性可选的要被取消的定时器的名称。

3.3.20 task(任务)
Task 是是流程定义里的一部分，它决定了task instance的创建和分配
名称类型多样性描述
name 属性可选的任务的名称。命名的任可以被引用并且可以通过TaskMgmtDefinition被查出。
blocking 属性可选的 {yes|no|true|false}，默认是false。如果blocking设置为true，当任务没有结束时节点不能被离开；如果设置为false（默认），令牌上的一个新号被用来继续执行并离开节点。默认设置为false，因为通常是由用户接口来强制阻塞。
signalling 属性可选的 {yes|no|true|false}，默认是true。如果设置signalling为false，则本任务将没有触发令牌继续的能力。
duedate 属性可选的一个绝对的期限表达式或象“第14章业务日历”中解释的业务时间。
swimlane 属性可选的引用一个swimlane，如果在任务上指定了一个swimlane，则assignment将被忽略。
priority 属性可选的 {highest,high,normal,low,lowest}之一。作为选择，可以为priority指定任何整数，供参考：(highest=1,lowest=5)。
assignment
元素可选的描写一个委托，该委托将在任务被创建时把任务分配给一个参与者。
event
元素 [0..*] 支持的事件类型：｛task-create|task-start|task-assign|task-end｝。为了任务分配，我们特别的为TaskInstance添加了一个非持久化的属性previousActorId。
exception
-handler 元素 [0..*] 一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。
timer
元素 [0..*] 指定一个监视本任务执行期限的一个定时器。对于任务定时器特殊的是可以指定cancel-event，cancel-event默认是task-end，但是它可以被自定义如task-assign或task-start。
controller
元素 [0..1] 指定流程变量怎样被转换为任务表单参数。任务表单参数有用户界面使用，用力向用户表现一个任务表单。

3.3.21 swimlane(泳道)
实际应用中，一个人是一个流程中多个Task的参与者(actor)的情况是很常见的。在jbpm中通过创建一个swimlane并且把swimlane赋给一个task的方式来设置当前task的参与者（actor）。一个业务流程中的swimlane可以被看做为一个参与者的参与者对象的名称，当然它不一定是固定的某个人，它可以是一个用户组，一个特定用户的角色等。首次执行到达一个Task，赋给该Task的一个swimlane就会算出参与者(actor)。
名称类型多样性描述
name 属性必需的泳道的名称。泳道可以被引用并且可以通过TaskMgmtDefinition被查出。
assignment
元素 [1..1] 指定泳道的分配。这个分配在本泳道中的第一个任务实例被创建时完成。

3.3.22 assignment(委派)
当流程执行到某个Task的时候，引时流程引挚要调用相应的swimlane或assignment将当前的task分配（委派）给某个参与者，外部参与者可以是一个人也可以是某个系统等。
名称类型多样性描述
expression 属性可选的由于历史原因，这个属性的表达式不是jPDL表达式，而是对jBPM身份组件的一个分配表达式。有关怎样写jBPM身份组件表达式的更多信息，请参考“第11.11.2节分配表达式”。注意，这个依赖于jbpm身份组件。

actor-id 属性可选的一个actorId，可以与pooled-actors协同使用。actor-id被作为一个表达式，因此你可以引用一个固定的actorId，如actor-id=”bobthebuiler”；或者你可以引用一个可以返回一个字符串的属性或方法，如actor-id=”myVar.actorId”，这将调用任务实例变量“myVar”上的getActorId方法。
Pooled
-actors 属性可选的一个逗号分割的actorId列表，可以与actor-id协同使用。一个固定的参与者池可以指定如下：pooled-actors=”chicagobulls,pointersisters”。 pooled-actors被作为一个表达式，因此你可以引用一个返回String[]、Collection、或一个逗号分割的池中的参与者列表的属性或方法。
class 属性可选的一个实现org.jbpm.taskmgmt.def.AssignmentHandler接口的类的全名称。
config-type 属性可选的 {field|bean|constructor|configuration-property}。指定分配处理器对象（assignment-handler-object）对象将被怎样创建以及本元素的内容怎样象配置信息那样被分配处理器对象所使用。
{内容} 可选的 assignment元素的内容可以被作为分配处理器（AssignmentHandler）实现的配置信息，这是考虑到可重用的委托类的创建。有关委托配置的更多信息，请参考“第16.2.3节委托配置”。

3.3.23 controller(控制器)
在任务执行时，可能需要读、写流程变量；在任务完成并提交时，可能需要写流程变量。为此，jBPM提供了"任务变量"的概念。在某些情况下，任务变量和流程变量并非简单的一一对应关系，例如，三个流程变量代表三个月的销售额，任务变量只需要它们的平均值。为实现任务与流程实例之间的信息交流，jBPM设置了任务控制器机制。该机制也采用递进模式：首先，jBPM提供基本（默认）的任务控制器；如果不敷使用，二次开发人员可以使用自定义的任务控制器。 jBPM的任务控制器机制在流程变量和任务变量之间架起了一座桥梁。

名称类型多样性描述
class 属性可选的一个实现org.jbpm.taskmgmt.def.TaskControllerHandler接口的类的全名称。
Config
-type 属性可选的 {field|bean|constructor|configuration-property}。指定分配处理器对象（assignment-handler-object）对象将被怎样创建以及本元素的内容怎样象配置信息那样被分配处理器对象所使用。
{内容} controller元素的内容要么是指定的任务控制处理器的配置信息（如果指定了class属性），要么必须是一个variable元素列表（如果没有指定任务控制器）。
variable
元素 [0..*] 如果没有通过class属性指定任务控制处理器，则controller元素的内容必须是变量列表。

3.3.24 process-state 子流程
process-state是JBPM提供的用来处理子流程的节点，一个process-state只能对应一个子流程，究竟指到哪个子流程可以在process-state的action里指定，当token执行到指定的子流程时，子流程就已经启动，不用像启动主流程一样手工启动子流程。其它部分的处理就和普通的流程没有区别了。

名称类型多样性描述
name 属性必需的名称。

3.3.25 condition 条件

名称类型多样性描述
{内容}或属性
表达式必需的 condition元素的内容是一个计算结果为布尔值的jPDL表达式。决策采用第一个表达式处理结果为true的转换（按在processdefinition.xml中的顺序），如果没有条件处理结果为true，则采用默认离开转换（也就是第一个）。

3.3.26 exception-handler 异常处理
Jbpm的异常处理机制仅仅集中于java异常，流程定义本身的执行不会导致什么异常，只有在执行委托类时才会导致异常。
在流程定义（process-definitions）、节点（nodes）和转换（transitions）上，可以指定一个异常处理（exception-handlers）清单，每个异常处理（exception-handler）有一个动作列表，当在委托类中发生异常时，会在流程元素的父层次搜索一个适当的异常处理（exception-handler），当它被搜索到，则异常处理（exception-handler）的动作将被执行。
注意，Jbpm的异常处理机制与java异常处理不完全相似。在java中，一个捕获的异常可以影响控制流，而在Jbpm中，流程不会被Jbpm异常处理机制所改变。异常要么被捕获，要么不捕获，没有被捕获的异常被抛向客户端（例如客户端调用token.signal()），而被捕获的异常则是通过Jbpm的exception-handler，对于被捕获的异常，图执行仍会继续，就像没有异常发生一样。
注意，在处理异常的动作中，可以使用Token.setNode(Node node)把令牌放入图中的任何节点。
名称类型多样性描述
exception-class 属性可选的指定与本异常处理器所匹配的java throwable类，如果这个没有指定这个属性，则它匹配所有异常（java.lang.Throwable）。
action
元素 [1..*] 当异常被异常处理器捕获时将要执行的动作列表。
小结
看到这里，我们已经对JPDL的流程定义语言有了较深的理解，接下来我们可以自己动手写一些流程定义的文件，以此加深对JPDL的理解。我们来看一下下面的流程定义文件内容：
<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="" name="test">
<!—定义一个开始结点，名为start，指向fork1-->
<start-state name="start">
<transition name="" to="fork1"></transition>
</start-state>

<!—在fork1分支结点上，我们定义了两个走向（transition）tr1和tr2，其中tr1指向top-state节点,tr2指向一个process-state，当token到达for1时会自动形成两个child token，沿着tr1和tr2的指向继续向执行-->
<fork name="fork1">
<transition name="tr1" to="top-state"></transition>
<transition name="tr2" to="test-sub-process"></transition>
</fork>

<!—top-state是一个state类型的节点，也就是前面提到的手工节点-->
<state name="top-state">
<transition name="to test-task" to="test-task"></transition>
</state>

<!—test-task是一个task-node类型的节点，它可以有多个task节点，生成我们的taskInstance，这里我们定义了三个节点-->
<task-node name="test-task" signal="first">
<task name="task-a"></task>
<task name="task-b"></task>
<task name="task-c"></task>
<transition name="to buttom-node" to="buttom-node"></transition>
</task-node>


<node name="buttom-node">
<transition name="" to="join1"></transition>
</node>

<!—在test-sub-process里我们加上了一个子流程处理，子流程定义我们写在了里面定义的enter-sub-process-action 里-->
<process-state name="test-sub-process">
<event type="node-enter">
<action name="enter-sub-process-action" class="gaojie.process.action.EnterSubProcessAction"></action>
</event>
<transition name="" to="join1"></transition>
</process-state>

<!—join1是一个join节点，与fork节点对应，从fork分支出发的所有child token汇集到join后继续向下执行-->
<join name="join1">
<transition name="" to="end"></transition>
</join>

<!—最后是结束结点，流程执行到此就宣告结束了-->
<end-state name="end"></end-state>
</process-definition>