Introduction

The Workflow Patterns Initiative (WPI) was established with the aim of delineating the fundamental requirements that arise during business process modeling on a recurring basis and describe them in an imperative way. It's widely used or referenced when enterprises want to model their workflow. In the first WPI version, 20 patterns were delivered in 2003. The number increased to 43 in the latest release. Those patterns post a big challenge to all kinds of BPEL engines. It's very difficult to support each one. In another word, one BPEL engine which can support those patterns well should gain more customers as its power.

WebSphere Process Server (WPS) is a powerful business process automated engine with high performance which provides perfect runtime support for all kinds of process. And WebSphere Integrated Developer (WID), as the development tool for applications running on WPS, can be used by customers to model their workflow visually. Customers just need drag-and-drop without any coding. The executable BPEL code will be generated automatically. Comparing with other BPEL engine products, Customers can implement the 43 patterns with the latest WID v7.0 and WPS v7.0 more easily and graciously.

In part 1 of this article series, we will introduce 2 categories patterns (Basic Control Flow Patterns and Cancellation and Force Completion Patterns) in detail.

Back to top

Basic control flow patterns

There are 5 basic patterns in this category, including:

1. Sequence
2. Parallel Split
3. Synchronization
4. Exclusive Choice
5. Simple Merge

All of those are fundamental workflow patterns. They're widely used in customers real business scenario. With them, we can implement basic and simple workflow.

Back to top

Sequence

This pattern requires executing tasks in sequence. This is the most fundamental workflow pattern. All business processes have this kind of building block.

For example, in bank credit card apply process, after applicant submits request, then credit check is performed. This "After-Then" scenario is the typical case which fits in Sequence pattern.

Another example is online train ticket system. Choose train ticket, pay on line, print ticket, those tasks should be executed one after another. This "one after another" scenario fits in Sequence pattern also.

Pattern detail description is here.

Analysis

The focus of this pattern is:

1. Task order is defined in process design period. In the process, does which task firstly, does which task next, that is predefined in model phase.
2. One task is enabled after preceding task completed. No condition requires.

In WID, tasks are executed in sequence by default.

Implementation

Case2 is executed right after Case1.

Run on WPS

[8/23/10 14:52:16:453 GMT+08:00] 0000004e SystemOut     O [Sequence] Run into Case1
[8/23/10 14:52:16:453 GMT+08:00] 0000004e SystemOut     O [Sequence] Run into Case2

Back to top

Parallel Split

This pattern requires executing tasks in parallel. It's widely used as almost all processes want to do some tasks concurrently to increase system efficiency.

For example, in bank credit card apply process, after applicant submits request, credit check including id check and existing account check are performed by different owners in parallel. This is a typical case which needs Parallel Split pattern.

Analysis

The focus of this pattern is:

1. The process splits into two or more branches at a given point.
2. Those split branches are executed concurrently. And they may or may not be re-synchronized at some future time.
3. All branches are defined in process model phase.

In WID, we can use Parallel Scope for this pattern easily.

Implementation

Case1, Case2, Case3 are executed in parallel.

Run on WPS

            
[8/23/10 14:53:55:140 GMT+08:00] 0000004e SystemOut     O [Parallel_Split] Run into Case2
[8/23/10 14:53:55:171 GMT+08:00] 0000004e SystemOut     O [Parallel_Split] Run into Case1
[8/23/10 14:53:55:187 GMT+08:00] 0000004e SystemOut     O [Parallel_Split] Run into Case3

Note: From the log, we can see three branches run in sequence in the same thread. That's because of the database limitation. Detail reason has already be documented to a tech note here: http://www-01.ibm.com/support/docview.wss?uid=swg21293793.

Back to top

Synchronization

This pattern requires synchronizing several branches into one node. It's always used together with Parallel Split pattern to synchronize split tasks' result.

Synchronization pattern provides a means of re-converging those parallel branches which are created using the Parallel Split construct earlier in the process model. The thread of control is passed to the task immediately following the synchronizer once all of the incoming branches have completed.

For example, in bank credit card apply process, after applicant submits request, credit check including id check and existing account check are completed in parallel, credit result task runs immediately. Here credit result task is Synchronization block.

Pattern detail description is here.

Analysis

The focus of this pattern is:

1. Two or more branches merge into one subsequent branch.
2. When all input branches completed, the process goes to the subsequent branch immediately.

In WID, we use Parallel Scope to start two or more branches concurrently, and use link to merge them into one subsequent branch.

Implementation

Case1 and Case2 are started in parallel, when they’re both finished, process sync together, and Case3 is executed.

Run on WPS

                 
[8/23/10 14:55:27:484 GMT+08:00] 0000004e SystemOut     O [Synchronization_Basic] 
                                                            Run into Case1
[8/23/10 14:55:27:484 GMT+08:00] 0000004e SystemOut     O [Synchronization_Basic]   
                                                            Run into Case2
[8/23/10 14:55:27:500 GMT+08:00] 0000004e SystemOut     O [Synchronization_Basic] 
                                                            Run into Case3

Back to top

Exclusive Choice

This pattern requires just enabling one branch out of several branches. Which branch to take is depending on the outcome of a preceding task, the values of specific data elements in the process, the results of an expression evaluation or some other form of programmatic selection mechanism.

This pattern is also widely used as business decision is needed in every company. The routing decision is made dynamically allowing it to be deferred to the latest possible moment at runtime.

For example, in bank credit card apply process, following routing branch depends on credit result task's result, if result is pass, process goes to card producing task; if result is fail, process goes to request fail task; if result is pending, process goes to 2nd review task. This is a typical scenario which needs Exclusive Choice pattern.

Pattern detail description is here.

Analysis

The focus of this pattern is:

1. One branch split into two or more subsequent branches.
2. Just one subsequent branch can be enabled as condition defined.
3. Routing is dynamic based on some specific data elements etc.

In WID, we have 2 solutions for this pattern.

• Solution 1: Choice
• Solution 2: Generalized Flow with Folk Gateway

Implementation

Solution 1 uses Choice, detail condition is defined in different cases, while Solution 2 uses Generalized Flow with Folk gateway, detail condition is defined in links to each case.

Run on WPS

In either solution, process just runs into Case1.

               
[8/23/10 14:58:38:296 GMT+08:00] 0000004e SystemOut     O [ExclusiveChoice] Run into Case1
[8/23/10 14:58:38:328 GMT+08:00] 0000004e SystemOut     O [ExclusiveChoice] Run into Case1

Back to top

Simple Merge

This pattern requires enabling merged node when one of incoming branches completes. It's used in the business scenario when need merge two or more distinct branches without synchronizing them. As such, it presents the opportunity to simplify a process model by removing the need to explicitly replicate a sequence of tasks that is common to two or more branches. Instead, these branches can be joined with a simple merge construct and the common set of tasks needs only to be depicted once in the process model.

For example, in bank credit card apply process, after either branch (card producing, request fail or 2nd review) is executed according to different credit result task's result, notify customer task is needed in common. Here we need Simple Merge pattern.

Pattern detail description is here.

Analysis

The focus of this pattern is:

1. Two or more branches merge into a single subsequent branch.
2. Each input branch completion will enable subsequent branch.

Note: It's similar to Synchronization pattern as both of them requires branches merge into one node. The difference is at the situation that fires merged node. In the Synchronization pattern, the merged node is deployed when incoming branches are all executed. While in Simple Merge pattern, merged node is fired when one of the incoming branches is executed.

In WID, we use Choice to implement this.

Implementation

Case1, Case2 and otherwise are enabled, but only one branch is taken as defined condition, after choice scope completes, process goes to “SimpleMerge” activity.

Run on WPS

 
[8/23/10 14:59:53:093 GMT+08:00] 0000004e SystemOut     O [Simple Merge] Run into Case1
[8/23/10 14:59:53:109 GMT+08:00] 0000004e SystemOut     O [Simple Merge] 
                                                           Run into Simple Merge

Back to top

Cancellation and force completion patterns

There are five patterns in this category, including:

1. Cancel Task
2. Cancel Case
3. Cancel Region
4. Cancel Multiple Instance Activity
5. Complete Multiple Instance Activity

Those patterns are defined how to end task, process, set of task and multiple instances of task.

Back to top

Cancel Task

This pattern requires the single task which has been enabled or is already executing can be canceled. And where possible, the currently running instance is halted and removed. This pattern is the most common used pattern when customer wants to cancel an existing uncompleted single task. It provides a way to cancel unnecessary task which results in process' termination.

For example, in bank credit card apply process, customer should be able to cancel the uncompleted customer request task if they change their mind and do not want to apply.

Another example is for automobile physical damage insurance case, access damage task is taken by two insurance assessors. Once the first assessor completed his task, the second need to be cancelled.

Patten detail description is here.

Analysis

The focus of this pattern is:

1. An enabled task is withdrawn prior to it commencing execution.
2. If the task has started, it is disabled.
3. The currently running instance is halted and removed.

There are two situations if tasks are performed in parallel or in sequence.

Such as above bank example, it is a sequence case. In WID, we can use Event Handler and Terminate to implement it. Mark it as Solution 1.

For above insurance case, it's a parallel case. In WID, we can use Throw, Fault Handler and Terminate to implement it. Mark it as Solution 2.

Note: When using event handler, need to configure correlation set id.

Implementation - Solution 1

Task1 and Task2 are performed in sequence. During Task1's executing, CancelTask can terminate the task as well as the process instance. Task2 will not be executed obviously.

Implementation - Solution 2

Task1 and Task2 are created concurrently. When one task is completed, the other task will be withdrawn. And process instance is terminated.

Run on WPS - Solution 1

After process starts, before Task1 completion, invoke "CancelTask", that way Task1 is terminated as well as the process instance (verified in below log).

  
[8/31/10 13:51:59:625 GMT+08:00] 00000061 SystemOut  O [Cancel Task] Task1 Start
[8/31/10 13:52:18:656 GMT+08:00] 00000061 SystemOut  O [Cancel Task] Cancel Task1

Task1 and process instance are terminated.

Run on WPS - Solution 2

Execution Steps:

1. Start a process instance.
2. Claim Task2.
3. Claim and complete Task1.

Then Task2 is canceled, process instance is terminated (verified in below log).

  
[8/23/10 17:28:44:812 GMT+08:00] 0000004e SystemOut     O [Cancel Task]Enter 
                                                                    Task1 Completed
[8/23/10 17:28:45:015 GMT+08:00] 0000004e SystemOut     O [Cancel Task]Enter 
                                                                    Cancel Task

Back to top

Cancel Case

This pattern requires canceling the whole process, including all currently executing tasks and sub-processes. It provides a way to halt a specified process instance and withdrawing any tasks associated with it.

For example, in bank credit card apply process, the process instance with all related tasks should be able to cancel if wait for customer's necessary input task is expired. At the same time, process instance should be marked as unsuccessful for future audit.

Pattern detail description is here.

Analysis

The focus of this pattern is:

1. Complete process instance is removed.
2. All process related tasks, currently executing or enabled, should be canceled.
3. All sub-processes will not be executed either.
4. The process instance is recorded as having completed unsuccessfully.

In WID, we use Event Handler and Terminate node to implement this pattern.

Implementation

After the process instance starts, Task1 and sub process instance are created in parallel. If CancelCase request comes in, all tasks, sub-process instance and parent process instance are all terminated.

Note: we should set sub process to "bind the life cycle to the invoking business process", that way, terminate action performed in parent process is able to terminate its sub processes also. Detail information for sub process lifecycle seen in WPS 7.0 information center.

Run on WPS

Execution Steps:

1. Start a process instance.
2. Claim Task1.
3. Invoke cancel operation.

After that, whole process including all tasks, sub process is terminated (verified in below log).

   
[8/31/10 11:36:28:531 GMT+08:00] 00000e5f SystemOut O [Cancel Case]Run into Initiate
[8/31/10 11:36:30:000 GMT+08:00] 00000061 SystemOut O [Cancel Case]Run into SubProcess
[8/31/10 11:37:07:078 GMT+08:00] 00000061 SystemOut O [Cancel Case]Run into CancelCase

The process instance, sub process instance and all uncompleted tasks are all terminated.

Back to top

Cancel Region

This pattern requires canceling a set of tasks. The tasks need not be a connected subset of the overall process model. It is a useful capability which provides a way to cancel a series of (potentially unrelated) tasks.

For example, in an on line store's sales promotion process, after 100 qualified customers get the award, need to cancel other customer request tasks.

Pattern detail description is here.

Analysis

The focus of this pattern is:

1. Disable a set of tasks in a process instance.
2. If any of the tasks are already executing, or are currently enabled, then they are withdrawn.
3. Tasks need not be a connected subset of the overall process model.
4. After cancel region, process instance should be able to continue next activity.

In WID, we partially support this pattern. Those tasks which can be canceled together should be in the same scope. We can use Nesting Scope, Event Handler, Throw and Fault Handler to implement this pattern.

Implementation

Task1 and Task2 are generated concurrently, when "CancelRegion" is invoked, all uncompleted tasks in the scope will be terminated. And process will go to AlternativeTask and Next activity.

Run on WPS

Execution Steps:

1. Start a process instance.
2. Claim Task1.
3. Invoke "CancelRegion".

Then Task1 (executing), Task2 (enabled), Task3 (not enabled) are withdrawn together. AltenativeTask is executed. After that, process goes to Next activity (verified in below log).

   
[8/31/10 10:48:12:078 GMT+08:00] 00000061 SystemOut     O [Cancel Region]Run 
                                                                into AlternativeTask
[8/31/10 10:48:12:078 GMT+08:00] 00000061 SystemOut     O [Cancel Region]Run 
                                                                into Next

Back to top

Cancel Multiple Instance Activity

This pattern requires canceling multiple instance activity. It provides a way to cancel a multiple instance task at any time during its execution such that any remaining instances are cancelled. However, any instances which have already completed are unaffected by the cancellation.

For example, in bank credit card apply process, we have three concurrent instance of final approve task to different person which should be completed in one day. If time out, the tasks whose owner doesn’t take action in time are canceled, and the completed tasks are not affected.

Analysis

The focus of this pattern is:

1. In a process, multiple instances of a task can be created. (Task number is known at design time). These instances are independent of each other.
2. At any time, the multiple instance tasks can be cancelled, tasks which have not completed are withdrawn.
3. Any instances which have already completed are unaffected by the cancellation.

In WID, we can use For Each, Event Handler and Terminate to implement this pattern. Mark this as Solution 1.

Typically in business scenario, we need to cancel tasks usually when some criteria achieved, other than at any time. Such as above bank credit card apply process, cancel happens when time out. If the pattern’s requirement 2 softens to "when some criteria achieved", we have "Parallel Human Task" (WID 7.0 new feature) to implement this more graciously. Mark this as Solution 2.

Implementation - Solution 1

"For Each" is configured as below.

1. Section 1 is set to "Parallel", that means human tasks will be created in parallel; if it set to "Sequential", then human tasks will be created in sequence.
2. Section 2 is iteration section. This decides how many human task instances you want to created. We set start from 1 to 3, so finally, there will be 3 task instances created.

Implementation - Solution 2

Configuration for "HumanTask" as below.

1. Section 1 is set to "Parallel", this means will create multiple task instance at once as designed.
2. Section 2 is for potential owners. Set Potential Owners to Group Members, and GroupName is: "cn=S27Group,o=defaultWIMFileBasedRealm". "S27Group" in a pre-defined group in WPS repository, it contains several users. That way, in runtime, for each user in S27Group, one task instance will be created out.
3. Section 3 is configured to set time out rule that means if there’s any tasks which will not complete in 5 minutes, remained uncompleted tasks will be canceled. You can define your own time out rule.
4. Section 4 is configured to set early quit criteria. Above snapshot shows if more than 80% of task owners return true for specific output field, then rest task instances will be canceled and process will move on.

Run on WPS - Solution 1

After process starts, below three tasks are created in parallel. All tasks' status is "Ready".

Complete one task (status changes to "Finished"), and claim one task (status changes to "Claimed") as below.

Then invoke "cancel" operation, uncompleted tasks are all canceled (status changes to "Terminated"), and completed task is not impacted, as below.

Run on WPS - Solution 2

Note: Should pre-define one group (S27Group in this sample) in WPS federate repository.

After process instance starts, three tasks are created in parallel, and status is "Claimed", as below.

Complete the task for usr1. Left other two tasks claimed. After 5 minutes timeout as designed, these two uncompleted tasks are canceled, status changes to "Terminated", as below.

Back to top

Complete multiple instance activity

This pattern requires after canceling multiple instance activity, process can go on to next node. It provides a way to cancel a multiple instance task that has not yet completed at any time during its execution such that any remaining instances are withdrawn and the thread of control is immediately passed to subsequent tasks.

For example, in bank credit card apply process, we have three concurrent instance of final approve task to different person which should be completed in one day. If time out, the tasks whose owner does not take action in time are canceled, and the completed tasks are not affected. Then the process moves to card producing task immediately.

Pattern detail description is here.

Analysis

The focus of this pattern is:

1. In a process, multiple instances of a task can be created. (Task number is known at design time). These instances are independent of each other.
2. At any time, the multiple instance task can be forced to complete, so that tasks which have not completed are withdrawn and the thread of control is passed to subsequent tasks.
3. Any instances which have already completed are unaffected by the cancellation.

Note: This pattern is similar with pattern Cancel Multiple Instance Activity as both of them require canceling multiple instance activity. The difference between them is that this pattern requires thread control is passed to subsequent tasks after multiple instance are canceled.

In WID, we have two similar solutions with pattern Cancel Multiple Instance Activity, just need to add the implementation for subsequent tasks.

Implementation - Solution 1

Main part is the same as pattern Cancel Multiple Instance Activity Solution 1, differences are:

1. Use standalone human task, not inline human task. (As related system API just can work on standalone human task.)
2. Use WPS Human Task Manager APIs to withdraw uncompleted tasks in Java snippet "ForceCompleteRestTasks".

   
System.out.println("[Complete Multiple Instance Task]Enter ForceCompleteRestTasks");
try{
javax.naming.Context initialContext= new javax.naming.InitialContext();
com.ibm.task.api.HumanTaskManagerHome home= 
    (com.ibm.task.api.HumanTaskManagerHome)initialContext.lookup
                ("com/ibm/task/api/HumanTaskManagerHome");
com.ibm.task.api.HumanTaskManager manager= home.create();
com.ibm.task.api.QueryResultSet queryresult = 
    manager.query("DISTINCT TASK.TKIID","(TASK.STATE = 
                TASK.STATE.STATE_CLAIMED OR TASK.STATE = 
                TASK.STATE.STATE_READY) AND (TASK.KIND = 
                TASK.KIND.KIND_PARTICIPATING OR TASK.KIND = 
                TASK.KIND.KIND_HUMAN)",
                                   (String)null,(Integer)null, (java.util.TimeZone)null);
System.out.println("task size : " + queryresult.size());

if (queryresult.size() > 0)
{
  queryresult.first();
  do{
	  com.ibm.task.api.TKIID tkiid = (com.ibm.task.api.TKIID) queryresult.getOID(1);
	  System.out.println("terminate : " + tkiid.toString());
	  manager.terminate(tkiid);
  }while(queryresult.next());
  
}
}catch (Exception e){
System.out.println("exception occured! ");
e.printStackTrace();
}

Note: Just WPS user which has administrator authorization can invoke Human Task Manger API. Detail info about Human Task Manger API is in WPS Information Center.

Implementation - Solution 2

Main part is the same as pattern Cancel Multiple Instance Activity Solution 2, difference is: Add Case1 after parallel HumanTask.

Run on WPS - Solution 1

Execution Steps:

1. After process starts, three tasks are created. All tasks' status is "Ready".
2. Complete one task, claim one task.
3. Invoke "forcecomplete" operation.

Below log is shown in SystemOut.log. Two tasks (one in "Ready" status, one in "Claim" status) will be terminated, while the completed task will not be impacted. Then process goes to Case1.

  
[8/24/10 17:04:27:296 GMT+08:00] 00000051 SystemOut O [Complete Multiple Instance Task]
                                                       Enter ForceCompleteRestTasks
[8/24/10 17:04:27:718 GMT+08:00] 00000051 SystemOut O tasks remained : 2
[8/24/10 17:04:27:718 GMT+08:00] 00000051 SystemOut O terminate 
                                                       : _TKI:a01b012a.a356f291.3aa4af6
                                                                    .f0c21648
[8/24/10 17:04:27:843 GMT+08:00] 00000051 SystemOut O terminate
                                                         : _TKI:a01b012a.a356f291.3aa4af6
                                                                    .f0c21649
[8/24/10 17:04:27:906 GMT+08:00] 00000051 SystemOut O [Complete Multiple Instance Task]
                                                       Enter Case1

Run on WPS - Solution 2

After parallel human task reaches the exit criteria, remained uncompleted tasks are terminated and process enters into Case1.

Most result here is the same as pattern Cancel Multiple Instance Activity Solution 2, except that there will be below log in SystemOut.log to verify after parallel human task, process do go into Case1.

  
[8/24/10 14:03:21:922 GMT+08:00] 00000051 SystemOut O [Complete Multiple Instance Task]
                                                       Enter Case1

Back to top

Conclusion

In this article, we introduce five "basic control flow patterns" and five "cancellation and for completion patterns" with related WID implementation. With those workflow patterns, we can construct simple and basic process with conditional cancel consideration. And we approve that WID can implement all of those patterns easily and graciously.

In following articles, we will introduce other advanced workflow patterns with its WID implementation in detail.

Back to top

Download

Information about download methods

Resources

Learn

• Learn more about the Workflow Patterns Initiative.
  
  
• Access Business Process Management samples.
  
  
• Access WebSphere Process Server Information Center.
  
  
• Read further about pattern detail descriptions.
  
  
• Read further about parallel Split pattern detail descriptions.
  
  
• Read further about parallel synchronization pattern detail descriptions.
  
  
• Read further about exclusive choice pattern detail descriptions.
  
  
• Read further about simple merge pattern detail descriptions.
  
  
• Read further about cancel task pattern detail descriptions.
  
  
• Read further about cancel case pattern detail descriptions.
  
  
• Read further about cancel region pattern detail descriptions.
  
  
• Read further about cancel multiple instance activity pattern detail descriptions.
  
  
• Read further about complete multiple instance activity pattern detail descriptions.
  
  
• Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
  
  
• Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
  
  
• Follow developerWorks on Twitter.
  
  
• Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
  
  

Get products and technologies

• Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
  
  

Discuss

• Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Basic control flow patterns
• Sequence
• Parallel Split
• Synchronization
• Exclusive Choice
• Simple Merge
• Cancellation and force completion patterns
• Cancel Task
• Cancel Case
• Cancel Region
• Cancel Multiple Instance Activity
• Complete multiple instance activity
• Conclusion
• Download
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers