This topic explains how to configure individual virtual assets deployed to a Virtualize server. Refer to Configuring Server and Deployment Settings Virtualize for details on configuring Virtualize server settings.
...
Double-click on a virtual asset in the Virtualize Server view to access it's its configuration settings. Alternatively, you can right-click the asset and choose choose Open.
| Info | ||
|---|---|---|
| ||
For details on how to customize virtual assets with different request/response use cases, error conditions, and other behaviors, customize the related Message Responder tools as described in Message Responder Overview. |
...
| Info | ||
|---|---|---|
| ||
Before deploying virtual assets over JMS and/or MQ, be sure to add the appropriate jar files to the Virtualize classpath. For For details on how to do this, see System Properties Settings. |
...
Specify a path on the server where the virtual asset will listen for incoming messages over HTTP. If no value is specified, then only JMS, MQ, or custom transport listener settings will be applied for receiving messages.
...
Wild cards can be used to allow segments of the path to be dynamic. For example, assume two requests were sent to Virtualize on the paths /path/1/service and /path/2/service. To have both requests go to the same virtual asset, configure the path as /path/*/service.
...
Specify the name of the topic requested by the client application and choose your connection configuration option from the Settings drop-down menu.
Choose Local Settings to use the provider URL, initial context class, connection factory, and login credentials specified in the Local Settings section, or choose a connection configured on the Virtualize server Connections Tab (see Using Global JMS Connections).
...
Specify the name of the message destination queue and choose your connection configuration option from the Settings drop-down menu.
Choose Local Settings to use the provider URL, initial context class, connection factory, and login credentials specified in the Local Settings section, or choose a connection configured on the Virtualize server Connections Tab (see Using Global JMS Connections).
...
Specify the name of the topic the client application subscribes to for the response and choose your connection configuration option from the Settings drop-down menu.
Choose Local Settings to use the provider URL, initial context class, connection factory, and login credentials specified in the Local Settings section, or choose a connection configured on the Virtualize server Connections Tab (see Using Global JMS Connections).
...
Specify the name of queue for posting responses and choose your connection configuration option from the Settings drop-down menu.
Choose Local Settings to use the provider URL, initial context class, connection factory, and login credentials specified in the Local Settings section, or choose a connection configured on the Virtualize server Connections Tab (see Using Global JMS Connections).
...
Enable this option to use the message's JMSReplyToQueueName header to determine where the virtual asset sends the response.
If Use JMSReplyTo for response is enabled, values from the incoming request will be used to determine where to send the response. If If it is not enabled, the response will be sent to the queue specified in the UI; the values in the JMS message header will be ignored.
...
You can use the connection settings defined in the Virtualize Server configuration. See Connections Tab for details on configuring global JMS connection settings. To use a global JMS connection, choose it from the Settings drop-down menu.
To review the details of a predefined global connection, click View settings.
...
The built-in JMS message listener receives and responds to javax.jms.TextMessage message TextMessage message types.
Behavior of Virtual Assets Deployed Over JMS
...
Virtual assets can emulate services that communicate over IBM WebSphere MQ queues if you configure the necessary MQ settings. Refer to IBM WebSphere MQ Tools Reference for additional details.
You can specify the following MQ settings.
...
Specify the queue that Virtualize retrieves the request message from (also referred to as "get" or "pull") and choose your connection settings from the Settings drop-down menu.
Choose Local Settings to use the connection settings configured in the Local Settings section or choose a setting configured in the Connections Tab of the Virtualize server configuration (see Using Global MQ Queues).
...
Specify the queue to which Virtualize sends (also referred to as "put" or "push") the response message and choose your connection settings rom from the Settings drop-down menu.
Choose Local Settings to use the connection settings configured in the Local Settings section or choose a setting configured in the Connections Tab of the Virtualize server configuration (see Using Global MQ Queues).
...
Enable this option to use the message's replyToQueueName header to determine where the virtual asset sends the response. It impacts responses to MQ messages of type MQMT_REQUEST.
If Use replyToQueueName for Response Response is enabled, values from the incoming request will be used to determine where to send the response. If If it is not enabled, the response will be sent to the queue specified in the UI. More specifically:
- If Use replyToQueueName for Response is enabled and values for both
MQMD.replyToQueueManagerNameandMQMD.replyToQueueNamehave been specified, those values will determine both the queue manager and the queue name to send the response to. - If Use replyToQueueName for Response is enabled and either
MQMD.replyToQueueManagerNameorMQMD.replyToQueueNameis missing from the request, the value specified in the UI will be used in place of the missing value.
If Use replyToQueueName for Response 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.
...
(Optional) When the same queue is being used by multiple applications (or there are multiple types of messages exchanged over the queue), it might be necessary to filter the messages that are picked up by Virtualize. The value in this field (if a value is provided) is matched against the MQMD applicationIdData field in the messages on the queue. In this case, the MQ API MQC.MQGMO_BROWSE_NEXT flag is used to get the messages from the queue.
...
Choose Local Settings when configuring the queue or topic connection settings and configure the the following settings. SSL is not supported in the local settings configuration settings. You must configure a global MQ queue to use SSL in the Virtualize server's Connections Tab and and choose the queue from the Settings drop-down menu (see see Using Global MQ Queues).
...
Choose one of the following modes:
- Default mode: Lets Lets you enter connection details (e.g.for example, host, port, channel, etc.and so on) manually.
- CCDT mode: Lets Lets you specify a client channel definition table (CCDT) file that provides connection details.
Host (Default Mode)
Specify the MQ queue manager host.
...
If you are using CCDT mode on a remote server, specify the relative path to the CCDT file as it would appear under the " Files " node in the Virtualize Server tree. The options to browse for the file in the workspace or file system will not be available.
...
If you want to configure queues deployed on different MQ servers within a single virtual asset (e.g.for example, you want a specific virtual asset to use two queues that are deployed on two different MQ servers), you can define them globally at the Virtualize server level, then reference them here. See See Connections Tab for details.
Browsing Queue Contents - Debugging and Testing of Virtual Assets Deployed Over MQ
When debugging the environment and testing the virtual asset configuration, you might want to use the Queue browser to review queue contents. This visibility can be very helpful when you are trying to understand and resolve unexpected unexpected behavior.For For details, see Browsing Queues_virt.
...
Increasing the worker count can help performance under concurrency. The entire message processing chain of the virtual asset 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 an asset will take longer because there are more connections to create/destroy. Also, it is possible that the WebSphere MQ infrastructure or the JMS provider 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.xml.
When subjecting Virtualize to 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.
...
If multiple custom listeners are available, you can select the one you want to use from the Select Implementation drop-down menu, then use the available controls to configure it as needed.
...
There are no special restrictions for .pvas that include SQL Responders; any path is acceptable. By default, the Parasoft JDBC Driver calls the virtual asset deployed at /virtualDb (when in Virtualize or Hybrid mode). If you want to configure it to call a virtual asset that is deployed at a different endpoint, add the appropriate property as described in in Specifying which Virtual Asset the Parasoft JDBC Driver Calls.
...