WebSphere Business Integration Adapters: An Adapter Development and WebSphere Business Integration Solution

Chapter 32. Gathering data from the run-time 843

Figure 32-19 Cleanup manager

16. Select Process Version.

17.Use the drop-down list of Process Lists to verify that the RedTenant process

is in the database.

You now have the basics in place. From here, you can make the required

modifications to the Message Flows to enable data to be sent to the Monitor.

32.4 Setting up the Message Broker environment

The way in which WebSphere Business Integration Message Broker integrates

with the Monitor is through the Emitter Node. This node can be located as part of

a support pack (IB01) for the Message Broker. The emitter node integrates with

the Monitor by sending data regarding the message flow in which it runs, to the

Monitor database.

Typically, to integrate WebSphere Business Integration Message Broker with the

Monitor, you must work with the WebSphere Business Integration Modeler. The

Modeler is used to construct the high-level view of the business process. This

high-level view includes the data structures that the business process uses.

When this business process has been constructed, it is then possible to export

various definition files for use with Monitor, Workflow, and WebSphere Business

Integration Message Broker.

844 WebSphere Business Integration Adapters

For the Monitor to integrate with WebSphere Business Integration Message

Broker, it needs a common frame of reference, which supplied by the export files

from Modeler. In this instance, the XSD file that relates to the message

structures for business processes needs to be exported from Modeler and into

WebSphere Business Integration Message Broker. When this is complete, data

sent from the Emitter Node can then be interpreted by the Monitor in a

meaningful way. In our example, we installed the Emitter Node into the Message

Broker Toolkit according to the instructions.

The EmitterMessages Message Set Project contains the message for the data

that we will emit. Note that the message set name is Customer. The name of the

message set is not in anyway directly linked to the Monitor. It is, however, linked

to what we build in the Broker. This is discussed in more detail when we see the

ESQL in Example 32-1 on page 847.

To set up the Message Broker environment:

1. Import the Message Set into your Broker Workspace.

2. In your RedMaintenance Message Flow project, add a reference to the

EmitterMessages Message Set.

3. Go to the Data perspective and configure the datasource for the WFMDB,

which is the default name of the Monitor database (Figure 32-20 on

page 845).

Note: The message set that we use and the subflows for the request and

response flows are included in the Additional Materials.

Chapter 32. Gathering data from the run-time 845

Figure 32-20 Data source WFMDB

4. Copy this data source to your RedMaintenanceFlows project.

5. EmitterFlows contains the two subflows that we created for handling the

emitting of data on the request flow and the response flow. Copy or move

these to the RedMaintenanceFlows project.

6. Double-click the MonitorEmitter Message Flow (Figure 32-21) to open it in the

Message Flow Editor.

Figure 32-21 MonitorEmitter

846 WebSphere Business Integration Adapters

7. Open the Compute node properties, as shown in Figure 32-22.

Figure 32-22 Compute node

8. The Compute Mode must be set to LocalEnvironment and Message.

9. The ESQL Module is EmitterRequest.

10.Open the ESQL that is shown in Example 32-1 on page 847.

The ESQL performs the following:

– Declares namespaces for our business object messages.

– Sets the Emitter data for each of the different type of messages that pass

through.

– Passes the Input message to the output message. (In our scenario, we do

want to modify the incoming message in any way, so we merely pass it

on.)

– Sets the Emitter values in the Environment.

– Sets the MEmitter Task value, which is the process identifier in the

Monitor.