Patterns: Serial and Parallel Processes for Process Choreography and Workflow

358 Patterns: Serial and Parallel Processes

13.1 Business scenario

From a business point of view, this scenario of using a second process manager

is identical to the scenario that introduced parallel processing. The order clerk

places an order specifying the part number and the quantity. An immediate

response is received indicating which wholesaler the order was placed with,

along with a confirmation number and a delivery date.

Behind the scenes, the user is unaware that two process managers are being

used. This scenario is implemented as a WebSphere MQ Workflow process that

invokes a WebSphere Process Choreographer process as a single UPES

activity. For illustrative purposes, this chapter also implements a WebSphere MQ

Workflow process invoking the WebSphere Process Choreographer process.

This scenario is different than the one described in “An alternative solution” on

page 273. The alternative solution has one process manager spawn another

process manager as the process in the first process manager ends. The process

is started with a

fire and forget mentality, or in other words, an asynchronous

process invocation. In this scenario, we are embedding a process run in a

second process manager, with a process running in the first process manager.

The form of sub-process is run synchronously.

It can be speculated that since WebSphere MQ Workflow is a mature product in

production at many sites around the world, an existing WebSphere MQ Workflow

customer may consider using WebSphere Process Choreographer to build a

non-interruptible process within an existing WebSphere MQ Workflow process.

Several UPES activities may be taken out of a current WebSphere MQ Workflow

process template and replaced with a single activity that calls the WebSphere

Process Choreographer non-interruptible process. This could be the first step to

migrating towards a WebSphere Process Choreographer runtime.

13.2 Business process model

The swimlane diagram to depict this process is shown in Figure 13-1 on

page 359.

Chapter 13. Process manager interoperability 359

Figure 13-1 Calling a another process manager swimlane diagram

This scenario executes the following business process:

򐂰 The order clerk places an order specifying the part number and quantity and a

process is started in WebSphere MQ Workflow.

򐂰 The first activity in WebSphere MQ Workflow is a UPES activity that starts a

non-interruptible process in WebSphere Process Choreographer.

򐂰 In a parallel fashion, requests are sent to Wholesaler A and Wholesaler B to

provide their delivery dates. Once both dates are received, the WebSphere

Process Choreographer process ends and control is passed back to

WebSphere MQ Workflow.

򐂰 The best wholesaler is determined by which wholesaler can supply the part

the most quickly.

򐂰 The order is placed with the best wholesaler.

򐂰 The clerk who initiated the process receives a confirmation that the order was

placed, This confirmation includes the name of the wholesaler and the

delivery date.

To show the reverse interoperability, we will call the complete WebSphere MQ

Workflow process described in this section from a WebSphere Process

Choreographer process.

Retail

Department

Wholesale

Department A

System

Confirm

order status,

best

wholesaler

and delivery

date.

Wholesale

Department B

System

Get

delivery

date.

Order

Part

Get

delivery

date from

Wholesaler A.

Get

delivery

date from

Wholesaler B.

Execute in Parallel

Determine the

need to place an

order. Order clerk

supplies the part

number and the

quantity to be

ordered.

Get

delivery

date.

B is Best

A is Best

Place Order

with

Wholesaler B.

Place Order

with

Wholesaler A.

Process

Automation

Order

Part

Determine

Best

Wholesaler.

Second

Process

Manager