This topic explains how to configure message proxies (and recording proxies) that send and receive messages over the MQ transport.
Sections include:
MQ Prerequisites
Jar Files
See Adding Necessary Jar Files to the Classpath.
Queue Allocation
When traffic is being exchanged over queues, the assumption is that there is a client application that puts a request to a client destination queue and a server application that gets that message from the queue then puts another (reply) message onto a second queue for the client to get.
With that scenario in mind, Parasoft Virtualize uses a "man-in-the-middle" (a.k.a. proxy) approach between the client and the server, so two extra queues are needed on the messaging provider in order to facilitate that mediation. Virtualize proxies will receive messages from where the client places them, record the message contents (if recording is enabled), then put the message on the queue where the server will receive it. Similarly, the server sends the message to a queue where the proxy picks it up, records it (if recording is enabled), and places it back on the queue where the client is expecting the reply response.
As a result, it is necessary to allocate two additional queues and either:
- Adjust the client application to communicate over these two new queues (with the proxy connections configured for them).
- Adjust the server application to use the two other queues.
Only one of the two application queues needs to be modified.
Specifying MQ Settings
Specify your MQ settings as follows:
- In the Proxy Connection Settings dialog, choose MQ for Proxy Type.
If you are defining the client and server queues in this panel (rather than referencing previously-defined queue managers as described in Using Global Queue Managers), enter server details in the Local Settings area.
- Specify the client and server queues. You can either enter the settings for each connection in this panel (via the Local Settings option) or reference a global queue manager defined at the Virtualize server level (see Using Global Queue Managers for details).
- A "put" queue is always where the AUT/client is putting/sending request messages. A "get" queue is where the client/AUT is getting response messages from.
- Virtualize will capture request messages sent to the client Put queue and forward them to the server Put queue for processing. The server Get queue is the queue that the server will place a response message on (after processing the request message). Virtualize will capture these messages and forward them to the client Get queue.
- When the Message Proxy is started, it will create two listeners. One listener is created on the Client put queue; this one picks up messages from the Client Put Queue and places them on the Server Put Queue. The second listener is started on the Server Get queue; it moves messages from Server Get Queue to the Client Get Queue.
If you want to customize the option flags that are used when the proxy opens a queue or puts a message on the server put queue, you can specify the JVM system properties
parasoft.proxy.mq.put.open.options
andparasoft.proxy.mq.put.options
when Virtualize is started. For instance, assume the message contains a customized value for the MQMD header putApplicationName. Setting the MQOO_SET_ALL_CONTEXT flag on the queue open options and the MQPMO_SET_ALL_CONTEXT flag on the put options would allow the message proxy to forward the customized putApplicationName header value.
See the IBM mq_queue_get_open_options and mq_message_put_options parameters for option flag values. For example:virtualize.exe -J-Dparasoft.proxy.mq.put.open.options=2052 -J-Dpara- soft.proxy.mq.put.options=2064
The values used here are the sum of all the values represented by the individual flags. For example, the open option value of 2052 means the three flags MQC.MQOO_SET_ALL_CONTEXT, MQC.MQOO_INPUT_SHARED and MQC.MQOO_INPUT_EXCLUSIVE are turned on.
- A "put" queue is always where the AUT/client is putting/sending request messages. A "get" queue is where the client/AUT is getting response messages from.
- Modify the Use replyToQueueName for response setting if desired. This option specifies whether to use the message’s replyToQueueName header to determine where the proxy sends the response. It impacts responses to MQ messages of type MQMT_REQUEST.
- If it is enabled, values from the incoming request will be used to determine where to send the response. If it is not enabled, the response will be sent to the queue specified in the UI. More specifically:
If it is enabled and values for both MQMD.replyToQueueManagerName and MQMD.replyToQueueName have been specified, those values will determine both the queue manager and the queue name to send the response to.
- If it is and either MQMD.replyToQueueManagerName or MQMD.replyToQueueName is missing from the request, the values specified in the UI will be used in place of the missing value.
- If it is disabled, the replyToQueueName and replyToQueueManagerName fields in the MQ request message will be ignored. The UI settings will determine where the message is sent.
Modify the Worker count setting if desired.
- If you are not using a global queue manager queue manager, specify connection details in the Local Settings area. You can choose between the following modes:
- Default mode: Lets you enter connection details (e.g., host, port, channel, etc.) manually.
- CCDT mode: Lets you specify a client channel definition table (CCDT) file that provides connection details.
If you are using Default mode, complete the following fields:
Option | Description |
---|---|
Host | Specifies the name of the host running IBM MQ. |
Port | Specifies the port where IBM MQ is running. |
Channel | Specifies the name of the server-defined channel. |
Username/Password | Enter if needed. |
If you are using CCDT mode, complete the following fields...
For a local server:
For a remote server:
Option | Description |
---|---|
CCDT file | Specifies the location of the CCDT file (with a .tab extension). If the proxy is deployed on a remote server, use the text field to specify the relative path to the CCDT file as it would appear under the "Files" node in the Virtualize Server tree. If the proxy is deployed on a local server, you can use the File System or Workspace buttons to browse to the file’s location. If you are configuring a proxy that is currently deployed on a local server but will later be deployed on a remote server, you will need to deploy the CCDT file to the remote server before deploying the proxy to that remote server. See Transferring Files Between the Remote Server and the Local Machine. |
Queue manager | Specifies the queue manager’s name. |
Username/Password | Enter if needed. |
Using Global Queue Managers
Global queue manager settings that apply across a specific Virtualize server can be defined at the server level, then referenced here. See Connections Tab for details.
To use a global queue manager, select it from the appropriate Queue box. MQ servers are listed using the naming convention hostname: queue manager name
To review the details of a predefined global queue manager, click View settings.
Queue Configuration Tips
See Configuring Queues For Recording for tips on how to configure queues in different scenarios.