org.jbpm.jpdl.xml.jpdl-3.0.xsd Maven / Gradle / Ivy
The newest version!
jBPM Process Definition Language (JPDL) version 3.0
Indicates how to use the metadata within a handler
Expression that indicates when a timer is due to fire
Yes, no, true, false, on, and off
Defines how a variable may be accessed
Defines if and when to repeat a timer
Defines custom behavior
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.
Either a class or ref-name must be specified.
Either a class or ref-name must be specified. The content of this action is not processed if a referenced action is specified.
If set to false, the action will only be executed on events that were fired on this action's element.
Specifies how the action object should be constructed and how the content of this element should be used as configuration information for the action object.
Controls the behavior of assigning a task to an identity.
The content of the assignment element can be used as configuration information for your custom assignment handler implementations. This allows the creation of reusable delegation classes.
The fully qualified class name of an implementation of org.jbpm.taskmgmt.def.AssignmentHandler.
Specifies how the assignment handler object should be constructed and how the content of this element should be used as configuration information for that object.
Cancels a timer previously set with create-timer
The name of the timer to be cancelled.
See documentation for the timer element.
The name of the timer. This name can be used later in a cancel-timer element.
The duration that specifies the time period between the creation of the timer and the execution of the timer. This can be expressed in business hours, minutes, etc. See the documentation for syntax for this attribute.
yes, true, or duration. After a timer has been executed on the duedate, this repeat attribute specifies the duration between repeating timer executions until the node is left. If yes or true are specified then the value of duedate is used.
Defines a decision to be made in the processing path
Either a handler or transitions with conditions should be specified. The decision will look for the first transition for which the condition evaluates to true. A transition without a condition is considered to evaluate to true (to model the 'otherwise' branch. See the condition element.
The content of the handler element can be used as configuration information for your custom decision handler implementations. This allows the creation of reusable delegation classes.
The fully qualified class name of an implementation of org.jbpm.graph.node.DecisionHandler.
Specifies how the decision handler object should be constructed and how the content of this element should be used as configuration information for that object.
A beanshell script that evaluates to true or false.
The name of the transition. Note that each transition leaving a node must have a distinct name.
The hierarchical name of the destination node. See documentation for an description of hierarchical names.
Marks the end of a processing path.
Event types supported: node-enter, before-signal
Supported event types: node-enter, node-leave, before-signal, after-signal.
A list of exception handlers that applies to all exceptions thrown by delegation classes within this node.
Specifies the fully qualified class name of the java throwable class that should match this exception handler. If this attribute is not specified it matches all exceptions derived from java.lang.Throwable.
Defines a point in the processing path where multiple execution paths will run in parallel.
Defines a point in the processing path where multiple execution paths merge into one path.
A generic node allowing custom behavior.
A custom action that represents the behaviour for this node
A node that allows execution of another subordinate process.
The name of the subordinate process definition to be executed within the enclosing process.
The version of the deployed process-definition that is to be executed. If none is specified the latest version of the identified process will be used.
Supported event types: node-enter, node-leave, before-signal, after-signal, subprocess-created, subprocess-end.
A beanshell script to execute. The script can be the content of this tag or you can specify one or more variables and a beanshell script in the expression tag.
The beanshell script.
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.
If set to false the action will only be executed on events that were fired in this action's element.
Represents a wait state in a process.
A custom action that represents the behaviour for this node
Grouping mechanism for a named set of nodes.
The nodes of the process definition. Note that a process without nodes is valid, but cannot be executed.
Supports all event types except the process-start and end events.
Groups tasks assigned to the same resource.
The tasks that should be created when execution arrives in this task node.
Controller supports the inclusion of one or more "variable" tags as children. It also supports custom XML for use with a custom controller class as indicated by config-type.
This section can include "variable" elements to identify input and output variables involved in this task.
Specifies how the assignment handler object should be constructed and how the content of this element should be used as configuration information for that object.
Supports events: task-create, task-assign, task-start, task-end.
Specifies a timer that monitors the duration of an execution in this task.
The name for this timer. Every timer should have a unique name. If a name is not specified then the name of the enclosing node is taken.
The duration that specifies the time period between the creation of the timer and the execution of the timer. This can be expressed in business hours, minutes, etc. See the documentation for syntax for this attribute.
yes, true, or duration. After a timer has been executed on the duedate, this repeat attribute specifies the duration between repeating timer executions until the node is left. If yes or true are specified then the value of duedate is used.
A transition name to be taken after the timer executes, the timer event is fired and execution of any specified actions has completed.
task-assign, task-start, task-end, or any combination of these specified as a comma separated list.
Named tasks can be referenced and looked up via the TaskMgmtDefinition.
The duration that specifies the time period between the creation of the timer and the execution of the timer. This can be expressed in business hours, minutes, etc. See the documentation for syntax for this attribute.
This value can also be any integer where the lower the number the higher the priority.
A node which accepts a list of tasks to be executed.
Signal specifies the effect of task completion on the process execution continuation.
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.
Can be set to true, in which all the tasks that are still open are ended on the node-leave event.
Specifies a timer that monitors the duration of an execution in this node.
The name for this timer. Every timer should have a unique name. If a name is not specified then the name of the enclosing node is taken.
The duration that specifies the time period between the creation of the timer and the execution of the timer. This can be expressed in business hours, minutes, etc. See the documentation for syntax for this attribute.
yes, true, or duration. After a timer has been executed on the duedate, this repeat attribute specifies the duration between repeating timer executions until the node is left. If yes or true are specified then the value of duedate is used.
A transition name to be taken after the timer executes, the timer event is fired and execution of any specified actions has completed.
The leaving transitions. Each transition leaving a node must have a distinct name. At most one transition can have no name. The first transition specified is the default transition: the path taken when the node is left without specifying a transition.
The name of the transition. Note that each transition leaving a node must have a distinct name.
The hierarchical name of the destination node. See documentation for an description of hierarchical names.
Input and Output variables for the node. Input variables are specified by access "read". If you have assigned variables during the script evaluation, the variables with "write" access allows you to store the values in the process instance. It does not matter whether the variables existed prior to this action.
User defined metadata.
Defaults to the process variable name as given by the name attribute.
Version 3.0 of the PDL schema
The start state of the process. Note that a process without a start-state is valid, but cannot be executed.
The nodes of the process definition. Note that a process without nodes is valid, but cannot be executed.
Globally defined actions that can be referenced from events and transitions.
Supports all event types. Uniquely supports process-start and process-end.
the name of the process