To Connect to a Remote WebSphere MQ Queue.

When an Adapter connects to a local queue manager and accesses one of its queues, that queue is a local queue. When an Adapter connects to a remote queue manager and accesses one of its queues, then that queue, is also a local queue. In WebSphere MQ terms, a remote queue is a queue that is managed by a queue manager other than the one to which the application (in this case, the Adapter) is connected.

For example, say that there are two queue managers, QM1 and QM2. QM1 manages a queue (Q1) and runs on Host1. QM2 manages a queue (Q2) and runs on Host2.

Furthermore, say that need to send messages to Q2, but the Adapter may only communicate with Host1 (that is, Host2 is unreachable from the system in which the Adapter is executing). By creating the appropriate channels and a remote queue definition (R1 on QM1), messages sent to R1 can be shuttled automatically to Q2 on QM2.

For this example, the Queues and the Adapter are configured as follows:

1. If either QM1 or QM2 do not have a transmission queue defined, create one. Both queue managers require one transmission queue each. In this example, assume that both queue managers have the transmission queue ’xmit’.

2. Create a Sender Channel for QM1 that points to Host2 and transmission queue xmit. The name of the channel must match the Receiver Channel created in the next step.

3. Create a Receiver Channel for Q2. The name of the channel must match the Sender Channel created in the previous step.

4. In QM1, create a Remote Queue Definition (R1). Designate Q2 as its remote queue, QM2 as its remote queue manager, and xmit as its transmission queue.

5. Configure the MQ Adapter to connect to Host1, QM1, and have it put messages into queue R1.

   ---

   Note –

   Messages cannot be read/GET from remote queues, only PUT. In the example situation above, to read the messages placed in QM2:Q2 through R1, an Adapter needs to connect directly to QM2 (Host2), thereby interacting with Q2 as a local queue.

   ---