This topic explains how to configure deployment settings for Virtualize servers—and for the virtual assets deployed upon them.

Sections include:

Configuring Virtualize Server Startup and Authentication Options

You can configure additional settings (for example, startup, authentication, and CTP notification options) from the Preferences panel as described in Server Settings.

Security Considerations

Be sure to deploy the Virtualize server in a secure manner. The Virtualize server hosts web services that can be used to manage virtual assets. This means that any host with network access to the Virtualize server can add, modify, or remove virtual assets hosted by that Virtualize server—unless a connection to CTP is configured, in which case, access controls will be enforced.  see Configuring user Access Control for Virtualize Servers for details).

We generally recommended that you deploy the Virtualize server on a trusted network. A proxy server or gateway could also be used in front of the Virtualize server to add layers of security other than what is provided by the Virtualize server.

The Virtualize server's HTTPS port (9443) should be used when sending login credentials. 

Extra caution should be taken if deploying a Virtualize server on an untrusted network such as the Internet. We recommend that you use a firewall to block unacceptable access (such as restricting access by IP addresses). A proxy server or gateway could also be used in front of the Virtualize server to add authentication, filtering, and logging.

Configuring SSL (HTTPS) for the Virtualize Server

When the AUT within an environment uses SSL to connect to a dependency that needs to be virtualized, there are several options:

1. 1. Configure Virtualize Server with a generated (possibly self-signed) certificate and add it to the trust store of the AUT.
   2. Add your actual server certificate to Virtualize. This option assumes that access to the server certificate and keys is possible—and changes to the AUT are difficult or shouldbe avoided. However, this option may not be possible if the certificate was signed for a hostname other than the hostname where Virtualize is deployed.
   3. (preferred) Create a certificate for the Virtualize server, sign it with a certificate authority that is trusted by the AUT, and issue it for the host where the Virtualize server is installed. With this option, you don’t need to make any changes to the AUT.
   4. Disable certificate trust in the AUT. The AUT would still connect over SSL but trust any server (such as the Virtualize server) without validating its certificate or its trust paths.

For the AUT to accept a certificate/private key pair, you generally need—at minimum—a self-signed certificate/private key pair whose common name (CN) parameter matches the fully-qualified name of the server. For example, if your Virtualize server URL is http://myserver.mycompany.com, the CN parameter should be "myserver.mycompany.com".

In any case, Virtualize can be configured to accept incoming HTTPS connections on port 9443 (default SSL connector) or another port. 

Editing server.xml

SSL details can be configured by modifying the SSL HTTP/1.1 Connector entry in server.xml. For example:

<Connector port="9443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="C:/Path To Keystore/virtualize.pfx"
keystorePass="security" keyAlias="virtualize" keystoreType="PKCS12" truststoreFile="../lib/cacerts"
truststorePass="changeit" truststoreType="JKS" />

Updating keystoreFile

If option (b) is being followed, the keyStoreFile attribute should be changed to point to the same keystore file as the actual SSL-based service that you want to emulate. Use forward slashes (/) instead of backward slashes (\).For example, C:/Users/myUser/keystore.jks.

If option (a) or (c) is being followed, use the path to the generated server keystore. Although the keystore paths can be relative to the location of the server.xml file, it is best to provide absolute paths in order to ensure correct configuration. 

With option (d), you do not need to modify the keyStoreFile attribute.

Updating keystorePass, keyAlias, and keystoreType

The keystorePass, keyAlias, and keystoreType attributes should be updated accordingly:

• Modify keystorePass to be the password to your keystore
• Modify keyAlias to point to the alias of the certificate/private key pair
• Modify keystoreType to PKCS12, JKS, BKS, UBER, or PEM—depending on the type of keystore you're using

For two-way SSL (mutual authentication), the clientAuth attribute must be set to true and the trust store used for validating client certificates should be specified using the truststoreFile, truststorePass, and truststoreType attributes:

• Modify truststoreFile to point to your keystore file. Use forward slashes (/) instead of backward slashes (\). For example, C:/Users/myUser/keystore.jks
• Modify truststorePass to be the password to your keystore
• Modify truststoreType to PKCS12, JKS, BKS, UBER, or PEM—depending on the type of keystore you're using

Additional Configuration Details

For more details on how to enable and configure the SSL connector, see the Apache Tomcat documentation (http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html).

It is possible to configure more than one port number for SSL. This is typically the case if different keystore/certificate configurations need to be "virtualized."

The default SSL connector (the one with attribute name="default") port number should be changed in the Virtualize server preferences (see Server Settings for details). When Virtualize starts, the preferences settings will take precedence over the server.xml settings.

You may add additional Connector elements to server.xml with distinct names and distinct SSL/certificate configurations as needed. Virtual assets and proxies cannot be mapped to specific Connector ports. A message received on a particular connector/port could be processed by any virtual asset based on header, URL and message content correlation criteria within the virtual asset path, proxy path or responder correlation rules, but not based on the port.

Reviewing and Configuring Server Settings in the Server Configuration Panel

You can configure various preferences and settings for a Virtualize server in the server configuration panel. To open this panel:

1. Start Virtualize Server in GUI mode.
2. In that GUI, open the configuration panel for the server whose settings you want to review.

From this panel, you can review and modify settings related to monitoring, server statistics, global JMS and MQ connections, and user authentication (for remote servers only). 

Monitoring Tab

This tab displays a summary of Virtualize server statistics. See Collecting Server Statistics for details.

Server Configuration Tab

This tab allows you to configure event monitoring and statistics collection settings. See Gaining Visibility into Server Events and Collecting Server Statistics for details.

Connections Tab

This tab allows you to define multiple JMS connections and MQ queue managers that you plan to use across proxies and virtual assets on this server.

Defining Global Connections

From this tab, click the appropriate Add button to add a JMS connection or MQ queue manager. The fields to complete here are also used in the virtual asset or proxy configuration panels. See Configuring JMS Settings and Configuring MQ Settings for details on the applicable fields.

Using Global Connections

After you add a connection, you will be able to select it from the proxy and virtual asset configuration panel.

For example, this shows how to select a global connection for a proxy using MQ:

For example, this shows how to select a global connection for a virtual asset using JMS:

Authentication Tab

For remote servers only

This tab allows users to re-enter credentials (e.g., if their roles were changed via CTP). For details, see Re-Entering Credentials for an Existing Server.

Configuring Individual Virtual Asset Deployment Settings

Individual settings can be configured by double-clicking a specific virtual asset listed in the Virtualize Server view—or by right-clicking it and choosing Open. 

You can then configure options as described in:

• Configuring General Virtual Asset Deployment Settings
• Configuring HTTP Settings
• Configuring JMS Settings
• Configuring MQ Settings
• Configuring Custom Transport Virtual Asset Settings
• Configuring Performance Settings
• Configuring Data Source Settings
• Configuring Virtual Database Deployment Settings

Configuring General Virtual Asset Deployment Settings

In the General tab, you can specify:

Configuring HTTP Settings

You can specify the following HTTP settings:

Configuring JMS Settings

A virtual asset can be configured to receive messages from (and send messages to) a queue or a topic.

• 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 JMS settings:

Using Global JMS Connections

Global JMS 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 JMS connection, select it from the Settings box. 

To review the details of a predefined global connection, click View settings.

Message Type Support

The built-in JMS message listener supports receiving and responding with messages of type javax.jms.TextMessage.

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

Configuring MQ Settings

Virtual assets can emulate services that communicate over IBM WebSphere MQ queues if you configure the necessary MQ settings.

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

You can specify the following MQ settings:

If the Settings option for the get queue and/or put queue is set to Local Settings, you will see additional options in the Local Settings section on the right.

This is where you specify queue connection details using one of two 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:

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

For a local server:

For a remote server:

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.

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; see Configuring SSL (HTTPS) for the Virtualize Server for details on where to find the server.xml for Virtualize’s Tomcat.

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 via the Transports> 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 box, then use the available controls to configure it as needed. 

Configuring Performance Settings

See Working with Performance Profiles.

Configuring Data Source Settings

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

Using an Alternative Port for the Virtualize HTTP Server

By default, the local Virtualize server uses port 9080. To change this:

1. Choose Parasoft> Preferences.
2. Open Parasoft> Server.
3. Change the port settings.
4. Restart the server.

Configuring User Access Control for Remote Access to the Parasoft Virtualize Server

For details on how to govern what actions each user can perform on the Virtualize Servers connected to his or her Virtualize Desktop installation, see Configuring user Access Control for Virtualize Servers.