Chapter 18. jBPM Process Definition Language (JPDL)
Prev |  | Next

## Chapter 18. 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.

## 18.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, ...

### 18.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 supported in the starters-kit. Right click on the process archive folder to find the "Deploy process archive" option. The starters-kit server contains the jBPM webapp, which has a servlet to upload process archives called ProcessUploadServlet. This servlet is capable of uploading process archives and deploying them to the default jBPM instance configured.

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`

### 18.1.2. Process versioning

What happens when we have a process definition deployed, many executions are not yet finished and we have a new version of the process definition that we want to deploy ?

Process instances always execute to the process definition that they are started in. But jBPM allows for multiple process definitions of the same name to coexist in the database. So typically, a process instance is 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.

If the process includes references to 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`. In that case, all the process definitions will see that same class file. 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 version these classes inside the process definition. More information about process classloading can be found in Section 18.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.

### 18.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.9, “Second level cache”

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

### 18.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".

## 18.2. Delegation

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

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

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

### 18.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:

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

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

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

#### 18.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)

## 18.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 ! :-)

## 18.4. jPDL xml schema

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

### 18.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.2">
      ...
    </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.

### 18.4.2. process-definition

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

### 18.4.3. node

Table 18.2.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
{action|script|create-timer|cancel-timer} | element | 1 | a custom action that represents the behaviour for this node
common node elements |  |  | See common node elements

### 18.4.4. common node elements

Table 18.3.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
name | attribute | required | the name of the node
async | attribute | { true | false }, false is the default | If set to true, this node will be executed asynchronously. See also Section 4.3.4, “Asynchronous continuations”
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.

### 18.4.5. start-state

Table 18.4.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
name | attribute | optional | the name of the node
task | element | [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”
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.

### 18.4.6. end-state

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

### 18.4.7. state

Table 18.6.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
common node elements |  |  | See common node elements

### 18.4.8. task-node

Table 18.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`.
end-tasks | attribute | optional | {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.
task | element | [0..*] | the tasks that should be created when execution arrives in this task node.
common node elements |  |  | See common node elements

### 18.4.9. process-state

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

### 18.4.10. super-state

Table 18.9.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
{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

### 18.4.11. fork

Table 18.10.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
common node elements |  |  | See common node elements

### 18.4.12. join

Table 18.11.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
common node elements |  |  | See common node elements

### 18.4.13. decision

Table 18.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 conditions | attribute or element text on the transitions leaving a decision |  | the leaving transitions. Each leaving transitions of a node can have a condition. The decision will use these conditions to look for the first transition for which the condition evaluates to true. The first transition represents the otherwise branch. So first, all transitions with a condition are evaluated. If one of those evaluate to true, that transition is taken. If no transition with a condition resolves to true, the default transition (=the first one) is taken. See the condition element
common node elements |  |  | See common node elements

### 18.4.14. event

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

### 18.4.15. transition

Table 18.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 9.6.3, “Hierarchical names”
condition | attribute or element text | optional | a guard condition expression. These condition attributes (or child elements) can be used in decision nodes, or to calculate the available transitions on a token at runtime.
{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.

### 18.4.16. action

Table 18.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, a ref-name or an expression | 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.
expression | attibute | either this, a class or a ref-name | A jPDL expression that resolves to a method. See also Section 18.3, “Expressions”
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 9.5.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.
async | attibute | {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} | 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 18.2.3, “Configuration of delegations”.

### 18.4.17. script

Table 18.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 9.5.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.

### 18.4.18. expression

Table 18.17.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
| {content} |  | a bean shell script.

### 18.4.19. variable

Table 18.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 `read`, `write` and `required`.
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.

### 18.4.20. handler

Table 18.19.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
expression | attibute | either this or a class | A 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 18.3, “Expressions”.
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 18.2.3, “Configuration of delegations”.

### 18.4.21. timer

Table 18.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 time period between the creation of the timer and the execution of the timer. See Section 15.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` or `true` is specified, the same duration as for the due date is taken for the repeat. See Section 15.1, “Duration” for the syntax.
transition | attribute | optional | a transition-name to be taken when the timer executes, after firing 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.
{action|script|create-timer|cancel-timer} | element | [0..1] | an action that should be executed when this timer fires

### 18.4.22. create-timer

Table 18.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 15.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 15.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).

### 18.4.23. cancel-timer

Table 18.22.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
name | attribute | optional | the name of the timer to be cancelled.

### 18.4.24. task

Table 18.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.
signalling | attribute | optional | {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.
duedate | attribute | optional | is a duration expressed in absolute or business hours as explained in Chapter 15, 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 `previousActorId` 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.

### 18.4.25. swimlane

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

### 18.4.26. assignment

Table 18.25.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
expression | attribute | optional | For 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-id | attribute | optional | An 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-actors | attribute | optional | A 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.
class | attribute | optional | 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 18.2.3, “Configuration of delegations”.

### 18.4.27. controller

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

### 18.4.28. sub-process

Table 18.27.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
name | attribute | required | the name of the sub process. To know how you can test subprocesses, see Section 20.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.

### 18.4.29. condition

Table 18.28.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
| {content} For backwards compatibility, the condition can also be entered with the 'expression' attribute, but that attribute is deprecated since 3.2 | required | The 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.

### 18.4.30. exception-handler

Table 18.29.

Name | Type | Multiplicity | Description
--- | --- | --- | ---
exception-class | attribute | optional | specifies 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`).
action | element | [1..*] | a list of actions to be executed when an exception is being handled by this exception handler.

Prev | Up | Next
Chapter 17. Logging | Home | Chapter 19. Security