Using multiple integration nodes for record and replay

You can have multiple integration nodes in your record and replay topology. If you use different integration nodes for deploying your message flows and for recording data captured from those message flows to a database, then you must configure a publish/subscribe relationship between the integration nodes.

Before you begin

Read the concept topic Record and replay.

About this task

You can use separate integration nodes for deploying the message flows from which you want to capture data, for recording the data to a database, and for viewing the data. The integration node used for viewing and replaying data does not interact with the integration node used to record data to a database. However, if the integration node to which you deploy your message flows is not the recording integration node, then you must set up a publish/subscribe relationship between these integration node.

Data capture is based on a publish/subscribe model. You configure monitoring on message flows that you have deployed to an integration node, for example, to integration node MONBKR. MONBKR publishes to the topic that you specify when you configure your monitoring events. The topic identifies the source of the data that you want to capture. You specify this topic in your DataCaptureSource configurable service.

You define a DataCaptureStore configurable service where you specify the integration server to use for processing the captured data, egForRecord. The integration node that you use to create the DataCaptureStore configurable service, RECBKR, subscribes to the monitoring topic. The subscription messages that this integration node receives are processed by egForRecord and recorded to the data source specified in the DataCaptureStore configurable service.

You must use the same integration node to create the DataCaptureStore and the DataCaptureSource configurable services.

In this scenario, MONBKR publishes on the monitoring topic and RECBKR subscribes to the topic. If MONBKR runs on queue manager MONQM and RECBKR runs on queue manager RECQM, then you need to configure a publish/subscribe relationship between MONQM and RECQM.

You can choose to create either a cluster or a hierarchical publish/subscribe relationship between the two queue managers. If you plan to add queue managers to your topology frequently, then a cluster relationship is more appropriate. See the topics on Publish/subscribe topologies in the WebSphere® MQ Version 7.5 product documentation online. This example uses a hierarchical relationship. In the example, values enclosed in single quotation marks can be replaced with your preferred values, but keep the quotation marks if you use lowercase characters. Complete the following steps:

Procedure

Establish a point-to-point channel connection between MONQM and RECQM.

On a command line on the server that hosts MONQM, enter runmqsc MONQM

Define a transmission queue for MONQM to use when forwarding messages to RECQM:

DEFINE QLOCAL('RECQM') USAGE(XMITQ) TRIGGER TRIGDATA('MONQM.TO.RECQM') INITQ(SYSTEM.CHANNEL.INITQ)

Define a sender channel:

DEFINE CHANNEL('MONQM.TO.RECQM') CHLTYPE(SDR) TRPTYPE(TCP) CONNAME('RECQM.SERVER') XMITQ(XMIT)
  DESCR('Sender channel from MONQM to RECQM')

RECQM.SERVER is the name of the server that hosts RECQM.

Define a receiver channel:

DEFINE CHANNEL('RECQM.TO.MONQM') CHLTYPE(RCVR) TRPTYPE(TCP)
   DESCR('Receiver channel from RECQM to MONQM')

Configure a listener on the queue manager:
```
DEFINE LISTENER ('LISTENER.TCP') TRPTYPE(TCP) PORT(PORT) CONTROL(QMGR)
```
PORT is the port number on which the listener listens.
Start the listener. Enter START LISTENER('LISTENER.TCP')
Enter END to finish the RUNMQSC session.

Now configure RECQM. On the server that hosts RECQM, enter the following commands at a command line:

runmqsc RECQM

DEFINE QLOCAL('MONQM') USAGE(XMITQ) TRIGGER TRIGDATA('RECQM.TO.MONQM') INITQ(SYSTEM.CHANNEL.INITQ)
DEFINE CHANNEL('RECQM.TO.MONQM') CHLTYPE(SDR) TRPTYPE(TCP) CONNAME('MONQM.SERVER') XMITQ(MONQM)
  DESCR('Sender channel from RECQM to MONQM')
DEFINE CHANNEL('MONQM.TO.RECQM') CHLTYPE(RCVR) TRPTYPE(TCP) 
  DESCR('Receiver channel from MONQM to RECQM')
DEFINE LISTENER ('LISTENER.TCP') TRPTYPE(TCP) PORT(PORT) CONTROL(QMGR)
START LISTENER ('LISTENER.TCP')
END

MONQM.SERVER is the name of the server that hosts MONQM, and PORT is the port number on which the listener listens.

For more information about configuring channels for publish/subscribe, see the topics on Publish/subscribe topologies in the WebSphere MQ Version 7.1 product documentation online .

Configure the queue manager publish/subscribe hierarchy.
Make RECQM a child of MONQM by completing the following steps:
1. Open a command line on the server that hosts RECQM, and enter: runmqsc RECQM
2. Make RECQM a child of MONQM:
```
ALTER QMGR PARENT('MONQM')
```
  To make RECQM a child of MONQM, the Parent queue manager name must be given as MONQM.
  Confirm that the operation worked by listing all publish/subscribe relationships for this queue manager:
```
DIS PUBSUB TYPE(ALL)
```
  The output shows that MONQM is now the parent of RECQM:
```
AMQ8723: Display pub/sub status details.
   QMNAME(RECQM)                           TYPE(LOCAL)
AMQ8723: Display pub/sub status details.
   QMNAME(MONQM)                           TYPE(PARENT)
```
3. Type END to end the RUNMQSC session for RECQM.
4. Optional: Start a RUNMQSC session for MONQM and display the publish/subscribe types, as you did for RECQM. The output shows that RECQM is a child of MONQM.

What to do next

Consider the performance implications of your record and replay topology; see Tuning data capture.

Complete the steps for recording data; see Recording data.