站内搜索: 请输入搜索关键词
当前页面: 在线文档首页 > JBoss JBPM 3.1.3 userguide 英文版文档

Chapter 16. jBPM Process Definition Language (JPDL) - JBoss JBPM 3.1.3 userguide 英文版文档

Chapter 16. jBPM Process Definition Language (JPDL)

JPDL specifies an xml schema and the mechanism to package all the process definition related files into a process archive.

16.1. The process archive

A process archive is a zip file. The central file in the process archive is processdefinition.xml. The main information in that file is the process graph. The processdefinition.xml also contains information about actions and tasks. A process archive can also contain other process related files such as classes, ui-forms for tasks, ...

16.1.1. Deploying a process archive

Deploying process archives can be done in 3 ways: with the process designer tool, with an ant task or programatically.

Deploying a process archive with the designer tool is still under construction.

Deploying a process archive with an ant task can be done as follows:

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

To deploy more process archives at once, use the nested fileset elements. The file attribute itself is optional. Other attributes of the ant task are:

  • cfg: cfg is optional, the default value is 'hibernate.cfg.xml'. The hibernate configuration file that contains the jdbc connection properties to the database and the mapping files.
  • properties: properties is optional and overwrites *all* hibernate properties as found in the hibernate.cfg.xml
  • createschema: if set to true, the jbpm database schema is created before the processes get deployed.

Process archives can also be deployed programmatically with the class org.jbpm.jpdl.par.ProcessArchiveDeployer

16.1.2. Process versioning

Process definitions should never change because it is extremely difficult (if not, impossible) to predict all possible side effects of process definition changes.

To get around this problem, jBPM has a sophicticated process versioning mechanism. The versioning mechanism allows multiple process definitions of the same name to coexist in the database. A process instance can be started in the latest version available at that time and it will keep on executing in that same process definition for its complete lifetime. When a newer version is deployed, newly created instances will be started in the newest version, while older process instances keep on executing in the older process defintions.

Process definitions are a combination of a declaratively specified process graph and optionally, a set of related java classes. The java classes can be made available to the jBPM runtime environment in 2 ways : by making sure these classes are visible to the jBPM classloader. This usually means that you can put your delegation classes in a .jar file next to the jbpm-[version].jar. The java classes can also be included in the process archive. When you include your delegation classes in the process archive (and they are not visible to the jbpm classloader), jBPM will also apply versioning on these classes. More information about process classloading can be found in Section 16.2, “Delegation”

When a process archive gets deployed, it creates a process definition in the jBPM database. Process definitions can be versioned on the basis of the process definition name. When a named process archive gets deployed, the deployer will assign a version number. To assign this number, the deployer will look up the highest version number for process definitions with the same name and adds 1. Unnamed process definitions will always have version number -1.

16.1.3. Changing deployed process definitions

Changing process definitions after they are deployed into the jBPM database has many potential pitfalls. Therefor, this is highly discouraged.

Actually, there is a whole variety of possible changes that can be made to a process definition. Some of those process definitions are harmless, but some other changes have implications far beyond the expected and desirable.

So please consider migrating process instances to a new definition over this approach.

In case you would consider it, these are the points to take into consideration:

Use hibernate's update: You can just load a process definition, change it and save it with the hibernate session. The hibernate session can be accessed with the method JbpmContext.getSession().

The second level cache: A process definition would need to be removed from the second level cache after you've updated an existing process definition. See also Section 7.10, “Second level cache”

16.1.4. Migrating process instances

An alternative approach to changing process definitions might be to convert the executions to a new process definition. Please take into account that this is not trivial due to the long-lived nature of business processes. Currently, this is an experimental area so for which there are not yet much out-of-the-box support.

As you know there is a clear distinction between process definition data, process instance data (the runtime data) and the logging data. With this approach, you create a separate new process definition in the jBPM database (by e.g. deploying a new version of the same process). Then the runtime information is converted to the new process definition. This might involve a translation cause tokens in the old process might be pointing to nodes that have been removed in the new version. So only new data is created in the database. But one execution of a process is spread over two process instance objects. This might become a bit tricky for the tools and statistics calculations. When resources permit us, we are going to add support for this in the future. E.g. a pointer could be added from one process instance to it's predecessor.

16.1.5. Process conversion

A conversion class has been made available to assist you with converting your jBPM 2.0 process archives into jBPM 3.0 compatible process archives. Create an output directory to hold the converted process archives. Enter the following command line from the build directory of the jBPM 3.0 distribution:

java -jar converter.jar indirectory outdirectory

Substitute the input directory where your jBPM 2.0 process archives reside for "indirectory". Substitute the output directory for the one you created to hold the newly converted process archives for "outdirectory".

16.2. Delegation

Delegation is the mechanism used to include the users' custom code in the execution of processes.

16.2.1. The jBPM class loader

The jBPM class loader is the class loader that loads the jBPM classes. Meaning, the classloader that has the library jbpm-3.x.jar in its classpath. To make classes visible to the jBPM classloader, put them in a jar file and put the jar file besides the jbpm-3.x.jar. E.g. in the WEB-INF/lib folder in the case of webapplications.

16.2.2. The process class loader

Delegation classes are loaded with the process class loader of their respective process definition. The process class loader is a class loader that has the jBPM classloader as a parent. The process class loader adds all the classes of one particular process definition. You can add classes to a process definition by putting them in the /classes folder in the process archive. Note that this is only useful when you want to version the classes that you add to the process definition. If versioning is not necessary, it is much more efficient to make the classes available to the jBPM class loader.

16.2.3. Configuration of delegations

Delegation classes contain user code that is called from within the execution of a process. The most common example is an action. In the case of action, an implementation of the interface ActionHandler can be called on an event in the process. Delegations are specified in the processdefinition.xml. 3 pieces of data can be supplied when specifying a delegation :

  • 1) the class name (required) : the fully qualified class name of the delegation class.
  • 2) configuration type (optional) : specifies the way to instantiate and configure the delegation object. By default the default constructor is used and the configuration information is ignored.
  • 3) configuration (optional) : the configuration of the delegation object in the format as required by the configuration type.

Next is a description of all the configuration types:

16.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. For example, following snippet will inject an ArrayList of Strings into field 'numbers':
    <numbers>
      <element>one</element>
      <element>two</element>
      <element>three</element>
    </numbers>

    The text in the elements can be converted to any object that has a String constructor. To use another type then String, specify the element-type in the field element ('numbers' in this case).

    Here's another example of a 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. 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>
...

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

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

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

16.3. Expressions

For some of the delegations, there is support for a JSP/JSF EL like expression language. In actions, assignments and decision conditions, you can write an expression like e.g. expression="#{myVar.handler[assignments].assign}"

The basics of this expression language can be found in the J2EE tutorial.

The jPDL expression language is similar to the JSF expression language. Meaning that jPDL EL is based on JSP EL, but it uses #{...} notation and that it includes support for method binding.

Depending on the context, the process variables or task instance variables can be used as starting variables along with the following implicit objects:

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

This feature becomes really powerfull in a JBoss SEAM environment. Because of the integration between jBPM and JBoss SEAM, all of your backed beans, EJB's and other one-kind-of-stuff becomes available right inside of your process definition. Thanks Gavin ! Absolutely awsome ! :-)

16.4. jPDL xml schema

The jPDL schema is the schema used in the file processdefinition.xml in the process archive.

16.4.1. Validation

When parsing a jPDL XML document, jBPM will validate your document against the jPDL schema when two conditions are met: first, the schema has to be referenced in the XML document like this

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

And second, the xerces parser has to be on the classpath.

The jPDL schema can be found in ${jbpm.home}/src/java.jbpm/org/jbpm/jpdl/xml/jpdl-3.1.xsd or at http://jbpm.org/jpdl-3.1.xsd.

16.4.2. process-definition

Table 16.1. 

NameTypeMultiplicityDescription
nameattributeoptionalthe name of the process
swimlaneelement[0..*]the swimlanes used in this process. The swimlanes represent process roles and they are used for task assignments.
start-stateelement[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.
eventelement[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.
taskelement[0..*]global defined tasks that can be used in e.g. actions.
exception-handlerelement[0..*]a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process definition.

16.4.3. node

Table 16.2. 

NameTypeMultiplicityDescription
{action|script|create-timer|cancel-timer}element1a custom action that represents the behaviour for this node
common node elements  See common node elements

16.4.4. common node elements

Table 16.3. 

NameTypeMultiplicityDescription
nameattributerequiredthe name of the node
asyncattribute{ true | false }, false is the defaultIf set to true, this node will be executed asynchronously. See also Chapter 13, Asynchronous continuations
transitionelement[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.
eventelement[0..*]supported event types: {node-enter|node-leave}
exception-handlerelement[0..*]a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process node.
timerelement[0..*]specifies a timer that monitors the duration of an execution in this node.

16.4.5. start-state

Table 16.4. 

NameTypeMultiplicityDescription
nameattributeoptionalthe name of the node
taskelement[0..1]the task to start a new instance for this process or to capture the process initiator. See Section 11.7, “Swimlane in start task”
eventelement[0..*]supported event types: {node-leave}
transitionelement[0..*]the leaving transitions. Each transition leaving a node *must* have a distinct name.
exception-handlerelement[0..*]a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process node.

16.4.6. end-state

Table 16.5. 

NameTypeMultiplicityDescription
nameattributerequiredthe name of the end-state
eventelement[0..*]supported event types: {node-enter}
exception-handlerelement[0..*]a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process node.

16.4.7. state

Table 16.6. 

NameTypeMultiplicityDescription
common node elements  See common node elements

16.4.8. task-node

Table 16.7. 

NameTypeMultiplicityDescription
signalattributeoptional{unsynchronized|never|first|first-wait|last|last-wait}, default is last. signal specifies the effect of task completion on the process execution continuation.
create-tasksattributeoptional{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.
end-tasksattributeoptional{yes|no|true|false}, default is false. In case remove-tasks is set to true, on node-leave, all the tasks that are still open are ended.
taskelement[0..*]the tasks that should be created when execution arrives in this task node.
common node elements  See common node elements

16.4.9. process-state

Table 16.8. 

NameTypeMultiplicityDescription
sub-processelement1the sub process that is associated with this node
variableelement[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

16.4.10. super-state

Table 16.9. 

NameTypeMultiplicityDescription
{end-state|state|node|task-node|process-state|super-state|fork|join|decision}element[0..*]the nodes of the superstate. superstates can be nested.
common node elements  See common node elements

16.4.11. fork

Table 16.10. 

NameTypeMultiplicityDescription
common node elements  See common node elements

16.4.12. join

Table 16.11. 

NameTypeMultiplicityDescription
common node elements  See common node elements

16.4.13. decision

Table 16.12. 

NameTypeMultiplicityDescription
handlerelementeither a 'handler' element or conditions on the transitions should be specifiedthe name of a org.jbpm.jpdl.Def.DecisionHandler implementation
transitionelement[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

16.4.14. event

Table 16.13. 

NameTypeMultiplicityDescription
typeattributerequiredthe 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

16.4.15. transition

Table 16.14. 

NameTypeMultiplicityDescription
nameattributeoptionalthe name of the transition. Note that each transition leaving a node *must* have a distinct name.
toattributerequiredthe hierarchical name of the destination node. For more information about hierarchical names, see Section 9.6.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-handlerelement[0..*]a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process node.

16.4.16. action

Table 16.15. 

NameTypeMultiplicityDescription
nameattributeoptionalthe 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.
classattibuteeither, a ref-name or an expressionthe fully qualified class name of the class that implements the org.jbpm.graph.def.ActionHandler interface.
ref-nameattibuteeither this or classthe name of the referenced action. The content of this action is not processed further if a referenced action is specified.
expressionattibuteeither this, a class or a ref-nameA jPDL expression that resolves to a method. See also Section 16.3, “Expressions”
accept-propagated-eventsattributeoptional{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 9.5.4, “Event propagation”
config-typeattributeoptional{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.
asyncattibute{true|false}Default is false, which means that the action is executed in the thread of the execution. If set to true, a message will be sent to the command executor and that component will execute the action asynchonously in a separate transaction.
 {content}optionalthe 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 16.2.3, “Configuration of delegations”.

16.4.17. script

Table 16.16. 

NameTypeMultiplicityDescription
nameattributeoptionalthe 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-eventsattributeoptional [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 9.5.4, “Event propagation”
expressionelement[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).
variableelement[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.

16.4.18. expression

Table 16.17. 

NameTypeMultiplicityDescription
 {content} a bean shell script.

16.4.19. variable

Table 16.18. 

NameTypeMultiplicityDescription
nameattributerequiredthe process variable name
accessattributeoptionaldefault is read,write. It is a comma separated list of access specifiers. The only access specifiers used so far are read, write and required.
mapped-nameattributeoptionalthis 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.

16.4.20. handler

Table 16.19. 

NameTypeMultiplicityDescription
expressionattibuteeither this or a classA jPDL expression. The returned result is transformed to a string with the toString() method. The resulting string should match one of the leaving transitions. See also Section 16.3, “Expressions”.
classattibuteeither this or ref-namethe fully qualified class name of the class that implements the org.jbpm.graph.node.DecisionHandler interface.
config-typeattributeoptional{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}optionalthe 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 16.2.3, “Configuration of delegations”.

16.4.21. timer

Table 16.20. 

NameTypeMultiplicityDescription
nameattributeoptionalthe 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.
duedateattributerequiredthe duration (optionally expressed in business hours) that specifies the time period between the creation of the timer and the execution of the timer. See Section 14.1, “Duration” for the syntax.
repeatattributeoptional{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 or true is specified, the same duration as for the due date is taken for the repeat. See Section 14.1, “Duration” for the syntax.
transitionattributeoptionala transition-name to be taken when the timer executes, after firing the timer event and executing the action (if any).
cancel-eventattributeoptionalthis 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.
{action|script|create-timer|cancel-timer}element[0..1]an action that should be executed when this timer fires

16.4.22. create-timer

Table 16.21. 

NameTypeMultiplicityDescription
nameattributeoptionalthe name of the timer. The name can be used for cancelling the timer with a cancel-timer action.
duedateattributerequiredthe 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 14.1, “Duration” for the syntax.
repeatattributeoptional{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 14.1, “Duration” for the syntax.
transitionattributeoptionala transition-name to be taken when the timer executes, after firing the the timer event and executing the action (if any).

16.4.23. cancel-timer

Table 16.22. 

NameTypeMultiplicityDescription
nameattributeoptionalthe name of the timer to be cancelled.

16.4.24. task

Table 16.23. 

NameTypeMultiplicityDescription
nameattributeoptionalthe name of the task. Named tasks can be referenced and looked up via the TaskMgmtDefinition
blockingattributeoptional{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.
signallingattributeoptional{yes|no|true|false}, default is true. If signalling is set to false, this task will never have the capability of trigering the continuation of the token.
duedateattributeoptionalis a duration expressed in absolute or business hours as explained in Chapter 14, Business calendar
swimlaneattributeoptionalreference to a swimlane. If a swimlane is specified on a task, the assignment is ignored.
priorityattributeoptionalone of {highest, high, normal, low, lowest}. alternatively, any integer number can be specified for the priority. FYI: (highest=1, lowest=5)
assignmentelementoptionaldescribes a delegation that will assign the task to an actor when the task is created.
eventelement[0..*]supported event types: {task-create|task-start|task-assign|task-end}. Especially for the task-assign we have added a non-persisted property previousActorId to the TaskInstance
exception-handlerelement[0..*]a list of exception handlers that applies to all exceptions thrown by delegation classes thrown in this process node.
timerelement[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.
controllerelement[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.

16.4.25. swimlane

Table 16.24. 

NameTypeMultiplicityDescription
nameattributerequiredthe name of the swimlane. Swimlanes can be referenced and looked up via the TaskMgmtDefinition
assignmentelement[1..1]specifies a the assignment of this swimlane. the assignment will be performed when the first task instance is created in this swimlane.

16.4.26. assignment

Table 16.25. 

NameTypeMultiplicityDescription
expressionattributeoptionalFor historical reasons, this attribute expression does not refer to the jPDL expression, but instead, it is an assignment expression for the jBPM identity component. For more information on how to write jBPM identity component expressions, see Section 11.11.2, “Assignment expressions”. Note that this implementation has a dependency on the jbpm identity component.
actor-idattributeoptionalAn actorId. Can be used in conjunction with pooled-actors. The actor-id is resolved as an expression. So you can refer to a fixed actorId like this actor-id="bobthebuilder". Or you can refer to a property or method that returns a String like this: actor-id="myVar.actorId", which will invoke the getActorId method on the task instance variable "myVar".
pooled-actorsattributeoptionalA comma separated list of actorIds. Can be used in conjunction with actor-id. A fixed set of pooled actors can be specified like this: pooled-actors="chicagobulls, pointersisters". The pooled-actors will be resolved as an expression. So you can also refer to a property or method that has to return, a String[], a Collection or a comma separated list of pooled actors.
classattributeoptionalthe fully qualified classname of an implementation of org.jbpm.taskmgmt.def.AssignmentHandler
config-typeattributeoptional{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}optionalthe 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 16.2.3, “Configuration of delegations”.

16.4.27. controller

Table 16.26. 

NameTypeMultiplicityDescription
classattributeoptionalthe fully qualified classname of an implementation of org.jbpm.taskmgmt.def.TaskControllerHandler
config-typeattributeoptional{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.
variableelement[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.

16.4.28. sub-process

Table 16.27. 

NameTypeMultiplicityDescription
nameattributerequiredthe name of the sub process. To know how you can test subprocesses, see Section 18.3, “Testing sub processes”
versionattributeoptionalthe version of the sub process. If no version is specified, the latest version of the given process will be taken.

16.4.29. condition

Table 16.28. 

NameTypeMultiplicityDescription
 {content} or attribute expressionrequiredThe contents of the condition element is a jPDL expression that should evaluate to a boolean. A decision takes the first transition (as ordered in the processdefinition.xml) for which the expression resolves to true. If none of the conditions resolve to true, the default leaving transition (== the first one) will be taken.

16.4.30. exception-handler

Table 16.29. 

NameTypeMultiplicityDescription
exception-classattributeoptionalspecifies the fully qualified name of the java throwable class that should match this exception handler. If this attribute is not specified, it matches all exceptions (java.lang.Throwable).
actionelement[1..*]a list of actions to be executed when an exception is being handled by this exception handler.