JBoss.orgCommunity Documentation
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.
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.
One can deploy a process archive in any of three
different 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 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 17.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 |
| 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.
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.
Learn more about process classloading by reading Section 17.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.)
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.
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.
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);
Use the delegation mechanism to include custom code in process executions.
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, one would place the
custom JAR file in WEB-INF/lib alongside
jbpm-jpdl.jar.
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 one wishes 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").
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. One
can supply any of these three pieces of data when specifying a
delegation:
the class name (required): this is the delegation class' fully-qualified name.
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.
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:
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>
One 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 one
does 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>
...
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.
This method takes the complete contents of the delegation XML element and passes them as text to the delegation class constructor.
There is limited support for a JSP/JSF EL-like expression
language. In actions, assignments and decision conditions, one
can write this kind of expression:
expression="#{myVar.handler[assignments].assign}"
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 one's process definition.
The jPDL schema is the schema used in the process archive's
processdefinition.xml file.
When parsing a jPDL XML document, jBPM will validate it against the schema when these two conditions are met:
The schema is referenced in the XML document:
<process-definition xmlns="urn:jbpm.org:jpdl-3.2">
...
</process-definition>
The Xerces parser is on the class-path.
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.
Table 17.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|mail-node} | 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|mail} | 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. |
Table 17.3. Node Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| {action|script|create-timer|cancel-timer|mail} | element | 1 | This is a custom action that represents the behaviour for this node |
| common node elements | Section 17.4.4, “common node elements” |
Table 17.4. Common Node Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| name | attribute | required | This is the name of the node |
| async | attribute | optional | {true|false}, false is the default. If set to true, this node will be executed asynchronously. See also Chapter 13, Asynchronous Continuations |
| description | element | [0..*] | A description of the node, state or process |
| 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. |
Table 17.5. Start State Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| name | attribute | optional | This is the name of the node |
| description | element | [0..*] | A description of the state |
| 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 11.7, “ Swimlane in Start Task ” for more information. |
| 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. |
Table 17.6. End State Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| name | attribute | required | This is the name of the end-state |
| description | element | [0..*] | A description of the 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. |
Table 17.7. State Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| common node elements | See Section 17.4.4, “common node elements” |
Table 17.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. See Section 17.4.25, “task” |
| common node elements | See Section 17.4.4, “common node elements” |
Table 17.9. Process State Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| sub-process | element | [0..1] | This is the sub-process that is associated with this node. See Section 17.4.30, “sub-process” |
| 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 17.4.4, “common node elements” |
Table 17.10. Super State Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| {end-state|state|node|task-node|process-state|super-state|fork|join|decision|mail-node} | element | [0..*] | These are the super-state's nodes. Super-states can be nested. |
| common node elements | See Section 17.4.4, “common node elements” |
Table 17.11. Fork Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| script | element | [0..1] | See Table 17.18, “Script Schema”.
With a script, the fork evaluates the script to obtain the names of leaving transitions to take. The script must have exactly one variable with 'write' access. The script must then assign a Collection of transition names (Strings) to that variable. |
| common node elements | See Section 17.4.4, “common node elements” |
Table 17.12. Join Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| common node elements | See Section 17.4.4, “common node elements” |
Table 17.13. Decision Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| handler | element | only one of either the 'handler' element or condition(s) on the transition(s) should be specified | the name of a org.jbpm.jpdl.Def.DecisionHandler implementation.
The class and config-type attributes can be used here. See
Section 17.4.17, “action” for a description of those attributes. |
| transition conditions | attribute or element text on the transitions leaving a decision | only one of either the 'handler' element or condition(s) on the transition(s) should be specified | 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. When 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 | All common node elements except for the timer element. See Section 17.4.4, “common node elements” |
Table 17.14. Mail Node Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| common node elements | Section 17.4.4, “common node elements” | ||
| subject | attribute or element text | [0..1] | The subject of the mail. |
| text | attribute or element text | [0..1] | The text (body) of the mail. |
| template | attribute | [0..1] | A text template for the mail. |
| to | attribute | [0..1] | A list of "to" addresses. |
| actors | attribute | [0..1] | A list of actors to which the message should be sent. See Section 15.3.3, “ Address Resolving ” |
| cc | attribute | [0..1] | A list of "cc" addressses. |
| cc-actors | attribute | [0..1] | A list of actors to which the message should be carbon copied. See Section 15.3.3, “ Address Resolving ” |
| bcc | attribute | [0..1] | A list of "bcc" addressses. |
| bcc-actors | attribute | [0..1] | A list of actors to which the message should be blind carbon copied. See Section 15.3.3, “ Address Resolving ” |
Table 17.15. 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|mail} | element | [0..*] | This is the list of actions that should be executed on this event |
Table 17.16. 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. |
| description | element | [0..*] | A description of the transition |
| to | attribute | required | This is the destination node's hierarchical name. For more information about hierarchical names, see Section 9.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|mail} | 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. |
Table 17.17. 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 | attibute | either this, a class or a ref-name | This is a jPDL expression that resolves to a method. See also Section 17.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 9.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 one to create reusable delegation classes. For more about delegation configuration, read Section 17.2.3, “ Configuring Delegations ”. |
Table 17.18. 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 9.5.3, “ Passing On Events ” |
| async | attribute | optional | {true|false}, false is the default. If set to true, this node will be executed asynchronously. See also Chapter 13, Asynchronous Continuations |
| expression | element | [0..1] | the beanshell script. If you don't specify variable elements, you can write the expression as the content of the script element (omitting the expression element tag). |
| variable | element | [0..*] | in variable for the script. If no in variables are specified, all the variables of the current token will be loaded into the script evaluation. Use the in variables if you want to limit the number of variables loaded into the script evaluation. |
Table 17.20. 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 one is a submitting 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 and for a process-state, this will be the variable name used in the sub-process. |
Table 17.21. Handler Schema
| 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 17.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 17.2.3, “ Configuring Delegations ”. |
Table 17.22. 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 14.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 14.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|mail} | element | [0..1] | an action that should be executed when this timer fires |
Table 17.23. 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. |
| action | element | [0..*] | An action to be executed when the timer fires. See Section 17.4.17, “action” |
| script | element | [0..*] | A script to be executed when the timer fires. See Section 17.4.18, “script” |
| 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 14.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 14.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). |
Table 17.24. Cancel Timer Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| name | attribute | required | the name of the timer to be cancelled. |
Table 17.25. 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 |
| description | attribute or element text | optional | A description of the task. |
| 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 14, 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}, with a default of normal.
Alternatively, any integer number can be specified for the priority. For example:
(highest=1, lowest=5) |
| notify | attribute | optional | {yes|no|true|false}, default is false. If notify is set to true,
a mail action will be fired when the task is assigned.
See Section 15.1.3, “
"Task Assigned" Email
” |
| 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.
|
| reminder | element | [0..*] | specifies a reminder, or "notification timer"
that will send a notification e-mail. See Section 15.1.4, “
"Task Reminder" Email
” |
| controller | element | [0..1] | specifies how the process variables are transformed into task form parameters. The task form paramaters are used by the user interface to render a task form to the user. |
Table 17.26. Mail Schema
| Name | Type | Multiplicity | Description |
|---|---|---|---|
| name | attribute | required | This is the name of the mail action |
| async | attribute | optional | {true|false}, false is the default, If set to true, this node will be executed asynchronously. See also Chapter 13, Asynchronous Continuations |
| subject | attribute or element text | [0..1] | The subject of the mail. |
| text | attribute or element text | [0..1] | The text (body) of the mail. |
| template | attribute | [0..1] | A text template for the mail. |
| to | attribute | [0..1] | A list of "to" addresses. |
| actors | attribute | [0..1] | A list of actors to which the message should be sent. See Section 15.3.3, “ Address Resolving ” |
| cc | attribute | [0..1] | A list of "cc" addressses. |
| cc-actors | attribute | [0..1] | A list of actors to which the message should be carbon copied. See Section 15.3.3, “ Address Resolving ” |
| bcc | attribute | [0..1] | A list of "bcc" addressses. |
| bcc-actors | attribute | [0..1] | A list of actors to which the message should be blind carbon copied. See Section 15.3.3, “ Address Resolving ” |
| 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 9.5.3, “
Passing On Events
”
|
Table 17.27. 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. |
Table 17.28. 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 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 17.2.3, “ Configuring Delegations ”. |
Table 17.29. 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. |
Table 17.30. 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".
|
Table 17.31. 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.
|
Table 17.32. 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 | [0..*] At least one action or script must be specified | An action to be executed when an error is being handled by this exception handler. |
| script | element | [0..*] At least one action or script must be specified | A script that will be executed when an error is being handled by this exception handler. See Section 17.4.18, “script” |