This topic explains how to configure recording for WebSphere MQ and JMS point-to-point (when queues are used, not topics).
Sections include:
Overview
The method that Parasoft Virtualize uses for capturing/recording JMS point-to-point messaging and WebSphere MQ requires Virtualize to be a proxy— or, in other words, an intermediary / man-in-the-middle.
Assume that there is a client/consumer application (we’ll call this "Client") that sends/puts/pushes a request message on destination queue REQUEST_QUEUE and receives/gets/pulls a response/reply from RESPONSE_QUEUE. Also assume there is a server/provider application (we’ll call this "Server") that receives/gets/pulls messages from REQUEST_QUEUE and sends/puts/pushes responses to RESPONSE_QUEUE.
There are two possible configuration scenarios for recording traffic. In one, you modify the queues that are used on the client application end. In the other, you modify the queues that are used on the server.
The best approach to use depends on your ability to access and modify each end. In both cases, you will need to create two extra queues in order to enable the recording process. Here, we’ll label them as PROXY_REQUEST_QUEUE and PROXY_RESPONSE_QUEUE.
If the application under test is the client end of the system, then it is likely that the goal is to virtualize the server application. In this case, scenario 1, which involves modifying the client application, is more feasible because it involves modifying the component that is owned by the party interested in virtualization.
Using Topics Instead of Queues?
If a publish and subscribe scheme is used (using Topics instead of queues), then you don’t need to introduce new topics into the system. That’s why only two destinations need to be provided in the wizard:
- One for the requests—labeled in the wizard as the "Client Subscribe Topic."
- One for the response—labeled in the wizard as the "Server Publish Topic."
Scenario 1: Modifying the Client Application
In this scenario, you need access to the client application deployment configuration in order to adjust the queues it uses. Modify the queues that the client uses to communicate with the server as follows:
- put/send/push messages on PROXY_REQUEST_QUEUE
- receive/get/pull messages from PROXY_RESPONSE_QUEUE
The server does not need to have its queues changed in this case.
In the Virtualize MQ or JMS recording wizard, provide the queue names as follows:
| Client Queues | |
|---|---|
| Destination/Put Queue | PROXY_REQUEST_QUEUE |
| Reply to/Get Queue | PROXY_RESPONSE_QUEUE |
| Server Queues | |
| Destination/Put Queue | REQUEST_QUEUE |
| Reply to/Get Queue | RESPONSE_QUEUE |
Scenario 2: Modifying the Server Application
In this scenario, you need access to the server application deployment configuration in order to adjust the queues it uses. Modify the queues that the server uses to communicate with the client as follows:
- receive/get/pull messages from PROXY_REQUEST_QUEUE
- put/send/push response messages on PROXY_RESPONSE_QUEUE
The client does not need to have its queues changed in this case.
In the Virtualize MQ or JMS recording wizard, provide the queue names as follows:
| Client Queues | |
|---|---|
| Destination/Put Queue | REQUEST_QUEUE |
| Reply to/Get Queue | RESPONSE_QUEUE |
| Server Queues | |
| Destination/Put Queue | PROXY_REQUEST_QUEUE |
| Reply to/Get Queue | PROXY_RESPONSE_QUEUE |
