Recording by using proxy queues mode

In Proxy Queues mode, Rational® Integration Tester monitors a "proxy" request queue (denoted by combining the actual queue name with the Queue Suffix), record and remove any messages that are received. It displays these messages in recording studio. Then, it passes the message on to the original queue. Request-based messages that are passed to the proxy queue are amended so that any reply queues that they specify are also converted to use the corresponding proxy queue.

About this task

Proxy Queues mode enables the Recording Studio perspective to show all of the original message details, and it allows tests and stubs to be created that use the original (non-proxy) queue names.

Before Proxy Queues mode can be used, the system administrator needs to set up the proxy queues. A proxy queue is named the same as the request or reply queue, except for the addition of the Queue Suffix (specified in the IBM® WebSphere® MQ transport). Additionally, message initiators can be configured to send their requests to the proxy queue.

Note: Proxy queues are required for both the request queue and for the reply queue.

Within the Recording Studio perspective and in transports bindings (in the definition of the containing operation), the original queue names must be used, which are "proxied" and "de-proxied" by Rational® Integration Tester when recording.

A "working" example of the process is described in the following steps:

Procedure

  1. The client sends a request to Q1.RIT, specifying Q2 for the reply (note that the reply queue is not "proxied" by the initiator).
  2. Rational® Integration Tester (Recording Studio) picks up the request on Q1.RIT, adds it to the list of recorded events, "proxies" the reply queue from Q2 to Q2.RIT, and "de-proxies" the request message by placing it on Q1.
  3. The server picks up the message on Q1, processes it, and sends the reply to Q2.RIT.
  4. Rational® Integration Tester (Recording Studio) picks up the reply on Q2.RIT, adds it to the list of recorded events, and "de-proxies" the reply message by placing it on Q2.
  5. The client receives the reply on Q2.
    Note: De-proxying occurs only while recording is taking place.