jBPM流程定义语言（JPDL）

发表于

 

JPDL指定了xml模式和打包所有流程定义相关文件到一个流程档案的机制。

16.1 流程档案

一个流程档案就是一个zip文件，流程档案中
的核心文件是processdefinition.xml，该文件的主要信息是流程图，processdefinition.xml文件还包括有关动作和
任务的信息。流程档案也可以包含其他流程相关文件，如classes(类的字节码文件)、任务的ui-forms(任务的用户界面窗体)、…

16.1.1 部署流程档案

可以用3种方式部署流程档案：用流程设计器工具，用ant任务或编程。

使用设计器工具部署流程档案仍然在构建阶段。

使用ant任务部署流程档案可以按照如下方式：

<target name=”deploy.par”>

 <taskdef name=”deploypar” classname=”org.jbpm.ant.DeployParTask”>

    <classpath –make sure the jbpm-[version].jar is in this classpath–/> 

 </taskdef> 

 <deploypar par=”build/myprocess.par” />

</target>

要一次部署多个流程档案，可以使用嵌套的fileset元素，file属性是可选的。Ant任务的其他属性是：

l        cfg：cfg是可选的，默认值是“hibernate.cfg.xml”，hibernate配置文件包含jdbc连接数据库的属性以及映射文件。

l        properties：properties是可选的，并且覆盖所有hibernate.cfg.xml文件中的hibernate相同属性。

l        createschema：如果设置为true，则jbpm数据库模式（数据表）在流程部署前被创建。

流程档案还可以通过使用类org.jbpm.jpdl.par.ProcessArchiveDeployer编程被部署。

16.1.2 流程版本

流程定义不应该改变，因为预测流程变化带来的所有可能的影响是非常困难的（或者说是不可能的）。

围绕这个问题，jBPM有一个明智的流程版本
机制。版本机制允许在数据库中多个同名流程定义共存，流程实例以当时的最新版本来启动，并且在它的整个生命周期中将保持以相同的流程定义执行。当一个新的
版本被部署，新的流程实例以新版本启动，而老的流程实例则以老的流程定义继续执行。

流程定义是指定的流程图以及其他一组相关的
java classes(字节码文件)的结合体，有两种方式可以使java classes在jBPM运行环境是可用的：确保这些java
classes对于jBPM类装载器是可见的，这通常意味着你可以把委托classes放入一个.jar文件，然后再放入
jbpm-[version].jar文件;另外，java
classes也可以被包含在流程档案中，当在流程档案中包含自己的委托classes时（它们不被jbpm类装载器可见），jBPM也将在这些
classes上应用版本机制。有关流程类装载的更多信息可以在“16.2委托”中找到。

当一个流程档案被部署时，将在jBPM数据库中创建一个流程定义，流程定义基于流程定义的名称被版本化。当一个被命名的流程档案被部署，部署器将分配一个版本号。为了分配版本号，部署器将查询同名流程定义的最高版本号，并且在其上加1，未命名的流程定义其版本号总是-1。

16.1.3 改变已部署的流程定义

在部署到jBPM数据库之后改变流程定义有很多潜在的缺陷，因此非常不鼓励这样做。

事实上，对于流程定义会有很多可能的改变，这些流程定义中的某些也许是无害的，但是改变意味着会更合理。

因此请考虑通过这种途径移植流程实例到新的定义。

如果你打算这么做，下面是需要考虑的点：

使用hibernate的更新：你可以加载一个流程定义，改变它并且使用hibernate session保存它。Hibernate session可以用JbpmContext.getSession()方法获取。

二级缓存：在你更新一个存在的流程定义之后，该流程定义需要从二级缓存中移除，请参看“第7.10节二级缓存”。

16.1.4 移植流程实例

改变流程定义可能会要求转换执行（正在执行的流程实例）到一个新的流程定义，由于业务流程的持续性，考虑到这不是没有价值的。当前，这还是一个实验区域，还没有在支持范围之内。

就象你所了解的那样，流程定义数据、流程实例
数据（运行时数据）、以及日志数据有明显的区别。使用这种方式，在jBPM数据库中创建一个独立的新的流程定义（例如，可以部署一个相同流程的新的版
本），然后运行时信息被转换到新的流程定义。这可能包括导致一个旧流程指向的节点在新流程中已被移除的转化，因此，仅仅新的数据才在数据库中被创建，但是
这样一个流程执行被遍布在两个流程实例对象上，这可能会成为工具和统计计算中棘手的部分。当资源允许时，我们将在以后做支持，例如，流程实例上会添加一个
指向其前一个实例的指针。

16.1.5 流程变换

一个转换类用来帮助你把jBPM2.0流程档案转换到jBPM3.0兼容的流程档案。创建一个用来放置转换后流程档案的输出目录，从jBPM3.0分发的构建目录键入下面命令行：

java –jar converter.jar 输入目录 输出目录

用你的jBPM2.0流程档案位置替换“输入目录”，用创建的放置新的转换后流程档案的目录替换“输出目录”。

16.2 委托

委托是用来在流程执行中包含用户自定义代码的机制。

16.2.1 jBPM类装载器

jBPM类装载器是装载jBPM类的装载器，
这意味着jbpm-3.x.jar库在类装载器的classpath中。要使类对于jBPM类装载器可见，就把它们放入一个jar文件，并把这个jar文
件放入jbpm-3.x.jar，或者放入web应用的WEB-INF/lib文件夹下。

16.2.2 流程类装载器

委托类由它们各自流程定义的流程类装载器来装载，流程类装载器是以jBPM类装载器为父的类装载器。流程类装载器添加某个流程定义的所有类，你可以通过把类放入流程档案的/classes文件夹而把类添加到流程定义。注意，这仅仅当你想要把所添加的类版本化时才有用。

如果版本化不是必须的，则使类对于jBPM类装载器可见效率会更高。

16.2.3 委托配置

委托类包含在流程执行中将被调用的用户代码，最一般的例子就是动作（action），在这种情况下，ActionHandler接口的一个实现在流程事件上被调用。委托在processdefinition.xml中被指定，当指定一个委托时可以提供3部分的数据：

l        类名（必需的）：委托类的完整类名。

l        配置类型（可选的）：指定实例化和配置委托类对象的方式。默认情况下，默认的构造器被使用并且配置信息被忽略。

l        配置（可选的）：按照配置类型所要求格式对委托对象的配置信息。

下面是所有配置类型的描述：

16.2.3.1配置类型field

这是默认的配置类型，配置类型field将首
先实例化一个委托类的对象，然后按照配置中的指定将值设置到对象的成员（field）中。配置是xml格式的，其元素与类的成员名称一致，元素的内容文本
被放入相应的成员。如果是必需且可能的，则元素的内容文本被转换为成员类型。

所支持的类型转换：

l        String当然不需要转换，但是它会被修整（trim）。

l        原始类型，例如int、long、float、double、…

l        原始类型的基本包装类。

l        列
表（list）、集合（set）、以及聚集（collection）。这种情况下，xml内容的每个元素被看作聚集的一个元素，并且在转换中被递归的解
析。如果元素类型与java.lang.String不同，则需要通过为类型属性指定一个完整类型名来标出。例如，下面片断将把一个字符串的
ArrayList注入成员“numbers”：

<numbers>

 <element>one</element>

 <element>two</element>

 <element>three</element>

</numbers>

元素中的文本可以被转换为任何拥有一个String构造器的对象，要使用String类型之外的其他类型，则在成员元素（本例中的“numbers”）中指定element-type。

下面是另外一个map的例子：

<numbers>

 <entry><key>one</key><value>1</value></entry>

 <entry><key>two</key><value>2</value></entry>

 <entry><key>three</key><value>3</value></entry>

</numbers>

l        maps。这种情况，每个成员元素需要有一个子元素key和一个元素value。key和value都被递归的使用转换规则解析，与聚集（collection）完全一样，如果没有类型属性被指定，则假定转换到java.lang.String。

l        org.dom4j.Element

l        其他类型，字符串构造器被使用。

例如下面的类…

public class MyAction implements ActionHandler {

 // access specifiers can be private, default, protected or public

 private String city;

 Integer rounds;

 …

}

…下面是有效的配置：

…

<action class=”org.test.MyAction”>

 <city>Atlanta</city>

 <rounds>5</rounds>

</action>

…

 

16.2.3.2配置类型bean

与field配置类型相似，除了属性被通过setter方法设置之外，而不是直接设置到成员上，使用相同的转换规则。

16.2.3.3配置类型constructor

这种实例化会取委托的xml元素的所有内容，并且把它们作为文本传入委托类的构造器。

16.2.3.4配置类型configuration-property

首先，使用默认的构造器，然后这种实例化将取出委托xml元素的所有内容，并且把它们作为文本传入方法void configure(String)。（就像jBPM2中一样）

16.3 表达式

对于某些委托，支持一种象JSP/JSF
EL那样的表达式语言。在动作（actions）、分配（assignments）和决策（decision）条件中，你可以写一个如
expression=“#{myVar.handler[assignments].assign}”的表达式。

这种表达式语言的基础知识可以在J2EE指南中找到。

jPDL表达式语言与JSF表达式语言相似，jPDL EL基于JSP EL，除了使用#{…}符号以及它包括对方法绑定的支持之外。

依赖于上下文，流程变量或者任务实例变量连同下面的内置对象可以被作为变量使用：

l        taskInstance(org.jbpm.taskmgmt.exe.TaskInstance)

l        processInstance(org.jbpm.graph.exe.ProcessInstance)

l        token(org.jbpm.graph.exe.Token)

l        taskMgmtInstance(org.jbpm.taskmgmt.exe.TaskMgmtInstance)

l        contextInstance(org.jbpm.context.exe.ContextInstance)

这个特性在Jboss SEAM环境中变得真正强大，因为jBPM与Jboss SEAM的集成，所有你自己的bean、EJB和其他某种素材在你的流程定义中变得直接可用。

16.4 jBPM XML 模式

jPDL模式是流程档案里的processdefinition.xml文件中所使用的模式。

16.4.1 确认

在解析一个jPDL XML文件时，当遇到两种情形时jBPM将靠jPDL模式验证你的文档：第一种，模式在XML文件中被引用，如下

<process-definition xmlns=”urn:jbpm.org:jpdl-3.1”>

 …

</process-definition>

第二种，xerces解析器被放置在了classpath。

jPDL模式可以在${jbpm.home}/src/java.jbpm/org/jbpm/jpdl/xml/jpdl-3.1.xsd或http://jbpm.org/jpdl-3.1.xsd中找到。

16.4.2 process-definition

表格 16.1

名称

类型

多样性

描述

name

属性

可选的

流程的名称。

元素

[0..*]

流程中使用的泳道。泳道表示流程角色，它们被用于任务分配。

元素

[0..1]

流程起始状态。注意，没有起始状态的流程是合法的，但是不能被执行。

元素

[0..*]

流程定义的节点。注意，没有节点的流程是合法的，但是不能被执行。

元素

[0..*]

作为一个容器服务于动作的流程事件。

元素

[0..*]

全局定义的的动作，可以在事件和转换中引用。注意，为了被引用，这些动作必须指定名称。

元素

[0..*]

全局定义的任务，可以在动作中使用。

元素

[0..*]

一个异常处理器列表，用于这个流程定义中的委托类所抛出的所有异常。

 

16.4.3 node

表格 16.2

名称

类型

多样性

描述

事件

1

用于表示这个节点行为的定制动作。

 

 

请参考普通节点元素。

 

16.4.4 普通节点元素

表格 16.3

名称

类型

多样性

描述

name

属性

必需的

节点的名称。

async

属性

{true|false}，默认是false

如果设置为true，这个节点将会异步执行。请参考“第13章异步继续”。

元素

[0..*]

离开转换。每个离开节点的转换必须有一个不同的名称，最多只允许所有离开转换中的一个没有名称。第一个转换被指定为默认转换，当离开节点而没有指定转换时，默认转换发生。

元素

[0..*]

支持的事件类型：｛node-enter|node-leave｝。

元素

[0..*]

一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。

元素

[0..*]

指定一个定时器，用来监视节点中的一个执行所持续的时间。

 

16.4.5 start-state

表格 16.4

名称

类型

多样性

描述

name

属性

可选的

节点的名称。

元素

[0..1]

起始一个流程实例的任务，或者用来捕获流程发起者，请参考“第11.7节开始任务中的泳道”。

元素

[0..*]

支持的事件类型：｛node-leave｝。

元素

[0..*]

离开转换，每个离开节点的转换必须有一个不同的名称。

元素

[0..*]

一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。

 

16.4.6 end-state

表格 16.5

名称

类型

多样性

描述

name

属性

必需的

结束状态的名称。

元素

[0..*]

支持的事件类型：｛node-enter｝。

元素

[0..*]

一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。

 

16.4.7 state

表格 16.6

名称

类型

多样性

描述

 

 

请参考普通节点元素。

 

16.4.8 task-node

表格 16.7

名称

类型

多样性

描述

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，在离开节点时，所有打开的任务将被结束。

元素

[0..*]

当执行到达本节点时所应被创建的任务。

 

 

请参考普通节点元素。

 

16.4.9 process-state

表格 16.8

名称

类型

多样性

描述

元素

1

与被节点相关联的子流程。

元素

[0..*]

指定在子流程发起时数据如何从超流程拷贝到子流程，以及在子流程结束时数据如何从子流程拷贝到超流程。

 

 

请参考普通节点元素。

 

16.4.10 super-state

表格 16.9

名称

类型

多样性

描述

元素

[0..*]

超状态节点，超状态可以嵌套。

 

 

请参考普通节点元素。

 

16.4.11 fork

表格 16.10

名称

类型

多样性

描述

 

 

请参考普通节点元素。

 

16.4.12 join

表格 16.11

名称

类型

多样性

描述

 

 

请参考普通节点元素。

 

16.4.13 decision

表格 16.12

名称

类型

多样性

描述

元素

要么指定“handler”元素，或者在转换上指定条件。

一个org.jbpm.jpdl.Def.DecisionHandler的实现名称。

元素

[0..*]

离开转换。决策的离开转换可以被扩展为拥有一个条件，决策会查找条件计算为true的第一个转换，没有条件的转换被认为计算为true（为了建模“otherwise”分支）。请参考condition元素。

 

 

请参考普通节点元素。

 

16.4.14 event

表格 16.13

名称

类型

多样性

描述

type

属性

必需的

表示相对于事件要放置的元素事件类型。

元素

[0..*]

在这个事件上将要执行的动作列表。

 

16.4.15 transition

表格 16.14

名称

类型

多样性

描述

name

属性

可选的

转换的名称。注意，每个节点的离开转换必须有一个不同的名称。

to

属性

必需的

目标节点的分级名称，有关分级名称的更多信息请参考“第9.6.3节分级命名”。

元素

[0..*]

发生转换时将要执行的动作。注意，转换的动作无需放入事件（因为只有一个事件）。

元素

[0..*]

一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。

 

16.4.16 action

表格 16.15

名称

类型

多样性

描述

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节委托配置”。

 

16.4.17 script

表格 16.16

名称

类型

多样性

描述

name

属性

可选的

脚本动作的名称。当动作被指定名称后，它们可以在流程定义中被查出，这对于运行时动作以及仅一次声明动作是有用的。

accept-propagated-events

属性

可选的[0..*]

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

expression

元素

[0..1]

beanshell脚本。如果你没有指定variable元素，可以写表达式作为脚本元素的内容（忽略expression元素标签）。

元素

[0..*]

脚本所需变量。如果没有指定变量，则当前令牌的所有变量将被装载到脚本，当你想要限制装载到脚本中的变量数量时使用variable。

 

16.4.18 expression

表格 16.17

名称

类型

多样性

描述

 

{内容}

 

一个beanshell脚本。

 

16.4.19 variable

表格 16.18

名称

类型

多样性

描述

name

属性

必需的

流程变量的名称。

access

属性

可选的

默认是read,write，用逗号分割的一个访问列表。迄今为止，使用的访问仅为read，write和required。

mapped-name

属性

可选的

默认是变量的名称。用来指定变量名称被映射的名称，mapped-name的含义依赖于这个元素所被使用的上下文。对于一个脚本，将是一个脚本变量名称；对于一个任务控制器，将是任务表单参数的标签；对于一个process-state，将是在子流程中使用的变量名称。

 

16.4.20 handler

表格 16.19

名称

类型

多样性

描述

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节委托配置”。

 

16.4.21 timer

表格 16.20

名称

类型

多样性

描述

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的类型也可以通过指定一个用逗号分割的列表被组合。

元素

[0..*]

当定时器被触发时所应被执行的动作。

 

16.4.22 create-timer

表格 16.21

名称

类型

多样性

描述

name

属性

可选的

定时器的名称。这个名称可被用于用一个cancel-timer动作取消定时器。

duedate

属性

必需的

所指定的定时器创建到定时器执行之间的期限（可以用业务时间来表示）。请参考“第14.1节期限”中的语法。

repeat

属性

可选的

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

transition

属性

可选的

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

 

16.4.23 cancel-timer

表格 16.22

名称

类型

多样性

描述

name

属性

可选的

要被取消的定时器的名称。

 

16.4.24 task

表格 16.23

名称

类型

多样性

描述

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)。

元素

可选的

描写一个委托，该委托将在任务被创建时把任务分配给一个参与者。

元素

[0..*]

支持的事件类型：｛task-create|task-start|task-assign|task-end｝。为了任务分配，我们特别的为TaskInstance添加了一个非持久化的属性previousActorId。

元素

[0..*]

一个异常处理器列表，用于这个流程节点中的委托类所抛出的所有异常。

元素

[0..*]

指定一个监视本任务执行期限的一个定时器。对于任务定时器特殊的是可以指定cancel-event，cancel-event默认是task-end，但是它可以被自定义如task-assign或task-start。

元素

[0..1]

指定流程变量怎样被转换为任务表单参数。任务表单参数有用户界面使用，用力向用户表现一个任务表单。

 

16.4.25 swimlane

表格 16.24

名称

类型

多样性

描述

name

属性

必需的

泳道的名称。泳道可以被引用并且可以通过TaskMgmtDefinition被查出。

元素

[1..1]

指定泳道的分配。这个分配在本泳道中的第一个任务实例被创建时完成。

 

16.4.26 assignment

表格 16.25

名称

类型

多样性

描述

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节委托配置”。

 

16.4.27 controller

表格 16.26

名称

类型

多样性

描述

class

属性

可选的

一个实现org.jbpm.taskmgmt.def.TaskControllerHandler接口的类的全名称。

config-type

属性

可选的

{field|bean|constructor|configuration-property}。指定分配处理器对象（assignment-handler-object）对象将被怎样创建以及本元素的内容怎样象配置信息那样被分配处理器对象所使用。

 

{内容}

 

controller元素的内容要么是指定的任务控制处理器的配置信息（如果指定了class属性），要么必须是一个variable元素列表（如果没有指定任务控制器）。

元素

[0..*]

如果没有通过class属性指定任务控制处理器，则controller元素的内容必须是变量列表。

 

16.4.28 sub-process

表格 16.27

名称

类型

多样性

描述

name

属性

必需的

子流程的名称。要知道怎样测试字流程，请参考“第18.3节测试子流程”。

version

属性

可选的

子流程的版本。如果没有指定版本，则给定流程的最新版本将被使用。

 

16.4.29 condition

表格 16.28

名称

类型

多样性

描述

 

{内容}或属性

表达式

必需的

 condition元素的内容是一个计算结果为布尔值的jPDL表达式。决策采用第一个表达式处理结果为true的转换（按在processdefinition.xml中的顺序），如果没有条件处理结果为true，则采用默认离开转换（也及时第一个）。

 

16.4.30 exception-handler

表格 16.29

名称

类型

多样性

描述

exception-class

属性

可选的

指定与本异常处理器所匹配的java throwable类，如果这个没有指定这个属性，则它匹配所有异常（java.lang.Throwable）。

元素

[1..*]

当异常被异常处理器捕获时将要执行的动作列表。
转自：http://i.mop.com/gabriel80