Introduction

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 Workflow Patterns Initiative (WPI) 43 patterns with the latest WID v7.0 and WPS v7.0 more easily and graciously.

We have previously the 34 patterns with implementation in parts 1, 2 and 3. In part 4 of this article, the last three categories patterns 1-State-based Patterns, 2-Termination Patterns and 3-Trigger Patterns will be introduced in detail.

Back to top

State-based patterns

There are 5 basic patterns in this category, including:

1. Deferred choice
2. Interleaved parallel routing
3. Milestone
4. Critical section
5. Interleaved routing

With those patterns, customer can implement most kinds of state based process easily.

Back to top

Deferred choice

This pattern requires the ability to defer the moment of choice in a process. And decision is based on factors external to the process instance (e.g. incoming messages, environment data, resource availability, timeouts etc.)

For example, in bank credit card apply process, after applicant submits request, human task credit check is performed whose result determines which branch to take afterwards. Read the complete pattern detail description here.

Analysis

The focus of this pattern is:

1. In a process, there is a point for external information to decide following branch.
2. External information includes incoming messages, environment data, resource availability, timeouts etc.
3. After the decision is made, execution alternatives in branches other than the one selected are withdrawn.

In WID, we can use human task and choice to implement this.

Implementation

Which case to go is decided by human task node "InputDeferredChoice". If field2 is 1, process goes into Case1; if field2 is 2, process goes into Case2; if field2 is other number, process goes into Case3.

Run on WebSphere Process Server

If input "1" is a human task, the process will run into Case1 (verified in the below log).

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

Back to top

Interleaved parallel routing

This pattern requires relaxing the strict ordering that a process usually imposes over a set of tasks. All tasks should be executed all, but only one task can be executed at the same time.

For example, in dispatching order process of an online store, pick goods, pack goods and prepare invoice tasks must be completed. The pick goods task must be done before the pack goods task. The prepare invoice task can occur at any time. Only one of these tasks can be done at any time for a given order. Full pattern detail description is located here.

Analysis

The focus of this pattern is:

1. A set of tasks has a partial ordering defined.
2. Each task in the task set must be executed once and they can be completed in any order that accords with the partial order.
3. Just one task can be executing at the same time.

In WID, we can use Isolated Scope and Fork Gateway to implement this pattern easily.

Implementation

Task C should be executed after Task A, that is the defined partial ordering. After Fork Gateway, two lines of tasks are started, Wait1 and Wait2 controls which task (Task A or Task B) be executed firstly. At the end of the process, the process will go to "PrintResult" activity.

Note: Each scope should be defined as "isolated" (in Property Detail tab). It ensures those isolated scopes are executed in sequence actually in runtime. That means at the same time, just one isolated scope can be executing.

Run on WebSphere Process Server

[9/6/10 15:49:20:000 GMT+08:00] 00000097 SystemOut     O 
                                            [run InterleavedParallelRouting] and the 
sequence is : [runHumanTaskA] ->  [runHumanTaskB] ->  [runHumanTaskC] ->  End.           

Back to top

Milestone

This pattern provides a mechanism for supporting the conditional execution of a task or sub-process (possibly on a repeated basis) where the process instance is in a given state. As such, it provides a means of synchronizing two distinct branches of a process instance, such that one branch cannot proceed unless the other branch has reached a specified state.

For example, in bank account request process, before bank staff issue request starts, customer can update information in the request. Once issue request completed, customer can not update information in the request any more. The full pattern detail description is located here.

Analysis

The focus of this pattern is:

1. One task is only enabled when the process instance is in a specific state.
2. The state is assumed to be a specific execution point (also known as a milestone) in the process model.
3. When the milestone is reached, the nominated task can be enabled.
4. If the process instance has progressed beyond this state, then the task cannot be enabled now or at any future time

In WID, we use Fork, Join and Split Gateway with conditioned link in GeneralizedFlow to implement this pattern.

Implementation

Task Trigger is the milestone of Task E. If Task Trigger is enabled and Task DeferChoice is uncompleted, branch Task E can be enabled and roll back to Task D. Use variable "istri" to mark Task Trigger is enabled or not; variable "EorF" to control which branch (TaskE or TaskF) to taken after Task DeferChoice.

Note:

1. In runtime, if the Task Trigger is enabled after Task DeferChoice instance been created, available choice (which is passed into DeferChoice task as input parameter) will not be refreshed anyway.
2. Error path is added after DeferChoice in case user chooses Task E when Trigger is disabled which is not allowed. That way, one new DerferChoice instance will be created for user’s correct choice.

Run on WebSphere Process Server

Execution Steps:

1. Start the process instance
2. Claim Task Trigger
3. Complete Task DeferChoice (output is "E")
4. Complete Task Trigger (output is "false")
5. Complete Task DeferChoice (output is "F")

       
[9/27/10 16:32:07:109 GMT+08:00] 00000054 SystemOut     O Enter Start
[9/27/10 16:32:07:109 GMT+08:00] 00000054 SystemOut     O Enter D
[9/27/10 16:32:07:109 GMT+08:00] 00000054 SystemOut     O Enter A
[9/27/10 16:32:45:500 GMT+08:00] 00000054 SystemOut     O Enter E
[9/27/10 16:32:45:500 GMT+08:00] 00000054 SystemOut     O Enter D
[9/27/10 16:33:17:609 GMT+08:00] 00000054 SystemOut     O Enter F
[9/27/10 16:33:17:609 GMT+08:00] 00000054 SystemOut     O Enter G
[9/27/10 16:33:29:703 GMT+08:00] 00000054 SystemOut     O Enter C
[9/27/10 16:33:29:718 GMT+08:00] 00000054 SystemOut     O Enter End 

Back to top

Critical section

This pattern provides a means of limiting two or more sections of a process from executing concurrently. It is necessary if tasks within this section require exclusive access to a common resource (either data or a physical resource) necessary for a task to be completed.

For example, in the holiday booking process, both the take-deposit and insurance-payment tasks require the exclusive use of the credit-card-processing machine. Consequently only one of them can execute at any given time. Read further about the attern detail description here.

Analysis

The focus of this pattern is:

1. Two or more connected sub graphs of a process model are identified as "critical sections".
2. At runtime for a given process instance, only tasks in one of these "critical sections" can be active at any given time.

In WID, we can use WhileLoop with defined token variable to implement this.

Implementation

The scope in each path is the defined “critical sections”. Once one path enters the scope, it will hold the token variable till completed. Another path will keeps waiting and will not be able to execute the critical sections till the token is released.

Run on WebSphere Process Server

Execution Steps:

1. Start the process instance
2. Complete HumanTask1
3. Complete HumanTask
4. Complete HumanTask3
5. Complete HumanTask2

              
[9/6/10 18:05:20:765 GMT+08:00] 00000071 SystemOut     O Process Starts
[9/6/10 18:05:37:312 GMT+08:00] 00000075 SystemOut     O Process2 starts
[9/6/10 18:05:37:375 GMT+08:00] 00000075 SystemOut     O Run into Critical Section 2 
                                                                    : true
[9/6/10 18:05:49:687 GMT+08:00] 00000075 SystemOut     O Process1 starts
[9/6/10 18:05:49:703 GMT+08:00] 00000075 SystemOut     O Process1 is waiting
[9/6/10 18:05:54:953 GMT+08:00] 00000045 SystemOut     O Process1 is waiting
[9/6/10 18:06:00:000 GMT+08:00] 00000045 SystemOut     O Process1 is waiting
[9/6/10 18:06:05:031 GMT+08:00] 00000044 SystemOut     O Process1 is waiting
[9/6/10 18:06:05:109 GMT+08:00] 00000075 SystemOut     O Process2 finished
[9/6/10 18:06:05:109 GMT+08:00] 00000075 SystemOut     O Process2 release the token
[9/6/10 18:06:10:062 GMT+08:00] 00000044 SystemOut     O Run into Critical Section 1 
                                                                    : true
[9/6/10 18:06:24:984 GMT+08:00] 00000075 SystemOut     O Process1 finished
[9/6/10 18:06:24:984 GMT+08:00] 00000075 SystemOut     O Process1 release the token
[9/6/10 18:06:24:984 GMT+08:00] 00000075 SystemOut     O All Processes Finished 

Back to top

Interleaved routing

This pattern allows a sequence of tasks to be executed in any order, but no two tasks can be executed at the same time.

For example, the check-oil, test-feeder, examine-main-unit and review-warranty tasks all need to be undertaken as part of the machine-service process. Only one of them can be undertaken at a time; however they can be executed in any order.

Note: This pattern is similar to pattern Interleaved Parallel Routing. Difference is that pattern Interleaved Parallel Routing has partial ordering restriction, while this pattern does not have any ordering restriction and allows a sequence of tasks to be executed in any order.

Full Pattern detail description is located here.

Analysis

The focus of this pattern is:

1. Each member of a set of tasks must be executed once.
2. Tasks can be executed in any order but no two tasks can be executed at the same time.
3. Once all of the tasks have completed, the next task in the process can be initiated.

In WID, we use Fork Gateway and WhileLoop with a token variable to implement this.

Implementation

Branch1, Branch2 and Branch3 are enabled together, based on the execution order which is defined in the input business data, Case1, Case2 and Case3 will be executed accordingly. When one case is executing (it holds the token), other uncompleted branches are waiting till the token is released.

Run on WebSphere Process Server

          
[9/7/10 9:39:41:890 GMT+08:00] 0000007b SystemOut     O process starts
[9/7/10 9:39:41:890 GMT+08:00] 0000007b SystemOut     O branch2 is ready
[9/7/10 9:39:41:921 GMT+08:00] 0000007b SystemOut     O branch1 is ready
[9/7/10 9:39:41:921 GMT+08:00] 0000007b SystemOut     O branch3 is ready
[9/7/10 9:39:42:015 GMT+08:00] 0000007b SystemOut     O branch2 is waiting
[9/7/10 9:39:42:031 GMT+08:00] 0000007b SystemOut     O Case1 finish
[9/7/10 9:39:42:046 GMT+08:00] 0000007b SystemOut     O branch3 is waiting
[9/7/10 9:39:44:250 GMT+08:00] 00000044 SystemOut     O Case2 finish
[9/7/10 9:39:44:468 GMT+08:00] 00000045 SystemOut     O Case3 finish
[9/7/10 9:39:44:468 GMT+08:00] 00000045 SystemOut     O process completes

Back to top

Termination patterns

There are 2 patterns in this category, including:

1. Implicit Termination
2. Explicit Termination

Those patterns are widely used when a workflow is considered to be completed. They provide way to terminate a business instance implicitly or explicitly.

Implicit termination

This pattern requires a given process (or sub-process) instance should terminate when there are no remaining work items that are able to be done and the process instance is not in deadlock. That provides a way to determine the process instance has been completed successfully. It’s a very common requirement in all kinds of process.

For example, in bank credit card apply process; after all tasks are completed as designed, the whole process instance should be completed successfully. Read further about the patten detail description here.

Analysis

The focus of this pattern is:

1. Process instance should terminate when there are no remaining work items.
2. The process is marked completed successfully

WID supports this by default. When work items in one process have all completed as designed, the process instance is completed successfully.

Implementation

Two branches are performed in sequence. After all nodes (NodeA~NodeE) completed, the process are terminated and marked as completed successfully.

Run on WebSphere Process Server

Execution Steps:

1. Start the process instance.
2. Complete human task NodeB, NodeC, NodeD, NodeE in order.

Then the process instance are terminated, and marked as "Finished" (verified in below picture) which means completed successfully.

Note: By default, process instance will be removed if it is completed successfully. Need to configure "Automatically delete the process after completion" (in the process property detail tab) to "NO". That way, you can check the successfully finished process instance.

Back to top

Explicit termination

This pattern requires a given process (or sub-process) instance should terminate when it reaches a nominated state. Usually it is a specific end node. When this end node is reached, any remaining work in the process instance is cancelled. As a result, the overall process instance is recorded as having completed successfully. Read about this pattern description in detail here.

Analysis

The focus of this pattern is:

1. Given process instance is terminated when it reaches a specific end node.
2. Any remaining work in the process instance is cancelled.
3. Overall process instance is recorded as having completed successfully

In WID, we can use Throw and Fault Handler to implement this pattern easily.

Implementation

After the process instance starts, human task Task1 is created. At the same time, Choice will be made to take which branch. If it turns into 1st branch, user-defined exception will be throw, fault handler be enabled, afterwards the process instance will be terminated (marked as "Finished"), and its sub instance, human task instance "Task1" be terminated also.

Run on WebSphere Process Server

After process instance starts, if input id set to "000", choice will go into 1st branch, and we receive:

1. Process instance be terminated, as below.

2. Sub process instance (Human task instance in this example) be terminated also, as below.

Back to top

Trigger Patterns

There are two patterns in this category, including:

1. Transient trigger
2. Persistent trigger

These two patterns are used when external signals are required to start certain tasks. They provide a way to deal with transient and persistent triggers.

Back to top

Transient trigger

This pattern requires task instance can be triggered by a signal from another part of the process or from the external environment. Most important, these triggers are transient in nature and are lost if not acted on immediately by the receiving task.

For example, should start the Handle overflow task immediately when dam capacity full signal is received. If that task can not be performed immediately, the trigger is invalid and be irrevocably lost. The full pattern detail description is located here.

Analysis

The focus of this pattern is:

1. Task instance can be triggered by a signal.
2. The signal is transient by nature.
3. If the receiving task can’t be triggered immediately, the signal will be lost.

In WID, we can use a specific business object and Event Handler to implement this pattern.

Implementation

The specific business object (TransientTrigger) is to hold the transient trigger information, especially the trigger fire time. Seen in below picture. When trigger event comes with this business object, process will compare the current time with fire time which is held by TransientTrigger, if the current time – fire time >= 100ms, means the trigger expired, just drop the trigger; or else, trigger is active, Case 2 be executed.

Back to top

Persistent trigger

This pattern requires task instance can be triggered by a signal from another part of the process or from the external environment. Most important, these triggers are persistent in form and are retained by the process until they can be acted on by the receiving task

Note: This pattern is similar with pattern Transient Trigger. Difference is that pattern Transient Trigger requires trigger is transient by nature, if receiving task can’t be triggered immediately, the signal will be lost. While this pattern requires trigger is persistent, no strict trigger time restriction for receiving task which can be initiated either immediately (if it already has received the thread of control) or at some future time.

The complete pattern detail description is here.

Analysis

The focus of this pattern is:

1. Task instance can be triggered by a signal.
2. The signal is persistent in form.
3. The receiving task can be initiated either immediately or at some future time.

In WID, we can use Event Handler to implement this pattern.

Implementation

After start process instance, we run into Case1, where if we get a trigger invoke (FirePerTrigger), it will enable event handler. Case2 will be executed.

Back to top

Conclusion

In this article, we introduce five "State-based patterns", two "termination patterns" and two "trigger patterns" with relation to WID implementations. With those workflow patterns, we can add some advance control over the business process. And we approve that WID can implement all of those patterns easily and graciously.

Back to top

Download

Information about download methods

Resources

• Learn more about the Workflow Patterns Initiative.
  
  
• Access Business Process Management samples.
  
  
• Access WebSphere Process Server Information Center.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Introduction
• State-based patterns
• Deferred choice
• Interleaved parallel routing
• Milestone
• Critical section
• Interleaved routing
• Termination patterns
• Explicit termination
• Trigger Patterns
• Transient trigger
• Persistent trigger
• 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