Patterns: Serial and Parallel Processes for Process Choreography and Workflow

362 Patterns: Serial and Parallel Processes

13.4 WebSphere MQ Workflow invoking Process

Choreographer

This section describes how to design an MQ Workflow process that invokes a

Process Choreographer process. It follows the normal phases of design,

development, and runtime guidelines.

You should read the design section to get a general understanding of how this

interoperability will work. The development section requires hands-on knowledge

of both WebSphere MQ Workflow Buildtime and WebSphere Studio Application

Developer Integration Edition. If you do not have these development tools

installed, you can skip the development section and go directly to the runtime

section.

13.4.1 Design guidelines

This section discusses some of the design guidelines to consider when

interoperating between these two process managers.

Interoperability overview

Figure 13-2 shows the processes that we discuss and develop in this section.

Figure 13-2 Process manager interoperability

The WebSphere MQ Workflow process (WMQWF2) essentially delegates the task of

“getBestWholeSaler” to a WebSphere Process Choreographer process (Called).

When the WebSphere Process Choreographer process returns, the WebSphere

MQ Workflow process can continue processing the other activity nodes. In our

case, we have an program activity which simply displays the return value.

Chapter 13. Process manager interoperability 363

However the process could be easily expanded to include the placeOrder

program activities as described in the previous chapters.

This chapter will focus on some design decisions and guidelines as they relate to

the interoperability scenarios. Best practices for designing either WebSphere MQ

Workflow or WebSphere Process Choreographer processes, as covered in

previous chapters, still apply here.

In order to understand the best practices for designing inter-operable processes,

we need to first understand how the two process managers can work together.

WebSphere MQ Workflow interface for interoperability

As you know already, WebSphere MQ Workflow is based on WebSphere MQ,

and all of its server components communicate using WebSphere MQ queues.

The most important component is the execution server, which is in charge of

starting and navigating WebSphere MQ Workflow processes. It is the

communication end point for any applications, including WebSphere Process

Choreographer, which want to exploit WebSphere MQ Workflow functionality.

The only communication interface with the execution server are messages that

are sent to a WebSphere MQ queue. The execution server can process two

message formats:

–

SDDS: An internal (proprietary) format of WebSphere MQ Workflow

messages that is generated by the client API functions

–

XML: A subset of the SDDS messages in XML format: The XML

messages have to be sent as the "payload" of an MQ message. The MQ

message may contain additional headers.

The execution server accepts XML messages (incoming) for the invocation of

certain functions, and it also uses XML message (outgoing) to invoke

user-defined process execution servers (UPES). Thus, XML messages are well

suited for interoperability with non-WebSphere MQ Workflow components. As

you will see later, XML message exchange is the foundation of our

interoperability.

Process Choreographer interface for interoperability

WebSphere Process Choreographer consists of several important components,

including a Navigator, Factory, and a host of plug-ins. The most important

component, as you can guess, is the Navigator, which is responsible for the

Note: The focus of this chapter is on interoperability. Therefore, not all of the

activities described in the business process model are actually implemented in

this scenario.