Recording by using proxy Channels, Queues, or Data Groups

HCL OneTest™ API monitors a request through a "proxy" Channel, Queue, or Data Group record and removes any messages that are received. It displays these messages in the recording Studio. Then, it passes the message on to the original communication target (Channel, Queue or Data Group). Request-based messages that are passed to the proxy communication target are amended so that any reply communication target that they specify is also converted to use the corresponding proxy.

Before you begin

You must have started recording from an Operation BEFORE starting recording the transport through a proxy so that the stub can receive the messages. The Operation Recording moves the message from the _HIT communication target ('Name_HIT') Stub from one Channel, Queue or Data Group to another (from CHANNEL1_HIT to CHANNEL1 in the example) and thus, the stub can pick it up.

About this task

The proxy 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) communication target names.

Before a proxy mode can be used, the system administrator needs to set up the proxy Channels, Queues or Data Groups. A proxy communication target is given the same as the request or reply communication target, except for the addition of the suffix (specified by Software AG Universal Messaging). Additionally, message initiators can be configured to send their requests to the proxy.

Note: Proxy Channels, Queues or Data Groups are required for both the request and for the reply.

Within the Recording Studio perspective and in transport's bindings (in the definition of the containing operation), the communication Channel, Queue or Data Group names must be used. An example of process is described in the following steps. In the example, proxy Channels are used.

Procedure

  1. The client sends a request to MyChannel1_HIT, specifying MyChannel2 for the reply (note that the reply Channel is not "proxied" by the initiator).
  2. The Recording Studio perspective picks up the request on MyChannel1_HIT, adds it to the list of recorded events, "proxies" the reply channel from MyChannel2 to MyChannel1_HIT, and "de-proxies" the request message during the recording by placing it on MyChannel1.
  3. The server picks up the message on MyChannel1, processes it, and sends the reply to MyChannel2_HIT.
  4. Recording Studio picks up the reply on MyChannel2_HIT, adds it to the list of recorded events, and "de-proxies" the reply message by placing it on MyChannel2 during the recording.
  5. The client receives the reply on MyChannel2.