SWS FlowConnect support for Control Flow Patterns
About FlowConnect.................................................................................................................................. ii
Modelling Notation Legend.....................................................................................................................iii
Basic control patterns ............................................................................................................................... 1
WCP-1 Sequence ................................................................................................................................. 1
WCP-2 Parallel Split (AND Split) ....................................................................................................... 1
WCP-3 Synchronisation (AND Join)................................................................................................... 2
WCP-4 Exclusive Choice (XOR Split) ................................................................................................ 3
WCP-5 Simple Merge (XOR Join) ...................................................................................................... 4
Advanced Branching ................................................................................................................................ 5
WCP-6 Multi-choice (OR Split) .......................................................................................................... 5
WCP-7 Structured Synchronising Merge ............................................................................................ 6
WCP-8 Multi-Merge ............................................................................................................................ 7
WCP-9 Structured Discriminator ......................................................................................................... 8
Structural .................................................................................................................................................. 9
WCP-10 Arbitrary Cycles (Unstructured loop) ................................................................................... 9
WCP-11 Implicit Termination ........................................................................................................... 10
Multiple Instance .................................................................................................................................... 11
WCP-12 Multiple Instances without Synchronisation ....................................................................... 11
WCP-13 Multiple Instances with a priori Design Knowledge ........................................................... 12
WCP-14 Multiple Instances with a priori Runtime Knowledge ........................................................ 13
WCP-15 Multiple Instances without a priori Runtime Knowledge ................................................... 14
State-Based ............................................................................................................................................. 15
WCP-16 Deferred Choice (Deferred XOR Split) .............................................................................. 15
WCP-17 Interleaved Parallel Routing ............................................................................................... 15
WCP-18 Milestone ............................................................................................................................ 16
Cancellation ............................................................................................................................................ 17
WCP-19 Cancel Activity ................................................................................................................... 17
WCP-20 Cancel Case ........................................................................................................................ 17
i
About FlowConnect
FlowConnect is a state-based workflow engine based on the concept of state machines that executes
process models containing a “network” of states connected by transitions. A FlowConnect process
model is a routing pattern for a business process that defines the states and event actions to perform
transitions between states in a process. The flow of control through a state machine lifecycle is
governed by a client’s business rules that define the process logic, the data accessed in each state and
any event actions that are raised after a state is exited. State machine lifecycles are asynchronous and
they may have points of synchronisation which gives them the ability to block (wait) until other state
machine lifecycles are in a certain state.
In this evaluation of the control flow pattern support for FlowConnect, pattern support is demonstrated
with abstract examples showing possible interactions between state machines in FlowConnect process
models. At a higher level in FlowConnect state machines are identified as business objects. Business
objects are entities in FlowConnect that play a role in a system and will be involved in one or more
business processes. It is important to note that business objects are not IT-related objects; instead they
represent real business functions by grouping related tasks together to maintain the state and order of
business functions. The data aspects of an object are described by its temporal milestones, document
attachments and attributes. The behavioural aspects of an object are described by the state machine
defined within the object. In a certain state, one or more tasks can be offered to multiple resources
however a state machine can only be in a maximum of one state at any point in time.
Further information concerning FlowConnect is available online at http://www.flowconnect.com.au
ii
Modelling Notation Legend
Model Element
Notation
State Machine
StateMachine01
State
State
001
Pre/Post State Gateway
Pre
Transition
Post
E1
Spawn Signal
Sig01
Finish Signal
Sig02
Message Signal
Sig03
Previous/Subsequent State Machine Lifecycle
...
iii
Basic control patterns
WCP-1 Sequence
An activity in a workflow process is enabled after the completion of a preceding activity in the same
process.
The FlowConnect engine proceeds to another state in a state machine when a transition occurs that
connects two states in the same state machine. A transition between two states is made following the
occurrence of an event. The type of event appears as a label in the transition. In the figure, each state
appears with a “pre” and a “post” gateway. These gateways are not used to capture sequences, but will
be used in subsequent patterns.
WCP-2 Parallel Split (AND Split)
A branch diverges into two or more parallel branches which each execute concurrently.
An execution of a state machine, which captures the lifecycle of one business object, can only be in one
state at a time. To capture parallel branching, it is necessary to split the model into several state
machines that will execute concurrently. Specifically, a parallel split is captured by having an instance
of one state machine (the parent), trigger an instance of another state machine (the child). This is
represented by a “spawn signal” as shown in the figure below. Spawn signals may be attached to a pre
or post- gateway of a state. When that state is entered/exited, an instance of the state machine targeted
by the spawn signal is created and this child state machine runs concurrently with its parent.
1
WCP-3 Synchronisation (AND Join)
Two or more branches converge into a single subsequent branch. Control passes to a single subsequent
branch after all input branches have been completed.
The AND-Join is captured by having two different signals sent by two child state machines
(StateMachine02 and StateMachine03 in the figure below), merge into a single gateway in the parent
state machine (see gateway "post” of State 001 in the figure). A condition of type “wait-for-all" should
be attached to this gateway to denote the fact that the parent state machine (StateMachine01) will wait
for an occurrence of each of these signals before continuing its execution.
2
WCP-4 Exclusive Choice (XOR Split)
A branch diverges into two or more branches. The thread of control is passed to precisely one of the
outgoing branches based upon a logical expression associated with the branch.
Evaluation of the exclusive choice happens when exiting a state. This is currently done implicitly in the
state post-gateway. In the post-gateway, conditional statements are captured using an “if-then-else”
construct. Based on the evaluation of conditions, an event of a certain type may be raised which in turn
may cause a transition to another state to be taken. In the same way, based on the evaluation of
conditions, a signal may be sent out that may cause one among several state machines to be spawned.
Thus, this pattern is supported in two different ways: an exclusive choice between states in the same
state machine (by raising one event among several possible events based on conditions) and also across
states in separate state machines (by raising one signal among multiple possible signals based on
conditions).
Exclusive choice in the same state machine
Exclusive choice across separate state machines
3
WCP-5 Simple Merge (XOR Join)
Two or more branches converge into a single branch. Each incoming branch passes a thread of control
to the subsequent branch.
Like WCP-4, the simple merge pattern can be supported in two ways; within the same state machine
and across separate state machines. Within the same state machine, a simple merge is represented by
having a state with multiple incoming transitions. Across different state machines, this is represented
by having multiple signals converge in a single gateway, and attaching a “wait-for-one” condition to
this gateway. As a result, this gateway will only wait for one of its incoming signals to be received.
Simple merge within the same state machine
Simple merge across separate state machines
4
Advanced Branching
WCP-6 Multi-choice (OR Split)
A branch diverges into two or more branches. The thread of control is passed to one or more of the
outgoing branches based upon the result of logical expressions associated with each branch.
In FlowConnect the OR-Split is captured by generating multiple signals based on certain conditions.
This is similar to one of the solutions given for the XOR-split, with the different that the evaluation of
the conditional statements may lead to more than one signal being raised and therefore more than one
child state machine being spawned.
5
WCP-7 Structured Synchronising Merge
Provides a means of synchronising all splits previously made from a multi-choice. Four context
conditions exist. If only one path, alternative branches should converge without synchronisation,
otherwise all active branches from a multi-choice split must synchronise.
In FlowConnect the post-gateway of a state has the option to either “wait-for-one” or “wait-for-all”.
This allows a parent state machine to either wait for either the first signal or all signals sent from its
children state machines. To support this pattern, the post-gateway of a waiting state is set to wait-forall, which means that a state in the parent state machine will wait until all expected signals from its
children have been received before the parent lifecycle can continue. In addition, a parent state machine
can query the number and type of its children that are active and will only wait for children that have an
active lifecycle. This enables the parent to know which branches are expected to complete following an
OR-Split. For example, the parent StateMachine01 will exit from State 004 when all expected finish
signals (Sig03 and Sig04) from its active children have been received. If the child state machine
StateMachine02 was not spawned from State 001 or was cancelled during its lifecycle, StateMachine01
will not expect to receive a finish signal (Sig03) from that child.
6
WCP-8 Multi-Merge
Every active path into the merge triggers the task after the merge. No synchronisation occurs at the
join.
A workaround is required to support a Multi-merge: The common state ‘State 004’ is implemented by
each of the children involved in the merge. When each child state machine enters State 004 the ‘merge’
can then occur by starting a new instance of state machine StateMachine04 after State 004 has
completed. The workaround means that State 004 is completed twice with no synchronisation occurring
between the state machines with respect to states State 004 and State 005 which satisfies the condition
for this pattern that “every active path into the merge triggers the task after the merge”.
FlowConnect implementation of WCP-8 Multi-Merge
7
WCP-9 Structured Discriminator
Two or more branches converge into a single subsequent branch following an earlier divergence in the
process model. The thread of control is passed on from the first active incoming branch. Subsequent
active incoming branches are not passed on. The discriminator resets once all incoming branches have
been enabled.
The structured discriminator is implemented by a waiting state that waits for the merge. Unlike pattern
WCP-3, each child state machine attempts to unlock its parent from a post-gateway. The first child
signal received will do it; the rest will have no effect and if any signals are sent from these children,
they will be ignored. A single token approach is taken – there is no available place for a second token.
If both signals arrive simultaneously (in the same engine cycle) the first evaluated signal unlocks the
wait, the second gets ignored, where the choice of which one arrived first is made nondeterministically.
The construct can reset either after a signal is received from each child (wait-for-one) or after all
signals are received (wait-for-all). The second case satisfies this pattern.
8
Structural
WCP-10 Arbitrary Cycles (Unstructured loop)
The ability to represent cycles in a process model that have more than one entry or exit point.
FlowConnect does not explicitly define the concept of cycle. This can be taken to mean that any
arbitrary sequence of states that are involved in a loop will be executed until the conditions that
initiated the loop change to fit the condition(s) that allow the loop to exit. Exit from the loop is possible
at any time based on data structure values.
Loops are supported from a data-structure point of view. Data structures that can be used to support
arbitrary loops include:



Object data structures - allows for multi valued attributes. On each iteration a new set of
those attributes can be used to store that iteration’s data.
Milestones (i.e. date/time attributes): - on each iteration of a loop a new planned value for a
milestone (deadline) can be set to control the time behaviour of that iteration. For example,
one might change the due date of a document submission.
Processing comments – a tool by which a user can leave a processing comment in a state. If
the case executes a state multiple times the comments are kept separately for each occurrence
of that state.
A loop terminates either by reaching a deadline or when data dependent routing triggers a transition out
of the loop.
9
WCP-11 Implicit Termination
A given process or sub-process should terminate when there are no more remaining work items that can
be done now or at any time in the future.
Implicit termination is detected by FlowConnect in all circumstances when there are no outgoing
transitions from a state in a state machine. This is implemented consistently across all state machines.
Additionally, a cancellation transition exists that explicitly terminates an entire state machine. The state
machine terminates once any of the final states are reached.
Implicit termination after completion of either State 003 or State 004
10
Multiple Instance
WCP-12 Multiple Instances without Synchronisation
Within a given process, multiple instances of an activity can be created. These instances are
independent of each other and run concurrently. There is no need to synchronise them upon
completion.
Multiple instances of a state machine are started and are left to complete without synchronisation. No
restrictions are imposed on the simplicity or complexity of the children state machine lifecycles.
Multiple instances of a state machine can be started from two different levels:


A state machine spawns multiple children state machines that are identical to the parent.
A state machine spawns multiple child state machines with a lifecycle consisting of states
that are different from the parent.
Parent state machine that spawns ‘n’ instances of a child state machine
11
WCP-13 Multiple Instances with a priori Design Knowledge
Within a given process, multiple instances of an activity can be created. The required number of
instances is known at design time. These instances are independent of each other and run concurrently.
It is necessary to synchronise them upon completion before any subsequent tasks can be triggered.
A child object factory is called a predefined (n) number of times. The parent then waits (blocks) for all
children to complete by waiting in a post-gateway for all signals to be received from each of its
children state machines, at which time synchronisation occurs and the parent lifecycle can continue.
See also, WCP-15.
12
WCP-14 Multiple Instances with a priori Runtime Knowledge
Within a given process, multiple instances of an activity can be created. The required number of
instances may depend on a number of runtime factors, including state data, resource availability and
inter-process communications, but is known before the activity instances must be created. Once
initiated, these instances are independent of each other and run concurrently. It is necessary to
synchronise them upon completion before any subsequent tasks can be triggered.
A child object factory that creates new child state machines is called as part of a data entry entered by a
user at runtime (n) from either a state or a loop. Child state machines run independently and
concurrently. The parent waits for all children to complete and synchronises all children upon
completion. See also, WCP-15.
13
WCP-15 Multiple Instances without a priori Runtime
Knowledge
Within a given process instance, multiple instances of an activity can be created. The required number
of instances may depend on a number of runtime factors, including state data, resource availability and
inter-process communications, but is known before the activity instances must be created. Once
initiated, these instances are independent of each other and run concurrently. At any time, whilst
instances are running, it is possible for additional instances to be created. It is necessary to synchronise
them upon completion before any subsequent tasks can be triggered.
This pattern is implemented via parent-child relationships, which are instantiated when a parent spawns
a child state machine. The FlowConnect engine uses these relationships to force the parent to wait until
all its children reach a predetermined state (the “flagged state”). The number of child instances
spawned by a parent may be determined at runtime based on data maintained by the parent state. The
number of child instances is affected in the following ways:
-
Spawning a new child instance increases the number of children that a parent tracks by one.
Cancelling/deleting a child decreases the number of children that a parent tracks by one.
To manage multiple instances without a priori runtime knowledge the FlowConnect engine waits for all
child instances to reach the “flagged state” and it does not care how those child objects were
instantiated i.e. based on design knowledge, runtime knowledge or ad-hoc instantiation. In the example
below, the flagged state for each of the children is the state named State 002. The flagged state is a state
in a child state machine which allows the parent to know that the child lifecycle is finished.
14
State-Based
WCP-16 Deferred Choice (Deferred XOR Split)
One of several branches is chosen based upon interaction with the environment. Prior to the decision all
possible future courses of execution are presented. After the decision is made execution alternatives
other than the one selected are removed.
By default in FlowConnect a choice between multiple transitions emanating from a given state is
always deferred until the last moment possible, based on the occurrence of events. The example below
shows a deferred choice where four events are possible from a single state and the event raised is not
known until the latest possible time. This is the result of the way the engine is designed. The decision
which branch to follow is deferred until the last possible moment which is immediately after an event is
raised. The receipt of that event by the engine causes a transition to be made to another state.
An example of a deferred choice between four states.
WCP-17 Interleaved Parallel Routing
A set of tasks is executed in a sequence that is determined at runtime. No two activities can be active at
the same time. The tasks synchronise upon completion.
Not supported.
15
WCP-18 Milestone
An activity is enabled, but cannot be completed until a milestone is reached elsewhere, which has not
expired.
In this example, State 003 in state machine StateMachine02 sends a message signal to State 005 in state
machine StateMachine03 and if State 005 also receives the event E3, tasks belonging to State 005 can
be performed.
However, this is not exactly equivalent to checking a place for the existence of a token in a place,
which is how the milestone pattern is modelled in a Petri Net. So if a token arrives in State 005 we will
only “see” it if State 003 is activated, which might not always occur in the case where State 003 is
activated by multiple other places.
16
Cancellation
WCP-19 Cancel Activity
Disable an enabled activity, before it is completed.
Tasks may be cancelled by timeouts or can be cancelled by explicitly defined cancellation events in
FlowConnect.
WCP-20 Cancel Case
A workflow instance (case) and its descendants are disabled and removed.
The simplest way to cancel a case in FlowConnect is to send a running case (an instance of a parent
state machine) to an end state where the state machine will implicitly terminate. Yet it is possible that a
case may be cancelled by every state in a state machine, leading to spaghetti state diagrams where all
states are connected to the same cancellation state. To avoid this, a shortcut notation can be used as
shown in the figure below.
Potential spaghetti diagram
Equivalent Shortcut notation for cancel case
17