...
| Table of Contents | ||
|---|---|---|
|
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.
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.
...
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.
| Anchor | ||||
|---|---|---|---|---|
|
When the AUT within an environment uses SSL to connect to a dependency that needs to be virtualized, there are several options:
...
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:
...
| Info | ||
|---|---|---|
| ||
|
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.
...
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 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).
...
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.
| Anchor | ||||
|---|---|---|---|---|
|
You can configure various preferences and settings for a Virtualize server in the server configuration panel. To open this panel:
...
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
| Anchor | ||||
|---|---|---|---|---|
|
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 Server and Deployment JMS Settings and Configuring Server and Deployment 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 virtual asset using JMS:
| Anchor | ||||
|---|---|---|---|---|
|
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 Server and General Virtual Asset Deployment Settings
- Configuring Server and Deployment HTTP Settings
- Configuring Server and Deployment JMS Settings
- Configuring Server and Deployment MQ Settings
- Configuring Server and Deployment Custom Transport Virtual Asset Settings
- Configuring Server and Deployment Performance Settings
- Configuring Server and Deployment Data Source Settings
- Configuring Server and Virtual Database Deployment Settings
| Info | ||
|---|---|---|
| ||
For details on customizing virtual asset behavior (e.g., how to customize virtual assets with different request/response use cases, error conditions, and so forth), you customize the related Message Responder tools as described in Message Responder Overview. |
| Anchor | ||||
|---|---|---|---|---|
|
In the General tab, you can specify:
...
| Info | ||
|---|---|---|
| ||
Before deploying virtual assets over JMS and/or MQ, be sure to add the appropriate jar files to the Virtualize classpath. For details on how to do this, see System Properties Settings. |
| Anchor | ||||
|---|---|---|---|---|
|
You can specify the following HTTP settings:
...
| Option | Description |
|---|---|
| Path | If you specify a value here, the virtual asset will listen for incoming messages on the HTTP path specified. If no value is specified, then only JMS, MQ or custom transport listener settings will be applied for receiving messages. To change the port number, see Using an Alternative Port for the Virtualize HTTP Server. To enable SSL (through HTTPS), see Configuring Server and Deployment SettingsSSL (HTTPS) for the Virtualize Server. 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 Wild cards are supported for replacing an entire segment of a path. For example:
|
| 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. |
| Anchor | ||||
|---|---|---|---|---|
|
A virtual asset can be configured to receive messages from (and send messages to) a queue or a topic.
...
| Option | Description |
|---|---|
Messaging Mode | Messaging Model options specify how messages are sent between applications. Select either Point to Point or Publish and Subscribe, then specify the settings in the appropriate area. For example, for point-to-point, you will specify Destination and replyTo queues. For publish and subscribe, you will specify Publish and Subscribe topics. You can then either enter the settings for each connection in this panel (via the Local Settings option) or reference a global JMS connection defined at the Virtualize server level (see Reviewing and Configuring Server and Deployment Settings in the Server Configuration Panel for details) |
| Use JMSReplyTo for response | This option specifies whether 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 |
| Worker count | Worker count impacts the number of listener worker threads that get created. See Configuring Server and Deployment Settings Adjusting the Worker Count for details. |
| 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 | Enter if needed. |
| JNDI Properties table | Specifies any additional JNDI properties you want applied to this deployment. |
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 Configuring Server and Deployment Settings 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_virt.
| Anchor | ||||
|---|---|---|---|---|
|
Virtual assets can emulate services that communicate over IBM WebSphere MQ queues if you configure the necessary MQ settings.
...
| Option | Description |
|---|---|
| Get queue | Specifies the queue that Virtualize retrieves the request message from (also referred to as get or pull). Note that a single virtual asset can use queues that are deployed on different MQ servers; for details, see Using Global Queue Managers. |
| Put queue | Specifies the queue to which Virtualize sends (put or push) the response message. Note that a single virtual asset can use queues that are deployed on different MQ servers; for details, see Using Global Queue Managers. |
| Use replyToQueueName for Response | This option specifies whether 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 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. See Using Message Selector Filters for tips. |
| Worker count | Worker count impacts the number of listener worker threads that get created. See Configuring Server and Deployment Settings Adjusting the Worker Count for details. |
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.
...
| Option | Description |
|---|---|
| CCDT file | Specifies the location of the CCDT file (with a .tab extension). If the virtual asset 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 "Files" node in the Virtualize Server tree. If the virtual asset 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 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. Note that 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 | Specifies the queue manager’s name. |
| Username/Password | Enter if needed. |
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 Configuring Server and Deployment Settings 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_virt.
| Anchor | ||||
|---|---|---|---|---|
|
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).
...
The worker count feature is equivalent to the “maxThreads” attribute in Tomcat server.xml; see Configuring Server and Deployment SettingsSSL (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.
| Anchor | ||||
|---|---|---|---|---|
|
You can configure settings for custom listeners via the Transports> Custom tab.
...
See “Extending Virtualize with Custom Transports and Message Formats”, page 253.
| Anchor | ||||
|---|---|---|---|---|
|
See Working with Performance Profiles.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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 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).
| Anchor | ||||
|---|---|---|---|---|
|
By default, the local Virtualize server uses port 9080. To change this:
...