Patterns: Serial and Parallel Processes for Process Choreography and Workflow

340 Patterns: Serial and Parallel Processes

Figure 12-21 Completion of a block with an event activity

Wait for a five minute period and then click Refresh List in the Web application.

The remaining process instance is removed from the table. This occurs because

the event activity has expired. A work item is now be generated to follow up the

reason for the expiration. Once you complete and claim this work item, the event

reappears in the Web application.

Send an event to the process instance and complete the notify process starter

work item to complete the process instance.

12.5 WebSphere MQ Workflow guidelines

This section describes how to implement the Parallel Process Workflow variation

pattern with events and compensation. It also describes how to create a process

that meets the requirements set by the ITSO Electronics business process

model. It uses the Runtime pattern and Product mappings described in “Parallel

Process: Workflow variation Product mappings” on page 100 for WebSphere MQ

Workflow.

You can download the completed process and run it in WebSphere MQ Workflow

or view it in WebSphere Business Integration Workbench. See “Sample

scenarios setup” on page 398.

12.5.1 Design guidelines

This section discusses WebSphere MQ Workflow specific-design guidelines

when creating a process that conforms to the Parallel Process Workflow variation

pattern with events and compensation.

Chapter 12. Creating processes with events and compensation 341

Process overview

Figure 12-22 shows an overview of the process, as modeled in WebSphere

Business Integration Workbench.

Figure 12-22 Process overview

The process has the following characteristics:

򐂰 Blocks with loop conditions

򐂰 Parallel execution paths

򐂰 Human interaction activities

򐂰 Automated activities

Staffing and organization models

This scenario builds on the organization model defined in the previous scenario.

In addition to the RetailManager and RetailStaff roles, two new roles are needed

for the Retail organization:

򐂰

ReceivingStaff, responsible for receiving deliveries of goods

򐂰

ReceivingManager, responsible for following up on delayed orders with the

responsible Wholesaler

Process and task interface definition

This process uses different process input and output data structures from the

previous scenarios. The process input data structure needs the name of two part

numbers and two quantities to order. The process output returns both

confirmation numbers from these orders. Additionally, the Wholesale data

structure (used as a placeholder for storing data required by multiple tasks within

the process) needs to store both confirmation codes and whether an item was

delivered.

342 Patterns: Serial and Parallel Processes

So as not to interfere with the previous scenarios, we have created new data

structures called OrderInputEvents, OrderOutputEvents, and WholesaleEvents.

The block activities require their own data structure. We define this data structure

as Delivery. It contains the part number and confirmation code of the item we

are waiting to be delivered, along with a delivered flag that is set to Y when the

item is received.

All data structures new to this scenario are shown in Figure 12-23.

Figure 12-23 New data structures added to the repository

Blocks and loops

It is necessary in this scenario for a portion of the process to loop until a certain

condition is met. WebSphere MQ Workflow supports this concept by using

blocks.

To create the looping functionality using blocks, we use the following guidelines:

򐂰 Create two processes, (1) containing the main process and (2) containing the

tasks and data mappings that are required in the loop portion of the process.

򐂰 Define the second process as a block.

򐂰 Add a new Process activity to the first process, and set it to the name of the

block.