Understand the use case

Consider a business scenario, where a process involves a Main task and multiple optional tasks, which can be done in parallel to the main task. However, when the main task is completed, the active optional tasks should be closed, as the process now needs to move forward. There are multiple solutions to this problem, which can either be achieve

1. By using conditional activities – in case each optional activity is performed only depending on certain criteria.
2. Multi-instance loops – in case all tasks are essentially same assigned to all members of a team or ad-hoc group. If any or a certain number of people complete their tasks, the rest are cancelled.
3. By using UCA – in case the cancellation is to be triggered asynchronously or externally.
4. By using server script to cancel previous tasks – in case main task is assigned to a single group/person, different from the optional tasks in nature, optional tasks never become mandatory based on conditions and completion of main task demands the closure of all optional tasks.

Understand the scope and audience

The document scope is limited to the discussion of scenario #4 as described in the introduction. The other scenarios, such as scenario #2 and #3 are already used extensively in practice.

The target audience for this document are all IBM BPM practitioners, architects and business analysts involved in story-boarding and design.

Design the Process

Considering the use case – An insurance claim process requires certain number of activities to be performed on the claim. However if the claim is approved in the main review – the other activities which may be uploading of optional documents or case history, may be by-passed. For the flow to move forward these optional tasks need to be cancelled.

Workflow design

The workflow is designed to have a simple split to create parallel flow for all the concerned tasks. The main task is followed by a server script for cancelling the remaining open tasks. The process may be halted here and more diverse decisions can be made depending on the practical business use story.

The join should be an intelligent join, so that it will not wait for all tokens to arrive, before moving forward. This is usually Inclusive Gateway.

The optional tasks should be having a pre-condition where the step id is captured into a local variable. This step ids will be used to cancel the steps needed in the server script. Optionally post conditions may also be set for further complex flows.

Implement the Process

Implementation will vary depending on each scenario. The workflow is already implemented during the design phase. If design is correct then the only implementation stage to be left is the server script.

Pre-condition

The pre-condition is to store the step id of the optional task into a local variable for later use. This may be list of Integers or simple.

Where ListOfSteps is

Note: This list may need to initialize before use.

Server Script

The server script is simple loop depending on the number of optional tasks need to be closed. Here in the example the loop is run for the list length of ListOfSteps.

At its simplest form it should look like this –

for(var i = 0; i< tw.local.ListOfSteps.listLength; i++){

    tw.system.cancelStep(tw.local.ListOfSteps[i]);   

    }

Identify Usage

This design pattern is useful in the following use cases –

1.     The business process has one main task and multiple optional tasks in parallel to the main task.

2.     The optional tasks does not become mandatory depending on any condition

3.     The optional tasks does not become inactive depending on any condition

4.     The closer of main task demands the closure of all active optional tasks irrespective of the status of the optional tasks.

This implementation can be augmented with scenario #1 to cater to complex processes.

Tips, Best practices and Recommendations

When implemented in a real-life project various practical problems may arise, such as –

·         Some optional tasks may become mandatory depending on conditions

·         Some optional tasks may have been closed before main task, needing null check to be introduced

·         More optional or mandatory tasks may be introduced at a later stage

Most of the above mentioned problems may be easily handled through introduction of various checks and variables in the server script OR the pre-post conditions. E.g. –

·         A post condition may set the list of steps for a particular task as NULL, once it is completed

·         A null check may be introduced in the server script to see if a cancellation step should be run or not

Hard-coding should be avoided to retain code robustness and scalability.