This topic explains how to configure individual virtual assets deployed to a Virtualize server. Refer to Configuring Server and Deployment Settings for details on configuring Virtualize server settings.

 In this section:

Accessing Virtual Asset Configuration Settings

Double-click on a virtual asset in the Virtualize Server view to access it's configuration settings. Alternatively, you can right-click the asset and choose Open. 

General Tab

In the General tab, you can specify the following settings.

Responder Suite

Specifies the Responder Suite in which Message Responders are configured, which is essentially a .pva file. To change the file that is used for this virtual asset deployment definition, browse to a .pva file within the local workspace or the file system in general. The file paths are relative to the VirtualAssets project folder.

Description

Provides a description of the virtual asset.

Transport Tab

The Transport tab contains configuration settings for how the virtual asset should receive and respond to messages.

HTTP Settings

You can specify the following HTTP settings.

Path

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. 

We recommend giving each virtual asset a unique HTTP path unless you want Virtualize to look into multiple virtual assets when searching for a responder that is configured to respond to the incoming message. 

If you deploy more than one virtual asset on the same HTTP path, Virtualize will look at each virtual asset until it finds a responder that matches the message based on the responder correlation criteria and use that responder and virtual asset for the response. The order in which virtual assets are evaluated in this case is not fixed; Virtualize will use the first virtual asset it finds during the evaluation.

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.

Wild cards are supported for replacing an entire segment of a path. For example:

• /path/*/service — valid
• /path/1*2/service — not valid

HTTP endpoint

If you are using HTTP (not JMS or MQ), this is where the virtual asset can be accessed. To exercise the virtual asset, you can configure your application to use this URL instead of the URL for the actual resource. Any machine that can access this endpoint can access and use your virtual asset.

JMS Settings

You can configure virtual assets to send and receive messages to a queue or a topic. Refer to JMS for details about configuring JMS settings.

• To configure global JMS settings that apply across a specific Virtualize server, double-click the appropriate server machine node in the Virtualize Server view.
• To configure JMS settings for a specific virtual asset, double-click the appropriate virtual asset node in the Virtualize Server view.

You can specify the following settings.

Point-to-Point

Enable this option to indicate a messaging model in which Destination and replyTo queues are specified. After enabling a messaging model, you can either enter the settings for each connection in the Local Settings section or reference a global JMS connection defined at the Virtualize server level (see Connections Tab).

Publish-and-Subscribe

Enable this option to indicate a messaging model in which Publish and Subscribe topics are specified. After enabling a messaging model, you can either enter the settings for each connection in the Local Settings section or reference a global JMS connection defined at the Virtualize server level (see Connections Tab).

Client Publish (Publish-and-Subscribe Mode)

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

Destination queue (Point-to-Point Mode)

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

Client Subscription (Publish-and-Subscribe Mode)

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

Reply to queue (Point-to-Point Mode)

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

Use JMSReplyTo for response

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

Message selector

(Optional) When the same queue is being used by multiple services, it is helpful to specify a message selector expression. For example, if the message selector expression is "product = 'virtualize'", then the virtual assets will select only messages in the queues/topics that have a JMS Message Property product with the value virtualize. See Using Message Selector Filters for tips.

Worker count

Worker count impacts the number of listener worker threads that get created. See Adjusting the Worker Count for details.

Local Settings

Choose Local Settings when configuring the queue or topic connection settings and configure the the following settings. To use settings configured at the server level, see Using Global JMS Connections. 

Provider URL

Specifies the value of the property named javax.naming.Context.PROVIDER_URL passed to the JNDI javax.naming.InitialContext constructor. 

Initial context class

Specifies a fully-qualified class name string, passed to the JNDI javax.naming.InitialContext constructor as a string value for the property named javax.naming.Context.INITIAL_CONTEXT_FACTORY.

Connection factory

Specifies the key used to look up the MOM-specific factory from the initial context. This can be either a Queue Connection Factory or a Topic Connection Factory. Be sure to add the related jars to the Virtualize classpath. See JMS Provider Configuration for tips on which factory classes to add for your specific JMS provider.

Username/Password

Specify the login credentials for the JMS provider, if applicable.

Additional initial context JNDI properties

Specifies any additional JNDI properties you want applied to this deployment.

Using Global JMS Connections

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.

JMS Message Type Support

The built-in JMS message listener receives and responds to javax.jms.TextMessage message types.

Behavior of Virtual Assets Deployed Over JMS

The JMSMessageID of the request message will be sent as the JMSCorrelationID of the response message.

Virtual assets deployed over JMS can be invoked simply by having the application send or publish the messages to the specified destination as usual. Virtualize will consume messages on that destination. If a value is specified in the Message Selector Expression field, it will consume any message that matches the specified expression.

Browsing Queue Contents - Debugging and Testing of Virtual Assets Deployed Over JMS

When debugging the environment and testing 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 behavior.For details, see Browsing Queues (SOAtest) or Browsing Queues 1 (Virtualize).

MQ Settings

Virtual assets can emulate services that communicate over IBM WebSphere MQ queues if you configure the necessary MQ settings. Refer to IBM WebSphere MQ for additional details.

You can specify the following MQ settings.

Get queue

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

Put queue

Specify the queue to which Virtualize sends (also referred to as "put" or "push") the response message and choose your connection settings rom 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).

Use replyToQueueName for Response

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 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 Use replyToQueueName for Response 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 Use replyToQueueName for Response is enabled and either MQMD.replyToQueueManagerName or MQMD.replyToQueueName is 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.

Message selector 

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

Worker count

Worker count impacts the number of listener worker threads that get created. See Adjusting the Worker Count for details.

Local Settings

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 choose the queue from the Settings drop-down menu (see Using Global MQ Queues).   

Mode

Choose one of 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. 
  
  
  
  

Host (Default Mode)

Specify the MQ queue manager host.

Port (Default Mode)

Specify MQ queue manager port.

Channel (Default Mode)

Specify MQ queue manager channel.

CCDT File (CCDT Mode)

Specify the location of the client channel definition table file, which provides connection details. 

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 are configuring a virtual asset that is currently deployed on a local server but will later be deployed on a remote server, we recommend keeping the CCDT file alongside the .pva file. You will need to deploy the CCDT file to the remote server before deploying the virtual asset to that remote server. See Transferring Files Between the Remote Server and the Local Machine for details.

Queue manager

Specify the queue manager’s name.

Username

If login credentials are required, specify the user name in this field.

Password

If login credentials are required, specify the password in this field.

Using Global MQ Queues

If you want to configure queues deployed on different MQ servers within a single virtual asset (e.g., 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 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 behavior.

For details, see Browsing Queues 1.

Adjusting the Worker Count

Each worker creates its own connection to the MQ/JMS 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 virtual asset is listening on. Whenever an asset 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 virtual asset is parallelized, so each worker thread will do message correlations, response message generation, etc. 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 in Tomcat server.xml.

When subjecting Virtualize to a high number of concurrent virtual users (i.e. during a load test), you can usually expect better performance by increasing these values.

Configuring Custom Transport Virtual Asset Settings

You can configure settings for custom listeners in the Custom tab. 

If only one custom listener is available, this tab will be dedicated to configuration for that custom format:

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. 

Performance Tab

See Working with Performance Profiles.

Data Source Tab

See Working with Data Groups.

Configuring Virtual Database Deployment Settings

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 Specifying which Virtual Asset the Parasoft JDBC Driver Calls. 

It is possible to have more than one virtual asset with that same path. In this case, Virtualize will find the virtual asset and SQL Responder that corresponds to the incoming query. 

It is also possible to have a single database recording used by multiple virtual assets, each of which is deployed at a different path/endpoint. This way, if you have three different AUTs—all of which need to access the same virtualized database behavior—you can create three different virtual assets from that same recording, then point each AUT to a separate virtual asset (deployed at a separate endpoint).