Red Hat Training

A Red Hat training course is available for JBoss Enterprise SOA Platform

Chapter 14. jBPM Process Definition Language

The jBPM Process Definition Language (jPDL) is the notation to define business processes recognized by the jBPM framework and expressed as an XML schema. Process definitions often require support files in addition to the jPDL document. All these files are packaged into a process archive for deployment.

14.1.  Process Archive

The process archive is just a ZIP archive with a specific content layout. The central file in the process archive is called processdefinition.xml This file defines the business process in the jPDL notation and provides information about automated actions and human tasks. The process archive also contains other files related to the process, such as action handler classes and user interface task forms.

14.1.1.  Deploying a Process Archive

You can deploy a process archive in any of these ways:
  • via the Process Designer Tool
  • with an ant task
  • programatically
To deploy a process archive with the Process Designer Tool, right-click on the process archive folder and select the Deploy process archive option.
The jBPM application server integration modules include the gpd-deployer web application, which has a servlet to upload process archives, called GPD Deployer Servlet. This servlet is capable of receiving process archives and deploying them to the configured database.
To deploy a process archive with an ant task, define and call the task as follows. 
<target name="deploy-process">
  <taskdef name="deployproc" classname="org.jbpm.ant.DeployProcessTask">
    <classpath location="jbpm-jpdl.jar" />
  </taskdef> 
  <deployproc process="build/myprocess.par" />
</target>
To deploy more process archives at once, use nested fileset elements. Here are the DeployProcessTask attributes.

Table 14.1. DeployProcessTask Attributes

Attribute Description Required?
process
Path to process archive.
Yes, unless a nested resource collection element is used.
jbpmcfg
jBPM configuration resource to load during deployment.
No; defaults to jbpm.cfg.xml
failonerror
If false, log a warning message, but do not stop the build, when the process definition fails to deploy.
No; defaults to true
To deploy process archives programmatically, use one of the parseXXX methods of the org.jbpm.graph.def.ProcessDefinition class.

14.1.2.  Process Versioning

Process instances always execute on the same process definition as that in which they were started. However, the jBPM allows multiple process definitions of the same name to co-exist in the database. 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 definitions.
If the process includes references to Java classes, these can be made available to the jBPM runtime environment in one of two ways:
  • by making sure these classes are visible to the jBPM class-loader.
    To do so, put the delegation classes in a .jar file "next to" jbpm-jpdl.jar so that all of the process definitions will see that 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), the jBPM will also version these classes inside the process definition.

    Note

    Learn more about process classloading by reading Section 14.2, “Delegation”
When a process archive is deployed, a process definition is created in the jBPM database. Version process definitions on the basis of their names. When a named process archive is deployed, the deployer assigns it a version number. It does so by searching for the highest number assigned to a process definition of the same name and then adds one to that value. (Unnamed process definitions will always be versioned as -1.)

14.1.3.  Changing Deployed Process Definitions

Warning

Changing process definitions after they are deployed is not a recommended practice. It is better to migrate process instances to a new version of the process definition.
Consider these factors before undertaking this process:
  • There is no restriction on updating a process definition loaded through the org.jbpm.db.GraphSession methods loadProcessDefinition, findProcessDefinition or reached through association traversal. Nonetheless, it is very easy to mess up the process with a few calls such as setStartState(null)!
  • Because processs definitions are not supposed to change, the shipped Hibernate configuration specifies the nonstrict-read-write caching strategy for definition classes and collections. This strategy can make uncommitted updates visible to other transactions.

14.1.4.  Migrating Process Instances

An alternative approach to changing a process definition is to migrate each process instance to a new version. Please consider that migration is not trivial due to the long-lived nature of business processes.

Note

This is an experimental feature.
There is a clear distinction between definition data, execution data and logging data. Because of this distinction, a new version of the process has to be deployed first, and then process instances are migrated to the new version. Migration involves a translation if tokens or task instances point to nodes or task definitions that have been removed in the target process definition. Be aware that logging data ends up spread over two process definitions. This can present challenges when developing tools and making statistics calculations.
To migrate a process instance to a new version, execute the ChangeProcessInstanceVersionCommand as shown below. 
new ChangeProcessInstanceVersionCommand()
  .processName("commute")
  .nodeNameMappingAdd("drive to destination", "ride bike to destination")
  .execute(jbpmContext);

14.2. Delegation

Use the delegation mechanism to include custom code in process executions.

14.2.1.  jBPM Class Loader

The jBPM class loader is the one that loads the jBPM classes. To make classes visible to the jBPM class loader, pack them in a JAR file and co-locate the JAR with jbpm-jpdl.jar. In the case of web applications, place the custom JAR file in WEB-INF/lib alongside jbpm-jpdl.jar.

14.2.2.  Process Class Loader

Delegation classes are loaded through their respective process class loader. The process class loader has the jBPM class loader as its parent. It adds the classes deployed with one particular process definition. To add classes to a process definition, put them in the classes directory of the process archive. Note that this is only useful when you want to version the classes that have been added to the process definition. If versioning is not required, make the classes available to the jBPM class loader instead.
If the resource name does not start with a slash, resources are also loaded from the process archive's classes directory. To load resources that reside outside this directory, start the path with a double forward slash (//). For example, to load data.xml, located in the process archive root, call class.getResource("//data.xml").

14.2.3.  Configuring Delegations

Delegation classes contain user code that is called from within a process execution, the most common example being an action. In the case of action, an implementation of the ActionHandler interface can be called on an event in the process. Delegations are specified in the processdefinition.xml file. You can supply any of these three pieces of data when specifying a delegation:
  1. the class name (required): this is the delegation class' fully-qualified name.
  2. configuration type (optional): this specifies the way in which to instantiate and configure the delegation object. By default, the constructor is used and the configuration information is ignored.
  3. configuration (optional): this is the configuration of the delegation object, which must be in the format required by the configuration type.
Here are descriptions of every type of configuration:

14.2.3.1.  config-type field

This is the default configuration type. The config-type field first instantiates an object of the delegation class and then set values in those object fields specified in the configuration. The configuration is stored in an XML file. In this file, the element names have to correspond to the class' field names. The element's content text is put in the corresponding field. If both necessary and possible to do, the element's content text is converted to the field type.
These are the supported type conversions:
  • string is trimmed but not converted.
  • primitive types such as int, long, float, double, ...
  • the basic wrapper classes for the primitive types.
  • lists, sets and collections. In these cases, each element of the xml-content is considered an element of the collection and is parsed recursively, applying the conversions. If the element types differ from java.lang.String indicate this by specifying a type attribute with the fully-qualified type name. For example, this code injects an ArrayList of strings into numbers field: 
    <numbers>
  <element>one</element>
  <element>two</element>
  <element>three</element>
</numbers>
    You can convert the text in the elements to any object that has a string constructor. To use a type other than a string, specify the element-type in the field (numbers in this case).
    Here is 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>
  • In this case, each of the field elements is expected to have one key and one value sub-element. Parse both of these by using the conversion rules recursively. As with collections, it will be assumed that a conversion to java.lang.String is intended if you do not specify a type attribute.
  • org.dom4j.Element
  • for any other type, the string constructor is used.
Look at this 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 for that class: 
...
<action class="org.test.MyAction">
  <city>Atlanta</city>
  <rounds>5</rounds>
</action>
...

14.2.3.2.  config-type bean

This is the same as the config-type field but, in that case, the properties are configured via "setter" methods. Here they are set directly on the fields. The same conversions are applied.

14.2.3.3.  config-type constructor

This method takes the complete contents of the delegation XML element and passes them as text to the delegation class constructor.

14.2.3.4.  config-type configuration-property

If you use the default constructor, this method will take the complete contents of the delegation XML element and pass it as text in the void configure(String); method.

14.3.  Expressions

There is limited support for a JSP/JSF EL-like expression language. In actions, assignments and decision conditions, you can write this kind of expression: expression="#{myVar.handler[assignments].assign}"

Note

To learn about this expression language, study this tutorial: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSPIntro7.html.
The jPDL and JSF expression languages are similar. jPDL EL is based on JSF EL but, in contrast to the latter, it employs #{...} notation and includes support for method-binding.
Depending on the context, the process and task instance variables can be used as starting variables, as can the 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 powerful when used in a JBoss SEAM environment (http://www.jboss.com/products/seam). Because of the integration between the JBPM and SEAM, every backed bean, Enterprise Java Bean and so forth becomes accessible from within the process definition.

14.4.  jPDL XML Schema

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

14.4.1.  Validation

When parsing a jPDL XML document, jBPM will validate it against the schema when these two conditions are met:
  1. The schema is referenced in the XML document: 
    <process-definition xmlns="urn:jbpm.org:jpdl-3.2">
  ...
</process-definition>
  2. The Xerces parser is on the class-path.

Note

Find the jPDL schema at ${jbpm.home}/src/java.jbpm/org/jbpm/jpdl/xml/jpdl-3.2.xsd or at http://jbpm.org/jpdl-3.2.xsd.

14.4.2.  process-definition

Table 14.2. Process Definition Schema

Name Type Multiplicity Description
name attribute optional This is the name of the process
swimlane element [0..*] These are the swim-lanes used in the process. The swim-lanes represent process roles and are used for task assignments.
start-state element [0..1] This is the process' start state. 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..*] These are the process definition's nodes. Note that a process without nodes is valid, but cannot be executed.
event element [0..*] These serve as a container for actions
{action|script|create-timer|cancel-timer} element [0..*] These are globally-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..*] These are globally-defined tasks that can be used in e.g. actions.
exception-handler element [0..*] This is a list of those exception handlers that applies to all errors thrown by delegation classes in this process definition.

14.4.3. node

Table 14.3. Node Schema

Name Type Multiplicity Description
{action|script|create-timer|cancel-timer} element 1 This is a custom action that represents the behaviour for this node
common node elements Section 14.4.4, “common node elements”

14.4.4. common node elements

Table 14.4. Common Node Schema

Name Type Multiplicity Description
name attribute required This is 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 Chapter 10, Asynchronous Continuations
transition element [0..*] These are 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 specified is called the default transition. The default transition is taken when the node is left without specifying a transition.
event element [0..*] There are two supported event types: {node-enter|node-leave}
exception-handler element [0..*] This is a list of exception handlers that applies to every bug thrown by a delegation class from within this process node.
timer element [0..*] This specifies a timer that monitors the duration of an execution in this node.

14.4.5. start-state

Table 14.5. Start State Schema

Name Type Multiplicity Description
name attribute optional This is the name of the node
task element [0..1] This is the task used to start a new instance for this process or to capture the process initiator. See Section 8.7, “ Swimlane in Start Task ”
event element [0..*] This is the supported event type: {node-leave}
transition element [0..*] These are the leaving transitions. Each transition leaving a node must have a distinct name.
exception-handler element [0..*] This is a list of exception handlers that applies to every bug thrown by a delegation class from within this process node.

14.4.6. end-state

Table 14.6. End State Schema

Name Type Multiplicity Description
name attribute required This is the name of the end-state
end-complete-process attribute optional If the end-complete-process is set to false, only the token concluding this end-state is finished. If this token was the last child to end, the parent token is ended recursively. Set this property to true, to ensure that the full process instance is ended.
event element [0..*] The supported event type is {node-enter}
exception-handler element [0..*] This is a list of exception handlers that applies to every bug thrown by a delegation class from within this process node.

14.4.7. state

Table 14.7. State Schema

Name Type Multiplicity Description
common node elements See Section 14.4.4, “common node elements”

14.4.8. task-node

Table 14.8. Task Node Schema

Name Type Multiplicity Description
signal attribute optional This can be {unsynchronized|never|first|first-wait|last|last-wait}, the default being last. It specifies the way in which task completion affects process execution continuation.
create-tasks attribute optional This can be {yes|no|true|false}, with the default being true. Set it to false when a run-time 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 This can be {yes|no|true|false}, with the default being false. If remove-tasks is set to true on node-leave, every open task is ended.
task element [0..*] These are the tasks that are created when execution arrives in this task node.
common node elements See Section 14.4.4, “common node elements”

14.4.9. process-state

Table 14.9. Process State Schema

Name Type Multiplicity Description
sub-process element 1 This is the sub-process that is associated with this node.
variable element [0..*] This specifies how data should be copied from the super-process to the sub-process at the commencement, and from the sub-process to the super-process upon completion of the sub-process.
common node elements See Section 14.4.4, “common node elements”

14.4.10. super-state

Table 14.10. Super State Schema

Name Type Multiplicity Description
{end-state|state|node|task-node|process-state|super-state|fork|join|decision} element [0..*] These are the super-state's nodes. Super-states can be nested.
common node elements See Section 14.4.4, “common node elements”

14.4.11. fork

Table 14.11. Fork Schema

Name Type Multiplicity Description
common node elements See Section 14.4.4, “common node elements”

14.4.12. join

Table 14.12. Join Schema

Name Type Multiplicity Description
common node elements See Section 14.4.4, “common node elements”

14.4.13. decision

Table 14.13. Decision Schema

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
Every transition may have a guard condition. The decision node examines the leaving transitions having a condition, and selects the first transition whose condition is true.
In case no condition is met, the default transition is taken. The default transition is the first unconditional transition if there is one, or else the first conditional transition. Transitions are considered in document order.
If only conditional ("guarded") transitions are available, and none of the conditions on the transitions evaluate to true, an exception will be thrown.
common node elements See Section 14.4.4, “common node elements”

14.4.14. event

Table 14.14. Event Schema

Name Type Multiplicity Description
type attribute required This is the event type that is expressed relative to the element on which the event is placed
{action|script|create-timer|cancel-timer} element [0..*] This is the list of actions that should be executed on this event

14.4.15. transition

Table 14.15. Transition Schema

Name Type Multiplicity Description
name attribute optional This is the name of the transition. Note that each transition leaving a node *must* have a distinct name.
to attribute required This is the destination node's hierarchical name. For more information about hierarchical names, see Section 6.6.3, “ Hierarchical Names ”
condition attribute or element text optional This is a guard condition expression. Use these condition attributes (or child elements) in decision nodes, or to calculate the available transitions on a token at run-time. Conditions are only allowed on transitions leaving decision nodes.
{action|script|create-timer|cancel-timer} element [0..*] These are the actions that will execute when this transition occurs. Note that a transition's actions do not need to be put in an event (because there is only one).
exception-handler element [0..*] This is a list of exception handlers that applies to every bug thrown by a delegation class from within this process node.

14.4.16. action

Table 14.16. Action Schema

Name Type Multiplicity Description
name attribute optional This is 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 This is the fully-qualified class name of the class that implements the org.jbpm.graph.def.ActionHandler interface.
ref-name attibute either this or class This is the name of the referenced action. The content of this action is not processed further if a referenced action is specified.
expression attribute either this, a class or a ref-name This is a jPDL expression that resolves to a method. See also Section 14.3, “ Expressions ”
accept-propagated-events attribute optional The options are {yes|no|true|false}. The 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, read Section 6.5.3, “ Passing On Events ”
config-type attribute optional The options are {field|bean|constructor|configuration-property}. This 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 attribute {true|false} 'async="true" is only supported in action when it is triggered in an event. The default value 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 asynchronously in a separate transaction.
{content} optional The action's content can be used as the configuration information for custom action implementations. This allows to create reusable delegation classes.

14.4.17. script

Table 14.17. Script Schema

Name Type Multiplicity Description
name attribute optional This is 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 6.5.3, “ Passing On Events ”
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.

14.4.18. expression

Table 14.18. Expression Schema

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

14.4.19. variable

Table 14.19. Variable Schema

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. "required" is only relevant when you are submitting a task variable to a process variable.
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. For a process-state, this will be the variable name used in the sub-process.

14.4.20. handler

Table 14.20. Handler Schema

Name Type Multiplicity Description
expression attribute 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 14.3, “ Expressions ”.
class attribute 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.

14.4.21. timer

Table 14.21. Timer Schema

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

14.4.22. create-timer

Table 14.22. Create Timer Schema

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

14.4.23. cancel-timer

Table 14.23. Cancel Timer Schema

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

14.4.24. task

Table 14.24. Task Schema

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

14.4.25. Swimlane

Table 14.25. Swimlane Schema

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.

14.4.26. Assignment

Table 14.26. Assignment Schema

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

14.4.27. Controller

Table 14.27. Controller Schema

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}. This 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} This is 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..*] When no task controller handler is specified by the class attribute, the content of the controller element must be a list of variables.

14.4.28. sub-process

Table 14.28. Sub Process Schema

Name Type Multiplicity Description
name attribute required Name of the sub-process to call. Can be an EL expression which must evaluate to String.
version attribute optional Version of the sub-process to call. If version is not specified, the process-state takes the latest version of the given process.
binding attribute optional Defines the moment when the sub-process is resolved. The options are: {early|late}. The default is to resolve early, that is, at deployment time. If binding is defined as late, the process-state resolves the latest version of the given process at each execution. Late binding is senseless in combination with a fixed version; therefore, the version attribute is ignored if binding="late".

14.4.29. condition

Table 14.29. Condition Schema

Name Type Multiplicity Description
The option is {content}. For backwards compatibility, the condition can also be entered with the expression attribute, but that attribute has been deprecated since Version 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 file) 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. Conditions are only allowed on transitions leaving decision nodes.

14.4.30. exception-handler

Table 14.30. Exception Handler Schema

Name Type Multiplicity Description
exception-class attribute optional This specifies the Java "throwable" class' fully-qualified name which should match this exception handler. If this attribute is not specified, it matches all exceptions (java.lang.Throwable).
action element [1..*] This is a list of actions to be executed when an error is being handled by this exception handler.