362 Patterns: Serial and Parallel Processes
13.4 WebSphere MQ Workflow invoking Process
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
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
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.

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.