Implementation of Standard Workflow Control
Patterns using Kontinuum v2006
Document Structure
This
document describes all of the gates and wires that are available by default to
the Kontinuum Designer. Each gate will describe
its recommended usage as well as what standard patterns are satisfied by way of
using this gate (possibly in combination with other gates).
For the
purposes of this document and easy of illustration diagrams will show the
simplest schematic possible that adequately displays a pattern.
In the end
user environment blue flowing water indicates that a gate has been reached
while an empty pipe indicates that a point has not yet been reached within a
workflow instance.
Definitions
Workflow/Workflow
Template: A template for a how a process is followed.
Workflow
Instance: An individual instance of associated information which follows a
schematic as specified by a workflow template.
Live: A wire
or gate is considered live if it has been reached within a workflow instance
WAFFL: Web
and Flo Functional Language, used to make programmatic decisions in the
workflow.
Activity/Task:
A unit of work done at a singular point within a workflow.
All
Definitions of workflow patterns are taken from: http://is.tm.tue.nl/research/patterns/
Tasks
Human tasks within Kontinuum
have a form icon and show different colors depending on the status of the
form. They are displayed as follows to
the end user.
a task that has been completed and did not require
approval.
a task that is
waiting completion by the user who is currently logged in.
a task within the
workflow that has not yet been reached.
a task that is
waiting completion by the user who is not currently logged in.
a task that has been
submitted and is waiting approval.
a task that was
rejected.
a task that was
approved.
a task that is
available to be rolled back.
a task that has been
completed and the user who is currently logged in does not have
access rights to the information pertaining
to this task.
Sequence / Series
Sequence: An activity in a workflow process is enabled after the
completion of another activity in the same process.
In this instance the first form is
completed but the second form is not completed, thus the third form is unavailable.
In the second form is then completed
the third form becomes available.
Tasks can be given permissions to
user groups but tasks also have override permission rules which assign the
tasks to one or more users for a particular workflow instance based on any
criteria particular to a workflow instance.
If the rule evaluates to nothing
this in effect cancels the task thus satisfying the cancel activity pattern.
Cancel
Activity
Cancel Activity: An enabled activity is disabled, i.e. a thread waiting for the execution of an activity is removed.
Wires
Wires within
Kontinuum are used to connect gates.
Wires have at most one in direction but can have one or multiple out
directions. A wire with more than one
output direction can be called a split or fork.
Examples of
wires:
Examples of
wires that fork
Split/Fork
Fork: A point in the workflow process where a single thread
of control splits into multiple threads of control which can be executed in
parallel, thus allowing activities to be executed simultaneously or in any
order.
In this
instance after the initial form has been completed two forms become available
and can either the top of the bottom form is not reliant on the completion of
the other
And Gates
Synchronization
Synchronization/AND: A point in the
workflow process where multiple parallel sub processes/activities converge into
one single thread of control, thus synchronizing multiple threads. It is an
assumption of this pattern that each incoming branch of a synchronizer is
executed only once
And gates bring together two or more
inputs and only become live after all inputs are live.
In this instance the top task has
been completed but the bottom task has not and therefore none of the workflow
has not proceeded past the AND gate.
In this
instance both top and bottom tasks have been completed and thus the workflow
proceeds past the AND gate
Or Gates
Simple Merge
Simple Merge/OR: A point in the
workflow process where two or more alternative branches come together without
synchronization. It is an assumption of this pattern that none of the
alternative branches is ever executed in parallel.
Unlike AND gates the default
behaviour for OR gates is become live if ANY of there inputs are live.**
In this instance the top task has
been completed thus the workflow has proceeded past the OR gate.
In this
instance both top and bottom tasks have been completed and thus the workflow
proceeds past the OR gate. However since
the workflow already had proceeded past the OR gate earlier this will not have
an effect on the rest of the workflow instance.
**designers can also set the x number of inputs are
required before the OR gate becomes live but setting the Inputs Required
Rule. This is known as the N out of M
Join Pattern.
N-out-of-M Join:
N-out-of-M Join:
N-out-of-M Join is a point in a workflow process where M parallel
paths converge into one. The subsequent activity should be activated once N
paths have completed. Completion of all remaining paths should be
ignored. Similarly to the discriminator, once all incoming
branches have "become live", the join resets itself so that it can fire again.
By setting a dynamic N value depending on how many
choices may have been taken by a decision gate the OR gate satisfies the
Synchronizing Merge pattern.
Synchronizing Merge
A point in
the workflow process where multiple paths converge into one single thread. If more than one path is taken, synchronization of
the active threads needs to take place. If only one path is taken, the
alternative branches should reconverge without synchronization. It is an
assumption of this pattern that a branch that has already been activated,
cannot be activated again while the merge is still waiting for other branches
to complete.
Decision Gates
Exclusive Choice
Exclusive Choice/Decision: A point
in the workflow process where, based on a decision or workflow control data,
one of several branches is chosen.
A decision gate must include a logic
statement.
A WAFFL
statement is usually required to determine which path is taken using a decision
gate. The statement must return a number
indicating which path is chosen. In this instance the top task is available because the
decision gate evaluated to 1.
In this
example the decision gate evaluated to 2
*Note that
conditions may change which may cause a decision gate to re-evaluate the rule
and thus a workflow instance that went down one path may switch to go down
another path.
Deferred
Choice
Deferred
Choice/Evaluate Once: A point in the workflow process where one of several
branches is chosen. In contrast
to the Decision
Gate, the choice is not made explicitly
(e.g. based on data or a decision) but several alternatives are offered to
the environment. However, in contrast to the AND-split, only one of the
alternatives is executed. This means that once the environment activates one of
the branches the other alternative branches are withdrawn. It is important to
note that the choice is delayed until the processing in one of the alternative
branches is actually started, i.e. the moment of choice is as late as
possible.
In order for a decision gate to be treated
as a deferred Choice the Evaluate Once rule for the decision Gate must be set
to or evaluate to 1.
Multiple
Choice
Multiple Choice:
A point in the workflow process where, based on a decision or workflow control
data, a number of branches are chosen.
In order for a decision gate to be treated as a multiple choice is must evaluate to more then one value. For instance a decision rule that sets the first and third output to live must evaluate to [1][3]
Stop Gate
Implicit
Terminator
Implicit Terminator/Stop Gate: A given sub process should be terminated when
there is nothing else to be done. In other words, there are no active
activities in the workflow and no other activity can be made active.
For instance
in the following workflow has reached a terminator because there are no other
tasks awaiting completion. The stop gates signify the end of a branch of
control flow within a workflow instance.
*Note that
within Kontinuum every branch must end with something usually a stop or lock
gate and the water is not allowed to ‘flow
out of the pipe’.
Loop Counter Gate
The loop counter is used to
determine where a feedback loop begins.
A loop counter monitors how many times a loop has been gone
through. Once a loop counter becomes
live it ‘erases’ all completed tasks that occur within a loop
Loop/Cycle:
Loop/Cycle: A point in a workflow
process where one or more activities can be done repeatedly.
For instance in the following
diagram Loop Counter 1, the fourth task is available to the user, if they
complete it and the decision rule determines that the bottom path should be
taken then the result is Loop Counter 2 Diagram. The
Diagram
Diagram
Discriminator
Discriminator: The discriminator is a point in a workflow
process that waits for one of the incoming branches to complete before activating
the subsequent activity. From that moment on it waits for all remaining
branches to complete and "ignores" them. Once all incoming branches
have been triggered, it resets itself so that it can be triggered again (which
is important otherwise it could not really be used in the context of a loop).
Once a Loop Counter has been enacted
every gate acts as a de facto discriminator as all gates know if they have or
have not been processed since the last time the loop counter was reached.
*Loop Counters can be embedded
within other loops.
**All Loops need a decision gate somewhere in them to avoid an infinite loop.
Lock Gate
The lock
gate can be used to delete or prevent further alteration or information
regarding a workflow instance. When a
workflow instance becomes locked all pending activities/tasks and privileges
are removed.
Cancel Case
Cancel Case/Lock Gate: A case,
i.e. workflow instance, is removed completely (i.e., even if parts of the
process are instantiated multiple times, all descendants are removed).
For instance in the following
workflow if top form is completed
Then the
resulting workflow locks all tasks and removes privileges such that they are
only read only.
Splitter Gate
The splitter
gate is used to create one or more instances of sub workflows. The behavior is governed by 3
parameters:
The first
parameter is the name of the workflow template that is used for the spawned
workflow instances.
The second
parameter is the population rule. This
rule determines how many instances of sub workflow are created and what any key
information might be.
The third
parameter is the completion rule. The
completion rule determines under what conditions the group of sub workflows is
considered complete. If the completion
rule is left blank then the default behavior of the splitter gate is that it is
only considered complete after all of the sub workflows have no tasks pending. Setting the completion rule equal to 1 or
true means that the splitter gate will always be considered live once it has
been reached. This has the effect of
performing the Multiple Instances without Synchronization Pattern.
Multiple Instances
without Synchronization
Multiple
Instances without Synchronization: Within the context
of a single case (i.e., workflow instance) multiple instances of an activity
can be created, i.e., there is a facility to spawn off new threads of control.
Each of these threads of control is independent of other threads. Moreover,
there is no need to synchronize these threads.
*Note that
each time a workflow instance with a splitter is viewed the population rule and
the completion rule is re-evaluated. In
this manner the splitter gate performs the Multiple Instances without a Priori
Runtime Knowledge pattern.
Multiple Instances
without a Priori Runtime Knowledge
Multiple
Instances without a Priori Runtime Knowledge:
For one case an activity is enabled multiple times. The number of instances of
a given activity for a given case is not known during design time, nor is it
known at any stage during runtime, before the instances of that activity have
to be created. Once all instances are completed some other activity needs to be
started. The difference with Pattern 14 is that even while some of the instances
are being executed or already completed, new ones can be created.
In order to satisfy the Multiple Instances with a Priori Runtime Knowledge the population statement has a logic check in it to determine if instances have already been created then do not spawn more instances.
Examples of
a splitter gate awaiting completion and a splitter gate that is complete
Other Workflow Patterns
Milestone
Milestone: The enabling of an activity depends on the case being
in a specified state, i.e. the activity is only enabled if a certain
milestone has been reached which did not expire yet.
To satisfy the milestone pattern a
rule is placed on a gate to check if a milestone has been reached and has not
expired. If the rule evaluates to the
user or users whom can access the activity otherwise it evaluate to nothing.
Interleaved
Parallel Routing
Interleaved Parallel Routing: A set
of activities is executed in an arbitrary order: Each activity in the set is
executed, the order is decided at run-time, and no two activities are executed
at the same moment (i.e. no two activities are active for the same
workflow instance at the same time).
To satisfy the interleaved parallel routing pattern a rule is placed on the gates at the start of both branches that are done in parallel. This rule states that if the other branch has been started by not completed then the rule evaluates to nothing otherwise it evaluates to the user or users whom can access the activity.
Non Flow Control
Gates
These gates do not affect the
control flow of workflow. When these
gates are reached they perform an action.
Then proceed to the next gate in the sequence.
SQL Update: Performs an action on the database
Report Display: Displays or
sends a report to one or more users
Send Email: Sends an email
Run Executable: Runs an
executable file.
Other Factors in
Workflow Design
Kontinuum
allows tasks can be available only before, after or during a certain timeframe.
Tasks can be
escalated to different resource within a system but this does not necessarily effect the design of the workflow.
Kontinuum
allows third party developers to create their own gates and place them within
workflows.
Control Flows Summary
|
Pattern |
Support |
Complexity |
|
|
Sequence |
Yes |
+ |
|
|
Parallel |
Yes |
+ |
|
|
Synchronization
|
Yes |
+ |
|
|
Exclusive
Choice |
Yes |
- |
Statement
supplied to determine which path is taken |
|
Simple
Merge |
Yes |
+ |
|
|
Multi
Choice |
Yes |
- |
Statement
supplied to determine which path(s) is taken |
|
Synchronizing
Merge |
Yes |
+ |
|
|
Multi
Merge |
Yes |
- |
Parameter
supplied indicating number of live paths required |
|
Discriminator
|
Yes |
+ |
|
|
Arbitrary
Cycles |
Yes |
+ |
|
|
Implicit
Termination |
Yes |
+ |
|
|
**MI
without Synchronization |
Yes |
- |
A value of
1 supplied for the completion rule |
|
**MI with
a Priori Design Time Knowledge |
Yes |
- |
|
|
**MI with
a Priori Runtime Knowledge |
Yes |
- |
|
|
**MI
without a Priori Runtime Knowledge |
Yes |
- |
|
|
Deferred
Choice |
Yes |
+ |
|
|
Interleaved
Parallel Routing |
Indirect |
* |
A
statement for permissions must be supplied |
|
Milestone |
Indirect |
* |
A
statement for permissions must be supplied |
|
Cancel
Activity |
Indirect |
* |
A
statement for permissions must be supplied |
|
Cancel
Case |
Yes |
+ |
|
+Indicates only placement of gates is required
- Indicates
parameters must also be supplied
* Indicates
a logic statement is required
** For all MI
patterns a population rule is required which determines how many instances of a
sub workflow are created and what the key identifying properties of those
criteria may be.
For more information on Kontinuum please visit www.webandflo.com