Enabling SOA Using WebSphere Messaging

Chapter 7. Integration scenarios with WebSphere Message Broker 223

You can use this interface to:

򐂰 Create and manage broker domains and topology.

򐂰 Create and manage execution groups.

򐂰 Create and deploy broker archive (bar) files to execution groups.

򐂰 Manage publish/subscribe topics and subscriptions.

򐂰 Manage event logs and alerts.

A single Message Brokers Toolkit can connect to multiple Configuration

Managers, thus allowing it to manage multiple broker domains.

7.1.3 Sample message flow

The message flow shown in Figure 7-3 illustrates some of the functionality you

can achieve in a message flow. This example is a simple scenario for routing

messages from a travel bureau to the proper airline company based on the

message content and transforming the messages if needed. This message flow

was created using built-in nodes.

Figure 7-3 Sample message flow

Each segment of the message flow is discussed in the following sections.

Initial processing

Figure 7-4 on page 224 shows the portion of the sample message flows that

routes the message to the proper destination based on the message contents.

224 Enabling SOA Using WebSphere Messaging

Figure 7-4 Message flow for the travel bureau

The process is:

1. A message is placed on a queue and enters the message flow through the

XML.IN MQInput node.

2. If the message is not in XML format it is sent through the failure terminal of

the MQInput node to the MQOutput node, XML.FAIL. The message ends up

on a queue designated for errors and the flow ends.

If the message format is valid, the message is sent to the KE Filter node.

3. The KE Filter node looks at the message data. If the FlightNumber string in

the XML data starts with “KE”, the message is sent over the true terminal to

the portion of the message flow that transforms data for Airline A. (See

“Airline A” on page 224 for a continuation of the scenario.) Otherwise the

message is sent through the false terminal to the OZ Filter node.

4. The OZ Filter node looks at the message data. If the FlightNumber string in

the XML data starts with “OZ”, the message is sent over the true terminal to

the portion of the message flow that transforms the data for Airline B. (See

“Airline B” on page 225 for a continuation of the scenario.)

If the FlightNumber string in the XML data does not start with either, the

message is sent to the Build.Err.Msg compute node, where it is changed to

an error message. The message is then sent to the ERR.MSG MQOutput

node, where it ends up on a queue designated as an error queue.

Airline A

Figure 7-5 on page 225 shows the portion of the message flow that handles data

bound for Airline A. The message sender uses a different XML format than

Airline A uses so transformation of the message is necessary before sending it

on to the airline.

<flow for Airline A>

<flow for Airline B>

Chapter 7. Integration scenarios with WebSphere Message Broker 225

Figure 7-5 Message flow for Airline A

The process is:

1. The KE Filter node has determined the message is to be sent to Airline A.

The message is sent to the XMLTransformation node where the XML

message is transformed from its original XML format to a new format required

by Airline A.

The message is then sent to the XML.OUT MQOutput node.

2. The MQOutput node sends the message to the Add.Topic Compute node.

The message is added to the Publication topic and sent to the Publication

node.

3. The Publication node publishes the message to a pub/sub application in

Airline A.

Airline B

Figure 7-6 on page 226 shows the portion of the message flow that handles data

bound for Airline B. Airline B uses a COBOL application so the message must be

transformed before being sent.