Chapter 6. Process Modeling
6.1. Some Helpful Definitions
entering a node, leaving a node and taking a transition.
6.2. Process Graph
processdefinition.xml. Each node must have a type (examples being state, decision, fork and join.) Each node has a set of leaving transitions. Names can be given to the transitions that leave a node in order to make them distinct from each other. For example, the following diagram shows a process graph for an auction process.

Figure 6.1. The auction process graph
<process-definition>
<start-state>
<transition to="auction" />
</start-state>
<state name="auction">
<transition name="auction ends" to="salefork" />
<transition name="cancel" to="end" />
</state>
<fork name="salefork">
<transition name="shipping" to="send item" />
<transition name="billing" to="receive money" />
</fork>
<state name="send item">
<transition to="receive item" />
</state>
<state name="receive item">
<transition to="salejoin" />
</state>
<state name="receive money">
<transition to="send money" />
</state>
<state name="send money">
<transition to="salejoin" />
</state>
<join name="salejoin">
<transition to="end" />
</join>
<end-state name="end" />
</process-definition>6.3. Nodes
6.3.1. Node Responsibilities
- it can not propagate the execution. (The node behaves as a
wait state.) - it can propagate the execution over one of the node's
leaving transitions. (This means that the token that originally arrived in the node is passed over one of theleaving transitionswith the API callexecutionContext.leaveNode(String).) The node will now act automatically in the sense that it will execute some custom programming logic and then continue the process execution automatically without waiting. - a node can "decide" to create new tokens, each of which will represent a new path of execution. Each of these new tokens can be launched over the node's
leaving transitions. A good example of this kind of behavior is thefork node. - it can end the path of execution. This means that the token has concluded.
- it can modify the whole run-time structure of the process instance. The run-time structure is a process instance that contains a tree of tokens, each of which represents a path of execution. A node can create and end tokens, put each token in a node of the graph and launch tokens over transitions.
6.3.2. Node Type: Task Node
wait state. When the users complete their tasks, the execution will be triggered, making it resume.
6.3.3. Node Type: State
wait state. It differs from a task node in that no task instances will be created for any task list. This can be useful if the process is waiting for an external system. After that, the process will go into a wait state. When the external system send a response message, a token.signal() is normally invoked, triggering the resumption of the process execution.
6.3.4. Node Type: Decision
- the decision is made by the process, and is therefore specified in the process definition,
- an external entity decides.
decision node. Specify the decision criteria in one of two ways, the simplest being to add condition elements to the transitions. (Conditions are EL expressions or beanshell scripts that return a Boolean value.)
leaving transitions which have conditions have been specified. It will evaluate those transitions first in the order specified in the XML. The first transition for which the condition resolves to true will be taken. If the conditions for all transitions resolve to false, the default transition, (the first in the XML), will taken instead. If no default transition is found, a JbpmException is thrown.
leaving transitions.
DecisionHandler interface that can be specified on the decision node. In this scenario, the decision is calculated by a Java class and the selected leaving transition is returned by the decide method, which belongs to the DecisionHandler implementation.
state or wait state node. The leaving transition can then be provided in the external trigger that resumes execution after the wait state is finished (these might, for example, be Token.signal(String transitionName) or TaskInstance.end(String transitionName).)
6.3.5. Node Type: Fork
6.3.6. Node Type: Join
leaving transition. When there are still sibling tokens active, the join will behave as a wait state.
6.3.7. Node Type: Node
actionhandler can do anything but be aware that it is also responsible for passing on the execution. (See Section 6.3.1, “ Node Responsibilities ” for more information.)
6.4. Transitions
Map getLeavingTransitionsMap() method will return less elements than List getLeavingTransitions().)
6.5. Actions
Important

Figure 6.2. A database update action
public class RemoveEmployeeUpdate implements ActionHandler {
public void execute(ExecutionContext ctx) throws Exception {
// get the fired employee from the process variables.
String firedEmployee =
(String) ctx.getContextInstance().getVariable("fired employee");
// by taking the same database connection as used for the jbpm
// updates, we reuse the jbpm transaction for our database update.
Connection connection =
ctx.getProcessInstance().getJbpmSession().getSession().getConnection();
Statement statement = connection.createStatement();
statement.execute("DELETE FROM EMPLOYEE WHERE ...");
statement.execute();
statement.close();
}
}<process-definition name="yearly evaluation">
<state name="fire employee">
<transition to="collect badge">
<action class="com.nomercy.hr.RemoveEmployeeUpdate" />
</transition>
</state>
<state name="collect badge">
</process-definition>6.5.1. Action References
6.5.2. Events
node-enter and node-leave events. (Events are the "hooks" for actions. Each event has a list of actions. When the jBPM engine fires an event, the list of actions is executed.)
6.5.3. Passing On Events
6.5.4. Scripts
- executionContext
- token
- node
- task
- taskInstance
<process-definition>
<event type="node-enter">
<script>
System.out.println("this script is entering node "+node);
</script>
</event>
...
</process-definition><process-definition>
<event type="process-end">
<script>
<expression>
a = b + c;
</expression>
<variable name='XXX' access='write' mapped-name='a' />
<variable name='YYY' access='read' mapped-name='b' />
<variable name='ZZZ' access='read' mapped-name='c' />
</script>
</event>
...
</process-definition>YYY and ZZZ will be made available to the script as script-variables b and c respectively. After the script is finished, the value of script-variable a is stored into the process variable XXX.
read, the process variable will be loaded as a script variable before the script is evaluated. If the access attribute contains write, the script variable will be stored as a process variable after evaluation. The mapped-name attribute can make the process variable available under another name in the script. Use this when the process variable names contain spaces or other invalid characters.
6.5.5. Custom Events
GraphElement.fireEvent(String eventType, ExecutionContext executionContext); method. Choose the names of the event types freely.
6.6. Super-States
6.6.1. Super-State Transitions
6.6.2. Super-State Events
superstate-enter and superstate-leave. They will be fired irrespective of which transitions the node has entered or left. As long as a token takes transitions within the super-state, these events will not be fired.
Note
6.6.3. Hierarchical Names
/) separated name. The slash separates the node names. Use .. to refer to an upper level. The next example shows how to refer to a node in a super-state:
<process-definition>
<state name="preparation">
<transition to="phase one/invite murphy"/>
</state>
<super-state name="phase one">
<state name="invite murphy"/>
</super-state>
</process-definition><process-definition>
<super-state name="phase one">
<state name="preparation">
<transition to="../phase two/invite murphy"/>
</state>
</super-state>
<super-state name="phase two">
<state name="invite murphy"/>
</super-state>
</process-definition>6.7. Exception Handling
exception-handlers can be specified on process-definitions, nodes and transitions. Each of these exception handlers has a list of actions. When an exception occurs in a delegation class, the process element's parent hierarchy is searched for an appropriate exception-handler, the actions for which are executed.
Important
token.signal() method. For those exceptions that are caught, the graph execution continues as if nothing had occurred.
Note
Token.setNode(Node node) to put the token in an arbitrary node within the graph of an exception-handling action.
6.8. Process Composition
process-state. This is a state that is associated with another process definition. When graph execution arrives in the process-state, a new instance of the sub-process is created. This sub-process is then associated with the path of execution that arrived in the process state. The super-process' path of execution will wait until the sub-process has ended and then leave the process state and continue graph execution in the super-process.
<process-definition name="hire">
<start-state>
<transition to="initial interview" />
</start-state>
<process-state name="initial interview">
<sub-process name="interview" />
<variable name="a" access="read,write" mapped-name="aa" />
<variable name="b" access="read" mapped-name="bb" />
<transition to="..." />
</process-state>
...
</process-definition>
hire process contains a process-state that spawns an interview process. When execution arrives in the first interview, a new execution (that is, process instance) of the interview process is created. If a version is not explicitly specified, the latest version of the sub-process is used. To make the Business Process Manager instantiate a specific version, specify the optional version attribute. To postpone binding the specified or latest version until the sub-process is actually created, set the optional binding attribute to late.
hire process variable a is copied into interview process variable aa. In the same way, hire variable b is copied into interview variable bb. When the interview process finishes, only variable aa is copied back into the a variable.
6.9. Custom Node Behavior
ActionHandler that can execute any business logic, but also has the responsibility to pass on the graph execution. Here is an example that reads a value from an ERP system, adds an amount (from the process variables) and stores the result back in the ERP system. Based on the size of the amount, use either the small amounts or the large amounts transition to exit.

Figure 6.3. Process Snippet for Updating ERP Example
public class AmountUpdate implements ActionHandler {
public void execute(ExecutionContext ctx) throws Exception {
// business logic
Float erpAmount = ...get amount from erp-system...;
Float processAmount = (Float) ctx.getContextInstance().getVariable("amount");
float result = erpAmount.floatValue() + processAmount.floatValue();
...update erp-system with the result...;
// graph execution propagation
if (result > 5000) {
ctx.leaveNode(ctx, "big amounts");
} else {
ctx.leaveNode(ctx, "small amounts");
}
}
}Note
6.10. Graph Execution
Note
wait state.
wait state.
wait state, the tokens can be made to persist in the database.

Figure 6.4. The graph execution-related methods
leaving transition from the token's current node. The first transition is the default. In a signal to a token, it takes its current node and calls the Node.leave(ExecutionContext,Transition) method. (It is best to think of the ExecutionContext as a token because the main object in it is a token.) The Node.leave(ExecutionContext,Transition) method will fire the node-leave event and call the Transition.take(ExecutionContext). That method will then run the transition event and call the Node.enter(ExecutionContext) on the transition's destination node. That method will then fire the node-enter event and call the Node.execute(ExecutionContext).
execute method. Each node is responsible for passing on the graph execution by calling the Node.leave(ExecutionContext,Transition) again. In summary:
Token.signal(Transition)Node.leave(ExecutionContext,Transition)Transition.take(ExecutionContext)Node.enter(ExecutionContext)Node.execute(ExecutionContext)
Note
6.11. Transaction Demarcation
token.signal() or taskInstance.end() will only return when the process has entered a new wait state.
Note
async="true" attribute in every node. Asynchronous nodes will not be executed in the thread of the client. Instead, a message is sent over the asynchronous messaging system and the thread is returned to the client (in other words, token.signal() or taskInstance.end() will be returned.)
org.jbpm.command.ExecuteNodeCommand message will be sent from the asynchronous messaging system to the jBPM Command Executor. This reads the commands from the queue and executes them. In the case of the org.jbpm.command.ExecuteNodeCommand, the process will be continued when the node is executed. (Each command is executed in a separate transaction.)
Important
jBPM Command Executor is running so that asynchronous processes can continue. Do so by configuring the web application's CommandExecutionServlet.
Note
wait state. (Use async="true" to demarcate a transaction in the process.)
<start-state> <transition to="one" /> </start-state> <node async="true" name="one"> <action class="com...MyAutomaticAction" /> <transition to="two" /> </node> <node async="true" name="two"> <action class="com...MyAutomaticAction" /> <transition to="three" /> </node> <node async="true" name="three"> <action class="com...MyAutomaticAction" /> <transition to="end" /> </node> <end-state name="end" /> ...
//start a transaction
JbpmContext jbpmContext = jbpmConfiguration.createContext();
try {
ProcessInstance processInstance =
jbpmContext.newProcessInstance("my async process");
processInstance.signal();
jbpmContext.save(processInstance);
} finally {
jbpmContext.close();
}root token will point to node one and an ExecuteNodeCommand message is sent to the command executor.
node one. The action can decide to pass the execution on or enter a wait state. If it chooses to pass it on, the transaction will be ended when the execution arrives at node two.

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.