JBPM!

Sky-Tiger

Process variables maintain the contextual data of a process execution. In an insurance claim process, the 'claimed
amount', 'approved amount' and 'isPaid' could be good examples of process variables. In many ways, they are similar
to the member fields of a class.
Graph Oriented Programming can be easily extended with support for process variables by associating a set of keyvalue
pairs that are associated with an execution. Concurrent execution paths and process composition will complicate
things a bit. Scoping rules will define the visibility of process variables in case of concurrent paths of execution
or subprocesses.

Sky-Tiger

Multiple concurrent paths of execution are often mixed up with multithreaded programming. Especially in the context
of workflow and BPM, these are quite different. A process specifies a state machine. Consider for a moment a
state machine as being always in a stable state and state transitions are instantanious. Then you can interpret concurrent
paths of execution by looking at the events that cause the state transitions.

Sky-Tiger

The main idea is that the super process has a node in the graph that represents a complete execution of the sub process.
When an execution enters the sub-process-node in the super process, several things are to be considered:
• First of all, a new execution is created for the sub process.
• Optionally some of information stored in the process variables of the super process can be injected from the super
process execution into the sub process execution. The most easy form is that the sub process node is configured
with a set of variables that are just copied from the super process variables to the sub process variables.
• The start-node of the sub process should have only one leaving transition. Process languages that support mul-
tiple leaving transitions must have a mechanism to choose one of those transitions based on the process variables
of the super process.
• The sub process execution is launched by sending an event that corresponds to the default leaving transition of
its start state.
After the sub process entered a wait state, the super process execution will be pointing to the sub-process-node and
the sub process execution will be pointing to some wait state.
When the sub process execution finishes, the super process execution can continue. The following aspects need to
be considered at that time:
• Process variable information may need to be copied back from the sub process execution into the super process
execution.
• The super process execution should continue. Typically, process languages allow only one leaving transition on
a sub process node. In that case the super process execution is propagated over that default single leaving transition.
• In case a sub process node is allowed more than one leaving transition, a mechanism has to be introduced to select
a leaving transition. This selection can be based on either the sub process execution's variables or the end
state of the sub process

Sky-Tiger

A task node represents one or more tasks that are to be performed by humans. So when execution arrives in a task
node, task instances will be created in the task lists of the workflow participants. After that, the node will behave as
a wait state. So when the users perform their task, the task completion will trigger the resuming of the execution. In
other words, that leads to a new signal being called on the token.

Sky-Tiger

A state is a bare-bones wait state. The difference with a task node is that no task instances will be created in any
task list. This can be usefull if the process should wait for an external system. E.g. upon entry of the node (via an
action on the node-enter event), a message could be sent to the external system. After that, the process will go into
a wait state. When the external system send a response message, this can lead to a token.signal(), which triggers resuming
of the process execution.

Sky-Tiger

Actually there are 2 ways to model a decision. The distinction between the two is based on *who* is making the
decision. Should the decision made by the process (read: specified in the process definition). Or should an external
entity provide the result of the decision.
When the decision is to be taken by the process, a decision node should be used. There are basically 2 ways to specify
the decision criteria. Simplest is by adding condition elements on the transitions. Conditions are EL expressions
or beanshell scripts that return a boolean.

Sky-Tiger

A fork splits one path of execution into multiple concurrent paths of execution. The default fork behaviour is to
create a child token for each transition that leaves the fork, creating a parent-child relation between the token that
arrives in the fork.

Sky-Tiger

The default join assumes that all tokens that arrive in the join are children of the same parent. This situation is created
when using the fork as mentioned above and when all tokens created by a fork arrive in the same join. A join
will end every token that enters the join. Then the join will examine the parent-child relation of the token that
enters the join. When all sibling tokens have arrived in the join, the parent token will be propagated over the
(unique!) leaving transition. When there are still sibling tokens active, the join will behave as a wait state.

Sky-Tiger

The type node serves the situation where you want to write your own code in a node. The nodetype node expects
one subelement action. The action is executed when the execution arrives in the node. The code you write in the actionhandler
can do anything you want but it is also responsible for propagating the execution.
This node can be used if you want to use a JavaAPI to implement some functional logic that is important for the
business analyst. By using a node, the node is visible in the graphical representation of the process. For comparison,
actions --covered next-- will allow you to add code that is invisible in the graphical representation of the process,
in case that logic is not important for the business analyst.

Sky-Tiger

Transitions have a source node and a destination node. The source node is represented with the property from and
the destination node is represented by the property to.
A transition can optionally have a name. Note that most of the jBPM features depend on the uniqueness of the
transition name. If more then one transition has the same name, the first transition with the given name is taken. In
case duplicate transition names occur in a node, the method Map getLeavingTransitionsMap() will return less
elements than List getLeavingTransitions().