jBPM jPDL 用户开发手册 3.2.3 - 第21章

第21章 jBPM流程定义语言（JPDL）

JPDL指定一个XML模式和机制来打包所有的流程定义相关的文件进入一个流程包中。

21.1. 流程包

流程包是一个zip文件。流程包中的中心文件是processdefinition.xml。在那个文件中的主要的信息是流程图。processdefinition.xml也包含关于动作和任务的信息。流程包也能包含其他的相关文件，例如类、任务的ui表单（ui-forms）等等。

21.1.1. 部署流程包

有三种方法来完成流程包的部署：使用流程设计器工具、使用一个ant任务或通过编程。

使用流程设计器工具部署流程包在新手工具箱中被支持。在流程包文件夹上点击右键找到“Deploy process archive”选项。新手工具箱服务器上包含jBPM web 应用，它有一个叫ProcessUploadServlet的上传流程包的servlet。这个servlet能够上传流程包和部署他们到缺省配置的jBPM实例上。

使用下面的方式使用ant任务完成部署流程包：

<target name="deploy.par">   <taskdef name="deploypar" classname="org.jbpm.ant.DeployProcessTask">     <classpath --make sure the jbpm-[version].jar is in this classpath--/>    </taskdef>    <deploypar par="build/myprocess.par" /> </target>

为了立即部署多个流程包，使用嵌套的fileset元素。这个文件属性本身是可选的。Ant任务的其他属性是：

l  cfg： cfg 可选，缺省值是'hibernate.cfg.xml'。hibernate配置文件包含到数据库的jdbc连接和映射文件。

l  properties：properties可选，它覆盖hibernate.cfg.xml文件中发现的*all* 属性。

l  createschema：如果设置为true，那么jbpm数据库模式将流程部署前创建。

流程包也能使用类org.jbpm.jpdl.par.ProcessArchiveDeployer通过编程部署。

21.1.2. 流程版本控制

当我们已经部署了一个流程定义，许多执行还没有完成然而有一个流程定义的新版本将要部署时会发生什么呢？

流程实例总是执行那些已经启动的流程定义。但jBPM允许同名的多个流程定义共存于数据库中。所以典型的是，一个流程实例那时会以最新的可用版本启动然后它将以那个相同的流程定义保持执行完成它的生命周期。当一个较新的版本被部署时，新创建的实例将以最新的版本启动，而旧的流程实例按照旧的流程定义继续执行。

如果流程包括引用的Java类，它有两种方式在jBPM运行时环境上生效：通过确保这些类对jBPM的类加载器可见。这通过意味着你可以放你的委托类在一个.jar文件中紧接着jbpm-[version].jar包。那样的话，所有流程定义将看到相同的类文件。Java类也可以包括在流程包中。当你包括委托类在流程包中（那么他们对jbpm类加载器不可见）时，jBPM将在你的流程定义中翻译（version）这些类。更多的关于流程加载的信息可能在21.2 委托部分找到。

当一个流程包部署完时，它在jBPM数据库中创建一个流程定义。流程定义可以根据流程定义名被版本化。当命名的流程包部署完时，部署者将分配一个版本号。为了分配这个号码，部署者将查阅同名的流程定义的最高版本号并增加1。未命名的流程定义总是分配版本号-1。

21.1.3. 变更已部署流程定义

在流程定义已经部署进jBPM数据库后再变更它会有许多的潜在的陷阱。因此，非常不鼓励这么做。

实际上，流程定义有一个完整的多种可能变化。那些流程定义中某些是无害的，但一些其他的变化的影响远远超越预期和期望的那样。

所以请考虑迁移流程实例为一个新的定义来越过这个方案。

万一你考虑它，这些是你要考虑到的点：

使用hibernate更新： 你可以加载流程定义、改变它并用hibernate的会话保存它。Hibernate的会话可以使用方法JbpmContext.getSession()访问。

二级缓存：在你已经更新了一个存在的流程定义后流程定义将需要从二级缓存中移除。也可以查看7.9 二级缓存部分。

21.1.4. 迁移流程实例

一个变更流程定义候选的方案可能是把这个执行转换成一个新的流程定义。请注意这并非琐碎的因为长期的业务流程的天性。当前，这是一个试验区域所以因为这个仍然没有更多随包的支持。

因为你知道在流程定义数据和流程实例数据（运行时数据）有明确区别。使用这个方案，你在jBPM数据库中创建一个独立新流程定义（通过例如部署一个新版本的相同流程）。然后运行时信息被转换成新流程定义。这可能会牵涉到转换导致旧流程中的令牌指向的节点在新版本中已经被移除了。所以在数据库中只有新数据被创建了。但是一个流程的执行通过两个流程实例对象来传播。对于这个工具和统计计算可能变得有点难以理解。当资源允许我们时，我们将来将为这个属性增加支持。例如可能增加一个从一个流程实例到它的前辈指示。

21.1.5. 流程转换

。可以协助你把jBPM 2.0流程包转换成jBPM 3.0兼容的流程包的转换类已经可用了。建立一个输出目录来保存转换后的流程包。从jBPM 3.0发布的构建目录中键入下列的命令行：

java -jar converter.jar indirectory outdirectory

"indirectory"替换成jBPM 2.0流程包驻留的目录，"outdirectory"替换成创建来存储新转换的流程包的输出目录。

21.2.委托

委托是在流程执行中用于包括用户定制代码机制。

21.2.1. jBPM类加载器

jBPM加载器是加载jBPM类的类加载器。意思是，在类加载器的类路径中有库jbpm-3.x.jar。为了让类对jBPM类加载器可视，放他们在一个jar文件中并放这个jar文件除在jbpm-3.x.jar的旁边。例如在这个web应用的WEB-INF/lib文件夹下。

21.2.2. 流程类加载器

委托类使用它们各自的流程定义的流程类加载器被加载。流程类加载器是一个把jBPM类加载器当作父亲的类加载器。流程类加载器增加一个特定流程定义的所有类。你可以增加类到一个流程定义通过在流程包里把他们放在/classes目录下。注意这仅仅是当你想版本化增加到流程定义中的类时才有用的，如果没有必要进行版本化，更加高效的是使用jBPM的类加载器。

如果资源名没有以斜线（/）开头，资源从流程包的/classess目录中加载。如果你想加载classes目录外面的类，那么使用双斜线（//）开头。例如加载定位在流程包文件根上的processdefinition.xml旁边的资源data.xml，你可以用clazz.getResource("//data.xml")或lassLoader.getResourceAsStream("//data.xml")或者是那些变体中的任何一个。

21.2.3. 委托配置

委托类包含从流程执行里调用的用户代码。最常见的例子是动作。就动作来说，一个ActionHandler接口的实现能够在流程的事件上被调用。委托在processdefinition.xml中指定的。当指定一个委托时提供了3种数据：

l  1）类名（必须的）：委托类的完全限定类名。

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

l  3）配置（可选的）：配置类型所要求的委托对象的配置使用的格式。

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

21.2.3.1. 配置类型域

这是缺省的配置类型。config-type域将首先初始化一个委托类对象然后像配置中指定的那样在域中设置值。配置是xml，那里的元素名必须和类的域名一致。元素的内容文本被放在响应域中。如果有必要而且可能的话，元素的内容文本被转换成域的类型。

支持的转换类型：

·         String 当然不需要转换了。但是要去掉

·         原始类型如int、long、float、double等待

·         原始类型的基本的包装类

·         Lists、sets和collections。那样的话xml内容的每个元素采用一个集合元素并且解析、递归地应用转换。如果元素的类型和java.lang.String 不同可以通过使用完全限定类型名指定一个类型属性来标明。例如：下面 片段将注入一个String类型的ArrayList 到域'numbers'：

<numbers> <element>one</element> <element>two</element> <element>three</element> </numbers>

 元素的文本能够被字符器构造器转换成任何对象。为了使用另一种类型，在域元素中（本例中的'numbers'）指定元素类型。

这里有另一个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>

 

·         Maps。在本例中，每一个域元素的元素有一个子元素key和value。Key和元素都使用转换规则被递归地解析。和使用 collections 相同，如果没有指定类型属性假设转换到java.lang.String。

·         org.dom4j.Element

·         任何其他类型，使用字符器构造器。

下列类的中例子：

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> ...

21.2.3.2. 配置类型bean

和配置类型域相同但是然后这一属性通过setter方法来设置，而不是直接在域上。相同的转换被应用。

21.2.3.3. 配置类型构造器

这个例示器（instantiator）将处理委托xml元素的完整内容并在委托类构造器中当作文本传递它。

21.2.3.4. 配置类型配置属性

首先，缺省构造器被使用，然后这个例示器（instantiator）将处理完整的委托xml元素的内容，然后传递它当作文本在方法void configure(String);。（同jBPM 2中的一样）

21.3. 表达式

对于委托中的一些，支持JSP/JSF EL 类表达式语言。在动作、分派和决策条件中，你可以写一个表达式，如expression="#{myVar.handler[assignments].assign}" 。

表达式语言的基础能够在J2EE教程中找到。

jPDL表达式语言同JSF表达式语言类似。意味着jPDL EL基于JSP EL，但它使用#{...}表示法并且它包括了方法绑定的支持。

依赖于上下文，流程变量或任务实例变量连同下列的隐含对象一起能够被用作开始变量：

 

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

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

·         processDefinition (org.jbpm.graph.def.ProcessDefinition)

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

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

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

这个属性在JBoss SEAM环境中变得真的非常强大。因为jBPM和JBoss SEAM的集成，所有的后备bean、EJB和其他的一种原料就在你的流程定义的内部变得可用。感谢加文 ，绝对让人吃惊！:-)

 

 

 

...the subsequent is working on.... :-)