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
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
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
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
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
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
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