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

Get Patterns: Serial and Parallel Processes for Process Choreography and Workflow now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.