Implementation of Standard Workflow Control Patterns

This document describes all the gates and wires that are available by default within the Kontinuum Design Studio. Each gate will describe its recommended usage as well as the patterns that each gate conforms to (this may be in conjunction with other gates).

For the purposes of this document, we will show the simplest schematic possible that adequately displays a pattern.

The Kontinuum interface displays blue flowing water through each of the pipes which indicates that a gate has been reached. An empty pipe indicates that a point has not yet been reached within a workflow instance.

Definitions

Workflow/Workflow Template: The Process design

Workflow Instance: An individual instance of associated information under which the transition of tasks and information is specified by a workflow template.

Gates: A location in a workflow instance which performs some function

Wires: A type of gate that connects other gates and does not perform any meaningful transitions in relation to the state or status of a workflow instance

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 articulate business rules in a workflow template.

Task: A unit of work done at a singular point by a singular person or system within a workflow.

All Definitions of workflow patterns are taken from: http://is.tm.tue.nl/research/patterns/ and can be viewed in abbreviated form in Appendix A at the end of this document.

Additional Information

Kontinuum always re-evaluates the status of all tasks within a workflow instance whenever that workflow instance is viewed or information within the workflow instances is modified. In effect viewing or modifying triggers all workflow instance tasks to be “recalculated” based on the latest information.

Tasks/Activities

Human tasks within Kontinuum have an associated form icon and show different colours depending on the status of that task. They are displayed as follows to the end user.

A task that has been completed and does not require approval.

A task that is awaiting completion by the user who is currently logged in.

A task may or may not need to be completed and is not yet available.

A task that is awaiting completion by a user who is not currently logged in.

A task that has been submitted and is awaiting approval.

A task that was rejected.

A task that was approved.

A task that is available for roll back.

A task that has been completed and the user who is currently logged in does not have rights to view or edit this task.

Please note: While Kontinuum workflow templates are generally designed without the notion of an overall state or status, for a workflow instance each of the tasks within a workflow instance has its own state. An overall state (used only for display purposes to end users) can be derived by determining the state of some or all of the tasks.

Placing forms from left to right is how Kontinuum satisfies the Series pattern. In this instance the first form is completed but the second form is not completed, thus the third form is unavailable.

If the second form is then completed the third form becomes available.

Tasks can be assigned to user groups not just individuals. These can override permission rules which assign tasks to one or more users for a particular workflow instance. These can be based on any criteria particular to a specific workflow instance.

If a Business rule evaluates to null, this in effect cancels the task, thus satisfying the Cancel Activity pattern.

GATES

AND Gates

AND gates bring together two or more inputs and only become live after all inputs are live. AND gates satisfy the Synchronisation Pattern.

In this instance the top task has been completed but the bottom task has not, therefore 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

Unlike AND gates the default behaviour for OR gates is to become live if ANY of their inputs are live. OR gates satisfy the Simple Merge pattern.

In this instance the top task has been completed and 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 had already proceeded past the OR gate earlier this will have no effect on the rest of the workflow instance.

Designers can set X number of inputs as required before the OR gate becomes live by placing a value in the Inputs Required Rule. Using the Inputs Required Rule for an OR gate is how Kontinuum satisfies the N out of M Join Pattern.

In this diagram the OR gate has an Inputs Required rule of 2 and only one live input, which prevents the OR gate from becoming live.

In this diagram the OR gate has an Inputs Required rule of 2 and 2 inputs have been completed which makes the OR gate live.

Please note: The completion of the bottom form will not have any effect on the later creation of tasks.

Decision Gates

A decision gate must include a business rule or logic statement. The WAFFL statement is always required to determine which path is taken when it reaches 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

Please note: Conditions may change which could cause a decision gate to re-evaluate and the workflow instance may switch and go down a different path. The default behaviour of the decision gate is to re-evaluate the decision regardless of whether a task has been completed downstream in one of the decision paths.

The business rule/decision rule, which is reliant on a particular outcome, can be modified so that once a path has been chosen and an activity has been completed the decision will no longer be re-evaluated. This is how Kontinuum satisfies the Deferred Choice Pattern.

Consider the following scenario:

In the first form there is a radio button called MYCHOICE which stores the values either 1 or 2.

If the first form is completed, the value supplied for the MYCHOICE radio button is 1 and the decision rule is @@DB.MYCHOICE then the diagram will look like:

Regardless of whether the top form in the third column was completed if the user edits the value of MYCHOICE the diagram will look like:

To satisfy the Deferred Choice pattern, the decision rule needs to determine if any forms have been completed (excluding the 1^st form). If so, it should pick the path that was already completed if not evaluate the MYCHOICE answer. The decision rule would have the following syntax.

if{

sqlval{

select count(*) > 0 from completed_forms where x_coordinate > 1

}

sqlval{

select max(y_coordinate) from completed_forms where x_coordinate > 1

@@DB.MYCHOICE

}

In order for a decision gate to satisfy the Multiple Choice pattern, it must have a decision rule that evaluates to more than one value.

For instance consider a workflow where there are two questions in the first form MYCHOICE1 and MYCHOICE2.

If MYCHOICE1 is ticked it stores the value 1 and if MYCHOICE2 is ticked it stores the value 2. If the decision rule is [@@DB.MYCHOICE1][@@DB.MYCHOICE2]. If the user ticks MYCHOICE1 the workflow looks like the following diagram:

If the user ticks MYCHOICE1 and MYCHOICE2 then the workflow looks like the following diagram:

Please note: Kontinuum has the facility to satisfy Multiple Choices that are also Deferred Choices. In this pattern if a path has been selected and a task has been completed, the decision rule can be designed in such a way that this path must always be live.

Stop Gate

The stop gate signifies the end of a branch of control flow within a workflow instance. The default behaviour in Kontinuum is that when all tasks have been completed the workflow is deemed completed. Placing stop gates at the end of all paths is how Kontinuum satisfies the Implicit Termination pattern.

Please note: Every branch must end with something usually a stop or lock gate so the water does not ‘flow out of the pipe’ so to speak.

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 cycled. Once a loop counter is live it ‘erases’ all completed tasks that occurred within a loop. The Loop counter in conjunction with a decision gate and an OR gate are how Kontinuum satisfies the Loop/Cycle pattern.

In the following diagram Loop Counter 1, the 4th task is available to the user. If they complete it and the decision rule determines that the loop should be activated then the result will be Loop Counter 2 Diagram. The Loop counter will effectively determine that the second, third and fourth step need to be redone.

Diagram Loop Counter 1

Diagram Loop Counter 2

Please note:

§ Loop Counters can be embedded within other loops.

§ All Loops need a decision gate somewhere in them to avoid an infinite loop.

§ All Loop gates are used in conjunction with an OR gate; the flow requires entering the loop and then proceeding around the loop if the exit condition in the decision gate is not met.

Lock Gate

The lock gate can be used to delete or prevent further alteration of a workflow instance. When a workflow instance becomes locked, all pending activities/tasks and privileges are removed. The lock gate is used to satisfy the Cancel Case Pattern.

In the following workflow if top form is completed,

then the workflow reaches a lock gate which removes all pending tasks and sets any completed tasks as read only.

Splitter Gate

The splitter gate is used to create one or more instances of sub workflows and determine when the main workflow may proceed. The splitter gate is used to satisfy the multiple-instance patterns. The behaviour of the splitter gate is governed by three parameters:

§ The first parameter is the name of the sub workflow template that is used to spawn workflow instances.

§ The second parameter is the population rule. This rule determines how many instances of the sub workflow are created and what the 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 behaviour of the splitter gate is that it is only considered complete after all sub workflows have completed all tasks.

Consider the following example scenarios:

The first form in a workflow is called PARENT with a primary key field MYTEXT.

There is a splitter gate in the second location with a population statement of

[@@DB.MYTEXT,,1][@@DB.MYTEXT,,2]

and the completion rule of 0.

There is a sub workflow called CHILD it has two primary keys.

This has the following effects:

After the first task is completed two sub workflows are created. Under these criteria the splitter gate satisfies the Multiple Instance without Synchronisation pattern. If the completion rule is blank, when all tasks have been completed in both sub workflows then the splitter gate is considered completed.

This is how the splitter gate satisfies the Multiple Instances with a Priori Design Time Knowledge pattern.

Now consider the population statement is set to:

sqlset{select @@DB.MYTEXT, 1 from mytable where NumberToSpawn >= 1 union select @@DB.MYTEXT, 1 from mytable where NumberToSpawn >= 2 union select @@DB.MYTEXT, 1 from mytable where NumberToSpawn >= 3}

and there is a question called NumberToSpawn in the first form.

If the value given in the NumberToSpawn question is 1 then one sub workflow instance is spawned. If the value given in the NumberToSpawn question is 2 then two sub workflow instances are spawned. If the value given in the NumberToSpawn question is 3 then three sub workflow instances are spawned. If the value of NumberToSpawn changes from 1 to 3 then two new sub workflow instances will be spawned. This is how the splitter gate satisfies the Multiple Instances Without a Priori Runtime Time Knowledge pattern.

As it satisfies the Multiple Instances Without a Priori Runtime Time Knowledge pattern it also satisfies the Multiple Instances With a Priori Runtime Time Knowledge pattern.

The Diagram below shows a splitter gate that has a completion rule which evaluates to true or 1

The Diagram below shows a splitter gate that has a completion rule which does not evaluate to true or 1

WIRES

Wires are used within Kontinuum to connect gates. Wires have at most one IN direction but can have one or more 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

Using Kontinuum’s wires satisfies the Split/Fork Pattern. In this instance once the 1st form has been completed, 2 forms become available. The availability of the top and bottom form is not reliant on the completion of one or the other.

Please note: All wires are directional.

OTHER WORKFLOW PATTERNS

To satisfy the Milestone pattern, a business rule is added to a gate to check if a milestone has been reached and has not expired.

Please note: Each task has a status that determines its completion. All tasks/activities have rules which determine whom the task should be assigned to.

To satisfy the Interleaved Parallel Routing pattern, a rule is added to the gates at the start of both branches. This rule states that if the other branch has been started but not completed then the rule evaluates to nothing, otherwise it evaluates to the user or users whom can access the task.

Consider the following workflow with a primary key called MYTEXT and a user called Tom.

In order to satisfy the Interleaved Parallel Routing pattern the top task (red) could have the following rule associated with it:

Sqlval{select case when count(*) <> 1 then ‘Tom’ else ‘’ end from completed_forms where @@Session.MYTEXT = MYTEXT and y_coordinate = 3}

The bottom task (red) could have the following rule associated with it:

Sqlval{select case when count(*) <> 1 then ‘Tom’ else ‘’ end from completed_forms where @@Session.MYTEXT = MYTEXT and y_coordinate = 1}.

In this case both red forms are available to the user Tom. However if either the top or bottom form is completed then Tom must wait for the next form to be completed before he can access the first form in the path that he did not select.

Non Flow Control Gates

Non Flow gates do not affect the control flow of a workflow instance. When these gates are reached they perform a single action. Then proceed to the next gate in the sequence.

§ SQL Update: Performs an action on a 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 delay tasks so that they are only available before, after or during a certain timeframe.

Tasks can be escalated to different Kontinuum users; this does not necessarily affect the visual layout of the workflow.

Kontinuum provides a facility for third party developers to create their own gates and place them within workflows.

APPENDIX A

Abbreviated Workflow Pattern Definitions

Cancel Activity

An enabled task/activity is disabled. For example: A thread waiting for the execution of an activity is removed.

Cancel Case/Lock Gate

A case or workflow instance is removed completely. For example: If parts of the workflow are instantiated multiple times, all descendants are removed.

Deferred Choice/Evaluate Once

A point in a workflow where one of several branches is chosen. In contrast to the decision gate, the choice is not made explicitly (based on data or a decision) but several alternatives are offered to the environment. 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 has actually started (the moment of choice is as late as possible).

Discriminator

The discriminator is a point in a workflow that waits for one of the incoming branches to be completed before activating the subsequent activity/task. 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 (important otherwise it cannot be used in the context of a loop).

Exclusive Choice/Decision

A point in the workflow process where, based on a decision or workflow control data, one of several branches is chosen.

Implicit Terminator/Stop Gate

A given sub process should be terminated when there is nothing else to be done. For example: There are no active tasks in the workflow and no other tasks can be made active.

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. For example: No two activities are active for the same workflow instance at the same time.

Loop/Cycle:

A point in a workflow where one or more activities is repeated.

Milestone

The enabling of an activity depends on the case being in a specified state. For example: The activity is only enabled if a certain milestone has been reached which has not yet expired.

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 another activity needs to be started. The difference with Pattern 14 is that while some of the instances are being executed or are already completed, new ones can be created.

Multiple Instances without Synchronization

Within the context of a single case (i.e. workflow instance) multiple instances of an activity can be created. For example: Kontinuum has the capability to spawn off new threads of control. Each of these threads is independent of other threads. There is no need to synchronise these threads.

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 "bec