...

...

1. In the Proxy Connection Settings dialog, choose MQ for  as the Proxy Type.
    
    
   

2. 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.

   Info
   icon false title Using multiple queue managers in a single proxy
   If you want to configure connections to different queue managers within a single proxy (e.g.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.

3. 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). 

   Info
   title SSL
   You can define an 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 drop-down menu. SSL configurations are not supported in the local settings configuration.

   

   • A Put queue is always where the AUT/client is putting/sending request messages. A "get" Get queue is where the client/AUT is getting response messages from.
     

   • Virtualize or SOAtest will SOAtest will capture request messages sent to the client Put queue and forward them to the server Put queue for processing. The  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.

   • When the Message Proxy is started, it will create two listeners. One listener is created on the client Put queue, which 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, which 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 and parasoft.proxy.mq.put.options whenVirtualize when Virtualize or SOAtest is SOAtest is started. For  For instance, assume the message contains a customized value for the MQMD header putApplicationName. Setting the MQOOthe 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:

     Code Block
     soatest.exe -J-Dparasoft.proxy.mq.put.open.options=2052 -J-Dparasoft.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 MQCflags MQC.MQOO_SET_ALL_CONTEXT, MQC.MQOO_INPUT_SHARED and MQC and MQC.MQOO_INPUT_EXCLUSIVE are turned on.

     Info
     icon false title Queue Configuration Details
     See Configuring Queues For for Recording for tips on how to configure recording in different scenarios.

4. Modify the Use replyToQueueName for response setting 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.

5. Modify the Worker count setting, if desired.

   Info
   icon false title Adjusting the Worker Count
   Each worker creates its own connection to the MQ provider. For example, for MQ, if you have 20 workers, your WebSphere 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, etc. 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 MQ infrastructure has a limit on how many concurrent connections to allow. You should not exceed what is configured/allowed by your infrastructure.  The worker count feature is equivalent to the “maxThreads” attribute maxThreads attribute in Tomcat server.xmlxml. To adjust the server.xml file: Launch Virtualize and ensure that at least one responder has been created. Modify the server.xml file at <INSTALL><INSTALL-DIR>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf/server.xml When using a high number of concurrent virtual users (i.e., such as during a load test), you can usually expect better performance by increasing these values.

6. 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.and so on) 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:

If you are using CCDT mode, complete the following fields...:

Local serverFor a local server:
 

For a remote Remote server:

...

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 for Recording for tips on how to configure queues in different scenarios.