Implementing advanced workflow patterns in WebSphere Integration Developer and WebSphere Process Server, Part 1: Basic control flow patterns and cancellation and force completion patterns

The Workflow Patterns Initiative is widely used or referenced when enterprises want to model their workflow. Its 43 workflow patterns post a big challenge to all kinds of BPEL engines.

WebSphere Process Server is a powerful business process automation engine with high performance. Customers can implement their workflow patterns easily with WebSphere Process Server and WebSphere Integrated Developer. Compared with other BPEL engine products, WebSphere Integrated Developer v7.0 and WebSphere Process Server v7.0 can implement all 43 patterns, but can also implement them easily and graciously.

Share:

Jing Wen Cui, Software Engineer, IBM China

Jing Wen Cui は、3 年以上、WebSphere Process Server のテストに取り組んでいます。彼はワークフロー、BPEL、および関連する WebSphere 製品についても熟知しています。



Ying Ji Sun, Staff Software Engineer, IBM China

Ying Ji Sun は現在、WebSphere Process Server SWAT チームに参加しています。以前は WebSphere Enterprise Service Bus 機能検証テストに取り組んでいた彼は、Web サービスおよび WebSphere Enterprise Service Bus を話題に取り上げた developerWorks 記事もいくつか書いています。



Yu Jie Gu, Staff Software Engineer, IBM China

Yu Jie Gu は現在、WebSphere Process Server Level 3 サポート・チームのメンバーです。



18 October 2010

Also available in Japanese

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 v7.0 release. Those patterns post a big challenge to all kinds of BPEL engines. It's difficult to support each one. One BPEL engine that can support those patterns well should gain more customers as its power.

WebSphere Process Server is a powerful business process automated engine with high performance that provides runtime support for all kinds of processes. You can use WebSphere Integrated Developer, as the development tool for applications that run on WebSphere Process Server, to model your workflow visually. You need only drag-and-drop without any coding. The executable BPEL code is generated automatically. Compared with other BPEL engine products, you can implement the 43 patterns with WebSphere Integrated Developer v7.0 and WebSphere Process Server v7.0 more easily and graciously.

Part 1 of this article series introduces two categories of patterns: Basic Control Flow Patterns and Cancellation and Force Completion Patterns.


Basic control flow patterns

This category has five basic patterns:

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

All of these patterns are fundamental workflow patterns. They're widely used in real customer business scenarios. With them, you can implement a basic and simple workflow.


Sequence

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

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

Another example is an online train ticket system. The tasks Choose train ticket, pay online, print ticket should run one after another. This "one after another" scenario also fits in the Sequence pattern.

Pattern detail description is here.

Analysis

This pattern has the following focus:

  • Task order is defined in the process design period. In the process, one task is done first, and another task is done next, as predefined in the model phase.
  • One task is enabled after the preceding task completed. No conditions are required.

In WebSphere Integrated Developer, tasks are run in sequence by default.

Implementation

Figure 1. Sequence Implementation
Sequence Implementation

Case2 is run right after Case1.

Run on WebSphere Process Server

Listing 1. Sequence Log
[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

Parallel Split

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

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

Analysis

This pattern has the following focus:

  • The process splits into two or more branches at a point.
  • Those split branches are run concurrently. And they might or might not be resynchronized at some future time.
  • All branches are defined in process model phase.

In WebSphere Integrated Developer, you can use Parallel Scope for this pattern easily.

Implementation

Figure 2. Parallel Split Implementation
Parallel Split Implementation

Case1, Case2, Case3 are run in parallel.

Run on WebSphere Process Server

Listing 2. Parallel Split Log
[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, three branches run in sequence in the same thread because of a database limitation.


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 reconverging those parallel branches that are created by using the Parallel Split construct earlier in the process model. The thread of control is passed to the task immediately following the synchronizer after all of the incoming branches are completed.

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

Pattern detail description is here.

Analysis

This pattern has the following focus:

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

In WebSphere Integrated Developer, you use Parallel Scope to start two or more branches concurrently, and use link to merge them into one subsequent branch.

Implementation

Figure 3. Synchronization Implementation
Synchronization Implementation

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

Run on WebSphere Process Server

Listing 3. Synchronization Log
[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

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 last possible moment at run time.

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

Pattern detail description is here.

Analysis

This pattern has the following focus:

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

WebSphere Integrated Developer has two solutions for this pattern:

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

Implementation

Figure 4. Exclusive Choice Implementation
Exclusive Choice 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 WebSphere Process Server

In either solution, process just runs into Case1.

Listing 4. Exclusive Choice Log
[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

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 a bank credit card application process, after either branch (card producing, request fail or 2nd review) is run according to different credit result task's result, notify customer task is needed in common. Here the Simple Merge pattern is needed.

Pattern detail description is here.

Analysis

This pattern has the following focus:

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

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

In WebSphere Integrated Developer, you use Choice to implement this.

Implementation

Figure 5. Simple Merge Implementation
Simple Merge 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 WebSphere Process Server

Listing 5. Simple Merge Log
[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

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.


Cancel Task

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

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

Another example is a physical damage insurance claim on an automobile, where access to the damage task is taken by two insurance assessors. After the first assessor completes an assessment, the second assessment needs to be canceled.

Patten detail description is here.

Analysis

This pattern has the following focus:

  • An enabled task is withdrawn before it begins execution.
  • If the task has started, it is disabled.
  • The currently running instance is halted and removed.

Two situations can occur if tasks are performed in parallel or in sequence.

The bank example is a sequence case. In WebSphere Integrated Developer, you can use Event Handler and Terminate to implement it. You mark it as Solution 1.

The automobile insurance case is a parallel case. In WebSphere Integrated Developer, you can use Throw, Fault Handler and Terminate to implement it. Mark it as Solution 2.

Note: When you use the event handler, configure the correlation set ID.

Implementation - Solution 1

Figure 6. Cancel Task Implementation Solution 1
Cancel Task Implementation Solution 1

Task1 and Task2 are performed in sequence. When Task1 is running, the CancelTask can end the task and the process instance. Task2 is not run obviously.

Implementation - Solution 2

Figure 7. Cancel Task Implementation Solution 2
Cancel Task Implementation Solution 2

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

Run on WebSphere Process Server - Solution 1

After process starts, before Task1 completion, start "CancelTask". That way Task1 and the process instance are ended (verified in the log in Listing 6).

Listing 6. Cancel Task Log Solution 1
[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 ended.

Run on WebSphere Process Server - Solution 2

Execution Steps:

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

Then Task2 is canceled, and the process instance is ended (verified in the log in Listing 7).

Listing 7. Cancel Task Log Solution 2
[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

Cancel Case

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

For example, in a bank credit card application 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, the process instance should be marked as unsuccessful for future audit.

Pattern detail description is here.

Analysis

This pattern has the following focus:

  • Complete process instance is removed.
  • All process-related tasks, currently running or enabled, should be canceled.
  • All subprocesses will not be run either.
  • The process instance is recorded as having completed unsuccessfully.

In WebSphere Integrated Developer, you use Event Handler and Terminate node to implement this pattern.

Implementation

Figure 8. Cancel Case Implementation
Cancel Case Implementation

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

Note: Set a subprocess to "bind the life cycle to the starting business process." This way, ending the action that is performed in the parent process can also end its subprocesses. For information about the subprocess lifecycle, see the WebSphere Process Server 7.0 information center.

Run on WebSphere Process Server

Execution steps:

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

Then, the whole process, including all tasks and subprocesses, is ended (verified in the following log).

Listing 8. Cancel Case 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 ended.


Cancel Region

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

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

Pattern detail description is here.

Analysis

This pattern has the following focus:

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

WebSphere Integrated Developer partially supports this pattern. The tasks that can be canceled together should be in the same scope. You can use the Nesting Scope, Event Handler, Throw, and Fault Handler to implement this pattern.

Implementation

Figure 9. Cancel Region Implementation
Cancel Region Implementation

Task1 and Task2 are generated concurrently, when "CancelRegion" is started, all incompleted tasks in the scope will be ended. And, the process goes to the AlternativeTask and Next activity.

Run on WebSphere Process Server

Execution Steps:

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

Then, Task1 (running), Task2 (enabled), Task3 (not enabled) are withdrawn together. AltenativeTask is run. After that, process goes to Next activity (verified in the log in Listing 9).

Listing 9. Cancel Region 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

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 canceled. However, any instances that have completed are unaffected by the cancellation.

For example, the bank credit card application process has three concurrent instances of the final approve task to different people that should be completed in one day. If a time-out occurs, the tasks whose owner doesn’t take action in time are canceled, and the completed tasks are not affected.

Analysis

This pattern has the following focus:

  • In a process, multiple instances of a task can be created. (The task number is known at design time.) These instances are independent of each other.
  • At any time, the multiple instance tasks can be canceled, and tasks that have not completed are withdrawn.
  • Any instances that are completed are unaffected by the cancellation.

In WebSphere Integrated Developer, you can use For Each, Event Handler, and Terminate to implement this pattern. Mark this as Solution 1.

Typically in a business scenario, you need to cancel tasks usually when some criteria achieved, other than at any time. For example, for the previous bank credit card application process, cancel happens when a time-out occurs. If the pattern’s Requirement 2 softens to "when some criteria is achieved", you have "Parallel Human Task" (WebSphere Integrated Developer 7.0 new feature) to implement this more graciously. Mark this as Solution 2.

Implementation - Solution 1

Figure 10. Cancel Multiple Instance Activity Implementation Solution1
Cancel Multiple Instance Activity Implementation Solution1

"For Each" is configured as shown in Figure 11.

Figure 11. For Each Configuration
For Each Configuration
  • Section 1 is set to "Parallel", which means human tasks are created in parallel; if it set to "Sequential", human tasks are created in sequence.
  • Section 2 is an iteration section, which determines how many human task instances you want to create. We set start with 1 - 3 so that three task instances created.

Implementation - Solution 2

Figure 12. Cancel Multiple Instance Activity Implementation Solution2
Cancel Multiple Instance Activity Implementation Solution2

Configuration for "HumanTask" as shown in Figure 13.

Figure 13. Parallel Human Task Configuration
Parallel Human Task Configuration
  • Section 1 is set to "Parallel", which means it creates multiple task instances at one time as designed.
  • 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 the WebSphere Process Server repository, it contains several users. That way, in run time, for each user in S27Group, one task instance is created out.
  • Section 3 is configured to set a time-out rule, which means if any tasks are not completed in 5 minutes, the remaining incompleted tasks are canceled. You can define your own time-out rule.
  • Section 4 is configured to set early quit criteria. Figure 13 shows that if more than 80% of task owners return true for specific output field, rest task instances are canceled, and the process moves on.

Run on WebSphere Process Server - Solution 1

After process starts, the following three tasks are created in parallel. The status for all tasks is "Ready".

Figure 14. Solution 1: Task Created
Solution 1: Task Created

Complete one task (status changes to "Finished"), and claim one task (status changes to "Claimed") as shown in Figure 15.

Figure 15. Solution 1: Task Claimed/Completed
Solution 1: Task Claimed/Completed

Then, start the "cancel" operation. Incompleted tasks are canceled (status changes to "Terminated"), and completed tasks are not affected (Figure 16).

Figure 16. Solution 1: Incompleted Tasks Canceled
Solution 1: Uncompleted Tasks Canceled

Run on WebSphere Process Server - Solution 2

Note: Predefine one group (S27Group in this sample) in the WebSphere Process Server federate repository.

After the process instance starts, three tasks are created in parallel, and the status is "Claimed" (Figure 17).

Figure 17. Solution 2: Tasks Claimed
Solution 2: Tasks Claimed

Complete the task for usr1. Leave the other two tasks as claimed. After a 5-minute timeout as designed, these two incompleted tasks are canceled, and the status changes to "Terminated" (Figure 18).

Figure 18. Solution 2: Task Canceled
Solution 2: Task Canceled

Complete multiple instance activity

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

For example, a bank credit card application process has three concurrent instances of the final approve task for different people that should be completed in one day. If a time-out occurs, the tasks whose owner does not take action in time are canceled, and the completed tasks are not affected. Then, the process moves to the card producing task immediately.

Pattern detail description is here.

Analysis

This pattern has the following focus:

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

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

WebSphere Integrated Developer has two similar solutions with the Cancel Multiple Instance Activity pattern, where you need to add the implementation for subsequent tasks.

Implementation - Solution 1

Figure 19. Complete Multiple Instance Activity Implementation Solution1
Complete Multiple Instance Activity Implementation Solution1

The main part is the same as the Cancel Multiple Instance Activity Solution 1 pattern with the following differences:

  • Use a stand-alone human task, not an inline human task. (Related system APIs can work only on a stand-alone human task.)
  • Use WebSphere Process Server Human Task Manager APIs to withdraw incompleted tasks in the Java snippet "ForceCompleteRestTasks".
Listing 10. ForceCompleteRestTasks Code
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: Only the WebSphere Process Server user that has administrator authorization can start the Human Task Manger API. For information about the Human Task Manger API, see the WebSphere Process Server Information Center.

Implementation - Solution 2

Figure 20. Complete Multiple Instance Activity Implementation Solution2
Complete Multiple Instance Activity Implementation Solution2

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

Run on WebSphere Process Server - 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. Start the "forcecomplete" operation.

The output in Listing 11 is shown in the SystemOut.log file. Two tasks (one in "Ready" status, one in "Claim" status) are ended, while the completed task is not affected. Then, the process goes to Case1.

Listing 11. Complete Multiple Instance Activity Solution1 Log
[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 WebSphere Process Server - Solution 2

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

Most results here are the same as the Cancel Multiple Instance Activity Solution 2 pattern. The exception is the output that is shown in the SystemOut.log file (Listing 12 ) to verify that, after the parallel human task, the process goes into Case1.

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

Conclusion

This article introduced five basic control flow patterns and five cancellation and for completion patterns with a related WebSphere Integrated Developer implementation. With those workflow patterns, you can construct simple and basic process with conditional cancel consideration. And, WebSphere Integrated Developer can implement all of these patterns easily and graciously.

The following articles introduce other advanced workflow patterns with WebSphere Integrated Developer.


Download

DescriptionNameSize
PI files for this articlePart1PI.zip255KB

Resources

Learn

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 and explore the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services, WebSphere
ArticleID=551309
ArticleTitle=Implementing advanced workflow patterns in WebSphere Integration Developer and WebSphere Process Server, Part 1: Basic control flow patterns and cancellation and force completion patterns
publish-date=10182010