IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Using multiple brokers for record and replay

You can have multiple brokers in your record and replay topology. If you use different brokers 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 brokers.

Before you start:

Read the concept topic Record and replay.

You can use separate brokers 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 broker used for viewing and replaying data does not interact with the broker used to record data to a database. However, if the broker to which you deploy your message flows is not the recording broker, then you must set up a publish/subscribe relationship between these brokers.

Data capture is based on a publish/subscribe model. You configure monitoring on message flows that you have deployed to a broker, for example, to broker 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 broker that you use to create the DataCaptureStore configurable service, RECBKR, subscribes to the monitoring topic. The subscription messages that this broker receives are processed by egForRecord and recorded to the data source specified in the DataCaptureStore configurable service.

You must use the same broker 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 Information Center 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:

Establish a point-to-point channel connection between MONQM and RECQM.
1. On a command line on the server that hosts MONQM, enter runmqsc MONQM
2. 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)
```
3. 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.
4. Define a receiver channel:
```
DEFINE CHANNEL('RECQM.TO.MONQM') CHLTYPE(RCVR) TRPTYPE(TCP)
   DESCR('Receiver channel from RECQM to MONQM')
```
5. 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.
6. Start the listener. Enter START LISTENER('LISTENER.TCP')
7. Enter END to finish the RUNMQSC session.
8. 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.
You can also configure the queue manager channels by using IBM® Integration Explorer. 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.

Next:

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

Complete the steps for recording data; see Recording data.

bj23710_.htm |

Last updated Friday, 21 July 2017