This topic explains how to configure message proxies that send and receive messages over the IBM MQ transport. In this section:
See Adding Necessary Jar Files to the Classpath.
When traffic is exchanged over queues, we assume that a client application sends a request to a destination queue and that a server application receives the message from the queue. The server then sends a reply message onto a second queue for the client to receive. In this scenario, the message proxy serves as a "man-in-the-middle" between the client and the server, which requires two additional queues on the messaging provider in order to facilitate the mediation. Parasoft proxies receive messages from where the client places them, records the message contents (if recording is enabled), then puts 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:
Only one of the two application queues needs to be modified.
See Configuring Queues for Recording for tips on how to configure recording in different scenarios. |
Specify your IBM MQ settings as follows:
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.
If you want to configure connections to different queue managers within a single proxy (for example, you want a specific proxy connection use two queues that are deployed on two different queue managers), create a global queue manager for each queue you want to use, then select the appropriate queue manager as you configure the proxy. |
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 server level (see Using Global Queue Managers for details).
You can define an IBM MQ queue on the Virtualize server that includes SSL configuration in the server's Connections Tab and apply the settings to the proxy by choosing the global queue manager from the menu. SSL configurations are not supported in the local settings configuration. |
Virtualize or SOAtest 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). These messages will be captured and forwarded 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 and parasoft.proxy.mq.put.options when Virtualize or SOAtest 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:
soatest.exe -J-Dparasoft.proxy.mq.put.open.options=2052 -J-Dparasoft.proxy.mq.put.options=2064 |
2052 means the three flags MQC.MQOO_SET_ALL_CONTEXT, MQC.MQOO_INPUT_SHARED and MQC.MQOO_INPUT_EXCLUSIVE are turned on.See Configuring Queues for Recording for tips on how to configure recording in different scenarios. |
replyToQueueName header to determine where the proxy sends the response. It impacts responses to MQ messages of type MQMT_REQUEST.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.
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.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.
Each worker creates its own connection to the IBM MQ provider. For example, if you have 20 workers, your IBM MQ Explorer should show the value 20 in the Open input count column for the request (get) queue that the message proxy is listening on. Whenever a proxy is deployed/redeployed with a worker count that is higher than the default value of 1, you should see messages like "Started x listener(s)" in the Console (where x is the number of workers configured). Increasing the worker count can help performance under concurrency. The entire message processing chain of the proxy is parallelized, so each worker thread will do message correlations, response message generation, and so on in parallel with other threads. However, beware that if you provide a high worker count, deploying/undeploying/redeploying a proxy will take longer because there are more connections to create/destroy. Also, it is possible that the IBM MQ infrastructure has a limit on how many concurrent connections to allow. You should not exceed what is configured/allowed by your infrastructure. |
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. |
| Queue manager | Specifies the name of the queue manager. |
| Username/Password | Enter if needed. |
If you are using CCDT mode, complete the following fields:
Local server
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 "Workspace files" node in the 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 name of the queue manager. |
| Username/Password | Enter if needed. |
In most cases, the default CCSID Virtualize uses to connect to the IBM MQ queue manager is acceptable. But if the IBM MQ queue manager is configured to use a different CCSID, you will be notified that the CCSID is not supported by queue manager.
You can set the following system property in your JVM arguments to change the default CCSID used to connect to the IBM MQ queue manager:
parasoft.mq.environment.ccsid=<CCSID>
The CCSID you set depends on the CCSID of the queue manager and what charset is supported on the JVM.
Also see Additional Preference Settings.
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. IBM 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.
See Configuring Queues for Recording for tips on how to configure queues in different scenarios.