Patterns: Serial and Parallel Processes for Process Choreography and Workflow

Chapter 10. Creating parallel processes 247

Wholesaler A and Wholesaler B are contacted at the same time. The scenario is

as follows:

򐂰 The order clerk places an order for a part number and a quantity.

򐂰 Wholesaler A is contacted for its delivery date.

򐂰 At the same time, Wholesaler B is contacted for its delivery date.

򐂰 Once both wholesalers respond, the system can determine who the best

wholesaler is (that is, which wholesaler can deliver the most quickly).

򐂰 The order is placed with the best wholesaler.

򐂰 After the order is successfully placed, the best wholesaler, confirmation

number and the deliver days are returned to the order clerk via the application

that was used to start the process.

10.3 General design guidelines

All of the design considerations listed in the previous scenario chapter apply to

the Parallel Process scenario as well. By getting the delivery dates from the two

wholesalers in parallel, we are potentially shortening the time it takes to complete

the process.

When the defined business process allows it, having the process manager split

the process into two or more paths of parallel processing is often desirable. For

long-running processes, cycle time reduction is in constant focus for business

executives. Since business processes should support a customer in some way,

shorter cycle time in processes usually equates to an organization being more

responsive to its customer.

10.3.1 Design overview

This scenario is an implementation of the Process-focused Application

Integration::Parallel Process pattern.

For information about the Parallel Process Application pattern, see:

3.4.8, “Parallel Process Application pattern” on page 61

For information about the Parallel Process Runtime pattern, see:

5.1.3, “Parallel Process Runtime pattern” on page 88

For information about the Product mappings of the Parallel Process Runtime

pattern, see:

5.2.3, “Parallel Process Product mappings” on page 98

248 Patterns: Serial and Parallel Processes

This scenario is an implementation of Stage One of the ITSO Electronics

integration project. For information about the use case and actors used in Stage

One, see:

6.2.1, “Stage One: Internal ordering on demand” on page 110

10.3.2 Design considerations

The following design decisions need to be made when considering whether to

use the Serial or Parallel Process pattern.

How much parallelism?

In our scenario, when the decision to contact the two wholesalers in parallel was

made, it was relatively easy to implement. Splitting the workflow into two parallel

paths is quite common and does not introduce much complexity.

However, consider a scenario that the logical model (that is, the to-be business

process) dictates that the process can run in, say, 10 parallel paths. Should the

implementation of the process support the 10 parallel paths?

Similar to a data model, there should be some level of

normalization of the

process that needs to occur for both performance and complexity reasons. In an

automated system process (either a short or long-running process), if there is no

urgency to have the process complete as quickly as possible, the process should

be normalized into some serial and some parallel processing paths. This is easy

to accomplish when there isn’t an urgency to complete the process as quickly as

possible.

If there is an urgency to complete the process quickly, then consideration for the

performance and complexity of implementing a process this way needs to be

considered.

Performance

From a performance point of view, the modeler must understand what resources

are required when the parallel processing occurs. You should ask yourself the

following questions:

򐂰 If more than one of the activities executing in parallel are requesting the same

resource, have we just created a bottle-neck in the process?

򐂰 Can the requested resource handle all of the requests from this process at

once?

򐂰 What if there are more than one of these process instances running at the

same time? Have we overloaded the resources we are calling with too many

concurrent requests?