JPDL 是指定的xml模式和机制包装所有的流程定义相关文件到一个流程文档.
流程文档是一个zip文件. 文档的中心流程是 processdefinition.xml . 文件中主要信息是流程图. processdefinition.xml也包含关于动作和任务的信息 . 流程文档也包含其他流程相关文档比如类,任务ui-form ...
发布文档文档可以通过3种方式来做: 用流程设计器工具, 用ant任务或编程实现.
发布任务通过设计器工具依然在开发阶段.
发布任务文档通过ant任务如下: <target name="deploy.par">
<taskdef name="deploypar" classname="org.jbpm.jpdl.par.ProcessArchiveDeployerTask">
<classpath --make sure the jbpm-[version].jar is in this classpath--/>
</taskdef>
<deploypar par="build/myprocess.par" />
</target>
一次发布多个流程文件, 用嵌套的fileset元素. file属性是可选的. 其他ant 任务属性是:
- cfg : cfg 可选的, 默认值是'hibernate.cfg.xml'. hibernate配置文件包含jdbc connection属性和mapping 文件.
- properties : 属性是可选的并且覆盖所有来自hibernate.cfg.xml的同样属性
- createschema : 如果为true, jbpm数据库模式将在发布之前被建立.
流程文档也可通过编程来发使用类 org.jbpm.jpdl.par.ProcessArchiveDeployer
流程定义基本不会改变,因为预测所有流程定义变化是非常困难的.
围绕这个问题, jBPM 有一个久经考验的流程版本机制.版本机制允许多个同名的流程定义在数据库中同时存在. 流程实例使用最后的可用版本并且并且在同一个流程里持续执行知道生命周期结束.当较新的版本被发布, 较新的建立实例将用最新的版本,同时老的流程实例用老的流程定义保持执行.
流程定义是组合声明指定图和一组相关的java classes. Java classes 能被jBPM运行时间环境以2种方式使用: 让这些class被jBPM classloader看到. 这是把你的委托 类放到.jar文件然后到 jbpm-[version].jar . java classes 也能被包括进流程文档. 当你包括你的委托类到流程文档(它们对jbpm classloader是不可见的), jBPM 将使用这些class版本. 关于流程载入的信息参考 13.2章节, “委托”
当流程档案被发布时, 它在jBPM数据库中生成一个流程定义. 流程定义可以被版本化基于基本的流程定义名字.当命名的流程档案被发布时,发布者将分配给它一个版本数字. 为了分配数字,发布者将查询同名的流程最高版本数字加1.没有名字的流程定义版本数字为-1.
13.1.3. 过程转换 Process conversion
一个转换class把jBPM 2.0文档转为3.0兼容流程文档.建立一个输出目录来处理被改变的流程文档. 输入下列命令行来构造jBPM 3.0发布:
java -jar converter.jar indirectory outdirectory
"indirectory"替换为你的jBPM 2.0文档目录."outdirectory"为输出3.0兼容的目录.
委托是一种机制用来在流程执行中包含用户定制代码.
13.2.1. jBPM class loader
jBPM class loader是用来载入 jBPM classes.意思是, classloader有库 jbpm-3.x.jar在它的 classpath. 要想class对jBPM classloader可见必须把它们放在 jbpm-3.x.jar里或者在web应用程序的 WEB-INF/lib
13.2.2. 流程 process class loader
委托类被流程classloader同它们定义一致的流程定义. 流程classLoader以jBPM classLoader为父母 . 流程classLoader增加了特定流程定义的所有类. 你可以增加类到流程定义只要把它们放在流程档案/class文件夹下. 说明这是唯一有用的当你想版本化你加在流程定义里的类. 如果版本是不必要的,那么更加有效的方式是把它们放在jBPM class loader.
委托类包含在流程执行里调用的用户代码. 最常见的例子是动作. 在动作里的情况, 接口 ActionHandler的实现能在流程事件里被调用.委托在processdefinition.xml里 指明. 3个数据可以用于指定委托的时候:
- 1) 类名 (必须的) : 全称唯一的委托类名字.
- 2) 配置类型 (可选) : 指明一个方式来实例和配置委托对象. 默认的配置是默认的构造和配置信息被忽略的.
- 3) 配置 (可选) : 委托对象被配置类型所要求的格式的配置信息.
下面描述所有的配置类型:
13.2.3.1. config-type field
This is the default configuration type. The config-type field will first instantiate an object of the delegation class and then set values in the fields of the object as specified in the configuration. The configuration is xml, where the elementnames have to correspond with the field names of the class. The content text of the element is put in the corresponding field. If necessary and possible, the content text of the element is converted to the field type.
Supported type conversions:
- String doesn't need converting, of course. but it is trimmed.
- primitive types such as int, long, float, double, ...
- and the basic wrapper classes for the primitive types.
- lists, sets and collections. in that case each element of the xml-content is consitered as an element of the collection and is parsed, recursively applying the conversions. if the type of the elements is different from java.lang.String this can be indicated by specifying a type attribute with the fully qualified type name.
- maps. in this case, each element of the field-element is expected to have one subelement key and one element value. The key and element are both parsed using the conversion rules recursively. Just the same as with collections, a conversion to java.lang.String is assumed if no type attribute is specified.
- org.dom4j.Element
- for any other type, the string constructor is used.
For example in the following class... public class MyAction implements ActionHandler {
// access specifiers can be private, default, protected or public
private String city;
Integer rounds;
...
}
...this is a valid configuration: ...
<action class="org.test.MyAction">
<city>Atlanta</city>
<rounds>5</rounds>
</action>
...
13.2.3.2. config-type bean
Same as config-type field but then the properties are set via setter methods, rather then directly on the fields. The same conversions are applied.
13.2.3.3. config-type constructor
This instantiator will take the complete contents of the delegation xml element and passes this as text in the delegation class constructor.
13.2.3.4. config-type configuration-property
First, the default constructor is used, then this instantiator will take the complete contents of the delegation xml element, and pass it as text in method void configure(String);. (as in jBPM 2)
The JPDL schema is the schema used in the file processdefinition.xml in the process archive.
13.3.1. process-definition
Table 13.1.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
optional |
the name of the process |
| swimlane |
element |
[0..*] |
the swimlanes used in this process. the swimlanes represent process roles and they are used for task assignments. |
| start-state |
element |
[0..1] |
the start state of the process. Note that a process without a start-state is valid, but cannot be executed. |
| {end-state|state|node|task-node|process-state|super-state|fork|join|decision} |
element |
[0..*] |
the nodes of the process definition. Note that a process without nodes is valid, but cannot be executed. |
| event |
element |
[0..*] |
the process events that serve as a container for actions |
| {action|script|create-timer|cancel-timer} |
element |
[0..*] |
global defined actions that can be referenced from events and transitions. Note that these actions must specify a name in order to be referenced. |
| task |
element |
[0..*] |
global defined tasks that can be used in e.g. actions. |
| exception-handler |
element |
[0..*] |
a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process definition. |
13.3.3. common node elements
Table 13.3.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
required |
the name of the node |
| transition |
element |
[0..*] |
the leaving transitions. Each transition leaving a node *must* have a distinct name. A maximum of one of the leaving transitions is allowed to have no name. The first transition that is specifed is called the default transition. The default transition is taken when the node is left without specifying a transition. |
| event |
element |
[0..*] |
supported event types: {node-enter|node-leave} |
| exception-handler |
element |
[0..*] |
a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process node. |
| timer |
element |
[0..*] |
specifies a timer that monitors the duration of an execution in this node. |
Table 13.4.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
optional |
the name of the node |
| event |
element |
[0..*] |
supported event types: {node-leave} |
| transition |
element |
[0..*] |
the leaving transitions. Each transition leaving a node *must* have a distinct name. |
| exception-handler |
element |
[0..*] |
a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process node. |
Table 13.5.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
required |
the name of the end-state |
| event |
element |
[0..*] |
supported event types: {node-enter} |
| exception-handler |
element |
[0..*] |
a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process node. |
Table 13.7.
| Name |
Type |
Multiplicity |
Description |
| signal |
attribute |
optional |
{unsynchronized|never|first|first-wait|last|last-wait}, default is last. signal specifies the effect of task completion on the process execution continuation. |
| create-tasks |
attribute |
optional |
{yes|no|true|false}, default is true. can be set to false when a runtime calculation has to determine which of the tasks have to be created. in that case, add an action on node-enter, create the tasks in the action and set create-tasks to false. |
| task |
element |
[0..*] |
the tasks that should be created when execution arrives in this task node. |
| common node elements |
|
|
See common node elements |
Table 13.8.
| Name |
Type |
Multiplicity |
Description |
| sub-process |
element |
1 |
the sub process that is associated with this node |
| variable |
element |
[0..*] |
specifies how data should be copied from the super process to the sub process at the start and from the sub process to the super process upon completion of the sub process. |
| common node elements |
|
|
See common node elements |
Table 13.12.
| Name |
Type |
Multiplicity |
Description |
| handler |
element |
either a 'handler' element or conditions on the transitions should be specified |
the name of a org.jbpm.jpdl.Def.DecisionHandler implementation |
| transition |
element |
[0..*] |
the leaving transitions. The leaving transitions of a decision can be extended with a condition. The decision will look for the first transition for which the condition evaluates to true. A transition without a condition is considered to evaluate to true (to model the 'otherwise' branch). See the condition element |
| common node elements |
|
|
See common node elements |
Table 13.13.
| Name |
Type |
Multiplicity |
Description |
| type |
attribute |
required |
the event type that is expressed relative to the element on which the event is placed |
| {action|script|create-timer|cancel-timer} |
element |
[0..*] |
the list of actions that should be executed on this event |
Table 13.14.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
optional |
the name of the transition. Note that each transition leaving a node *must* have a distinct name. |
| to |
attribute |
required |
the hierarchical name of the destination node. For more information about hierarchical names, see Section 7.5.3, “Hierarchical names” |
| {action|script|create-timer|cancel-timer} |
element |
[0..*] |
the actions to be executed upon taking this transition. Note that the actions of a transition do not need to be put in an event (because there is only one) |
| exception-handler |
element |
[0..*] |
a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process node. |
Table 13.15.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
optional |
the name of the action. When actions are given names, they can be looked up from the process definition. This can be useful for runtime actions and declaring actions only once. |
| class |
attibute |
either this or ref-name |
the fully qualified class name of the class that implements the org.jbpm.graph.def.ActionHandler interface. |
| ref-name |
attibute |
either this or class |
the name of the referenced action. The content of this action is not processed further if a referenced action is specified. |
| accept-propagated-events |
attribute |
optional |
{yes|no|true|false}. Default is yes|true. If set to false, the action will only be executed on events that were fired on this action's element. for more information, see Section 7.4.4, “Event propagation” |
| config-type |
attribute |
optional |
{field|bean|constructor|configuration-property}. Specifies how the action-object should be constructed and how the content of this element should be used as configuration information for that action-object. |
| |
{content} |
optional |
the content of the action can be used as configuration information for your custom action implementations. This allows the creation of reusable delegation classes. For more about delegation configuration, see Section 13.2.3, “Configuration of delegations”. |
Table 13.16.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
optional |
the name of the script-action. When actions are given names, they can be looked up from the process definition. This can be useful for runtime actions and declaring actions only once. |
| accept-propagated-events |
attribute |
optional [0..*] |
{yes|no|true|false}. Default is yes|true. If set to false, the action will only be executed on events that were fired on this action's element. for more information, see Section 7.4.4, “Event propagation” |
| expression |
element |
[0..1] |
the beanshell script. If you don't specify variable elements, you can write the expression as the content of the script element (omitting the expression element tag). |
| variable |
element |
[0..*] |
in variable for the script. If no in variables are specified, all the variables of the current token will be loaded into the script evaluation. Use the in variables if you want to limit the number of variables loaded into the script evaluation. |
Table 13.17.
| Name |
Type |
Multiplicity |
Description |
| |
{content} |
|
a bean shell script. |
Table 13.18.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
required |
the process variable name |
| access |
attribute |
optional |
default is read,write. it is a comma separated list of access specifiers. the only access specifiers used so far are |
| mapped-name |
attribute |
optional |
this defaults to the variable name. it specifies a name to which the variable name is mapped. the meaning of the mapped-name is dependent on the context in which this element is used. for a script, this will be the script-variable-name. for a task controller, this will be the label of the task form parameter and for a process-state, this will be the variable name used in the sub-process. |
Table 13.19.
| Name |
Type |
Multiplicity |
Description |
| class |
attibute |
either this or ref-name |
the fully qualified class name of the class that implements the org.jbpm.graph.node.DecisionHandler interface. |
| config-type |
attribute |
optional |
{field|bean|constructor|configuration-property}. Specifies how the action-object should be constructed and how the content of this element should be used as configuration information for that action-object. |
| |
{content} |
optional |
the content of the handler can be used as configuration information for your custom handler implementations. This allows the creation of reusable delegation classes. For more about delegation configuration, see Section 13.2.3, “Configuration of delegations”. |
Table 13.20.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
optional |
the name of the timer. If no name is specified, the name of the enclosing node is taken. Note that every timer should have a unique name. |
| duedate |
attribute |
required |
the duration (optionally expressed in business hours) that specifies the the time period between the creation of the timer and the execution of the timer. See Section 11.1, “Duration” for the syntax. |
| repeat |
attribute |
optional |
{duration | 'yes' | 'true'}after a timer has been executed on the duedate, 'repeat' optionally specifies duration between repeating timer executions until the node is left. If yes of true is specified, the same duration as for the due date is taken for the repeat. See Section 11.1, “Duration” for the syntax. |
| transition |
attribute |
optional |
a transition-name to be taken when the timer executes, after firing the the timer event and executing the action (if any). |
| cancel-event |
attribute |
optional |
this attribute is only to be used in timers of tasks. it specifies the event on which the timer should be cancelled. by default, this is the task-end event, but it can be set to e.g. task-assign or task-start. The cancel-event types can be combined by specifying them in a comma separated list in the attribute. |
Table 13.21.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
optional |
the name of the timer. The name can be used for cancelling the timer with a cancel-timer action. |
| duedate |
attribute |
required |
the duration (optionally expressed in business hours) that specifies the the time period between the creation of the timer and the execution of the timer. See Section 11.1, “Duration” for the syntax. |
| repeat |
attribute |
optional |
{duration | 'yes' | 'true'}after a timer has been executed on the duedate, 'repeat' optionally specifies duration between repeating timer executions until the node is left. If yes of true is specified, the same duration as for the due date is taken for the repeat. See Section 11.1, “Duration” for the syntax. |
| transition |
attribute |
optional |
a transition-name to be taken when the timer executes, after firing the the timer event and executing the action (if any). |
Table 13.22.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
optional |
the name of the timer to be cancelled. |
Table 13.23.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
optional |
the name of the task. Named tasks can be referenced and looked up via the TaskMgmtDefinition |
| blocking |
attribute |
optional |
{yes|no|true|false}, default is false. If blocking is set to true, the node cannot be left when the task is not finished. If set to false (default) a signal on the token is allowed to continue execution and leave the node. The default is set to false, because blocking is normally forced by the user interface. |
| duedate |
attribute |
optional |
is a duration expressed in absolute or business hours as explained in Chapter 11, Business calendar |
| swimlane |
attribute |
optional |
reference to a swimlane. If a swimlane is specified on a task, the assignment is ignored. |
| priority |
attribute |
optional |
one of {highest, high, normal, low, lowest}. alternatively, any integer number can be specified for the priority. FYI: (highest=1, lowest=5) |
| assignment |
element |
optional |
describes a delegation that will assign the task to an actor when the task is created. |
| event |
element |
[0..*] |
supported event types: {task-create|task-start|task-assign|task-end}. Especially for the task-assign we have added a non-persisted property 绨蚧虺iousActorId to the TaskInstance |
| exception-handler |
element |
[0..*] |
a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process node. |
| timer |
element |
[0..*] |
specifies a timer that monitors the duration of an execution in this task. special for task timers, the cancel-event can be specified. by default the cancel-event is task-end, but it can be customized to e.g. task-assign or task-start. |
| controller |
element |
[0..1] |
specifies how the process variables are transformed into task form parameters. the task form paramaters are used by the user interface to render a task form to the user. |
Table 13.24.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
required |
the name of the swimlane. Swimlanes can be referenced and looked up via the TaskMgmtDefinition |
| assignment |
element |
[1..1] |
specifies a the assignment of this swimlane. the assignment will be performed when the first task instance is created in this swimlane. |
Table 13.25.
| Name |
Type |
Multiplicity |
Description |
| class |
attribute |
required |
the fully qualified classname of an implementation of org.jbpm.taskmgmt.def.AssignmentHandler |
| config-type |
attribute |
optional |
{field|bean|constructor|configuration-property}. Specifies how the assignment-handler-object should be constructed and how the content of this element should be used as configuration information for that assignment-handler-object. |
| |
{content} |
optional |
the content of the assignment-element can be used as configuration information for your AssignmentHandler implementations. This allows the creation of reusable delegation classes. for more about delegation configuration, see Section 13.2.3, “Configuration of delegations”. |
Table 13.26.
| Name |
Type |
Multiplicity |
Description |
| class |
attribute |
optional |
the fully qualified classname of an implementation of org.jbpm.taskmgmt.def.TaskControllerHandler |
| config-type |
attribute |
optional |
{field|bean|constructor|configuration-property}. Specifies how the assignment-handler-object should be constructed and how the content of this element should be used as configuration information for that assignment-handler-object. |
| |
{content} |
|
either the content of the controller is the configuration of the specified task controller handler (if the class attribute is specified. if no task controller handler is specified, the content must be a list of variable elements. |
| variable |
element |
[0..*] |
in case no task controller handler is specified by the class attribute, the content of the controller element must be a list of variables. |
Table 13.27.
| Name |
Type |
Multiplicity |
Description |
| name |
attribute |
required |
the name of the sub process. To know how you can test subprocesses, see Section 15.3, “Testing sub processes” |
| version |
attribute |
optional |
the version of the sub process. If no version is specified, the latest version of the given process will be taken. |
Table 13.28.
| Name |
Type |
Multiplicity |
Description |
| |
{content} |
required |
条件元素内容是beanshell表达式,评估结果为boolean.一个决策接受第一个转换 (as ordered in the processdefinition.xml) 来确定那一个表达式分解为 true. |
13.3.29. exception-handler
Table 13.29.
| Name |
Type |
Multiplicity |
Description |
| exception-class |
attribute |
optional |
指明处理Java扔出的处理异常匹配的handler全称的类名.如果没有指明它处理所有异常 exceptions (java.lang.Throwable). |
| action |
element |
[1..*] |
动作清单用来当异常被这个异常handler处理的时候. |
|
