This topic provides details specific to working with a remote Virtualize Server.

Sections include:

For an overview of local vs. remote Virtualize servers, see Dedicated (Remote) Virtualize Servers vs. The Local Virtualize Server.

This functionality assumes that the same version of Parasoft Virtualize is available on the Virtualize desktop and the remote Virtualize Server. Subminor version differences (i.e. these from service packs) do not impact interoperability.

Starting and Stopping the Server

To work with a dedicated Virtualize server, you start Virtualize in server mode from the designated server machine, then you interact with it from the various desktop Virtualize installations that your team uses.

Starting the Server

To set up a dedicated Virtualize server:

Install Virtualize Server on the machine that you want to act as a dedicated Virtualize server.
On that same machine, start Virtualize in Virtualize server mode by using a command such as:
"virtualizecli -startServer -data <workspace_dir> -settings
<settings_file>" file

You can use the following command line options with virtualizecli:

-StartServer: Starts the local Virtualize server from the command line.
-data: Specifies the Eclipse workspace location. If the -data option is not used, then the default workspace found under [Virtualize_workspace]\parasoft\workspace (where"Virtualize_workspace" could be C:\Users\yourname) will be used.
-settings: Controls various settings for Virtualize, CTP, licensing, and more. You can use the same options available across Parasoft Test products (e.g., Parasoft SOAtest). You can also use options that are specific to Virtualize and CTP. See Settings for details.
-prefs: Reads the %PREFS_URL% preference URL to import Eclipse workspace preferences.%PREFS_URL% is interpreted as a URL or the path to a local Eclipse workspace preferences file. For example:
-prefs "http://intranet.acme.com/Virtualize/workspace.properties" -prefs "workspace.properties"

-disableEventMonitoring: Disables all event monitoring for this server.
-machineid: Prints the machine ID, which is used for licensing purposes.
-Dparasoft.async.support.mode=<mode>: This property sets the asynchronous processing mode. Asynchronous processing enables better concurrency when responders are configured with delays (e.g., in performance profiles). JMS, MQ and Http Listeners support asynchronous processing. You can specify the following modes:
- ON - all requests are processed asynchronously
- DELAY - only responses that have a delay are processed asynchronously, default
- OFF - no asynchronous processing

-Dparasoft.async.support.workers: The number of worker threads for performing asynchronous processing. Default is 200.

When starting Virtualize in this way, the Start deactivated, release automatically when idle option (in Parasoft> Preferences> Parasoft> License) needs to be disabled. Otherwise, you won’t be able to add this server from another Virtualize installation’s UI.

The Virtualize server is controlled by a web service with the URL http://localhost:9080/axis2/services/StubService?wsdl. For details about this web service’s operations, see Managing Virtualize Servers Through the Web Service Interface.

Stopping the Server

To stop a dedicated Virtualize server:

Invoke the "shutdown" operation from the Virtualize web service.

Use the following command to stop the local Virtualize server using the shutdown port. The port is configured in the server.xml. The default port is 9616.

virtualizecli -stopServer

Interacting with a Remote Virtualize Server from the Parasoft Virtualize Desktop

To configure a desktop Virtualize installation to interact with a remote Virtualize server (e.g., so you can view and add virtual assets):

Click the Virtualize Server view tab (if it is not already open, go to Window> Show View> Virtualize Server to open it).
Do one of the following:
- Right-click the Server node, then choose Add Server.
- Select the Server node, then click Add Server.
In the Add Server dialog that opens, specify the server’s host name, display name (shown in the Virtualize server tree), protocol, and port.
- If your team has implemented user access control, enter your username and password as well, unless OpenID Connect has been enabled for authentication (see OpenID Connect under Preferences).
Click OK.

The server will then be added to the list of servers—allowing you to add virtual assets and configure virtual assets that run on this server.

SOAtest and Virtualize with CTP 2022.1 > Working with a Remote Dedicated Virtualize Server > 37.png

Deploying Virtual Assets

For instructions on how to deploy virtual assets to a remote Virtualize server, see Local and Remote Deployment Options.

When a virtual asset is deployed to a remote Virtualize server, the .pva file is written to the VirtualAssets project of the workspace being used by the remote Virtualize server.

Transferring Files Between the Remote Server and the Local Machine

Each remote server provides a Workspace Files folder designed to allow easy transfer of files between remote Virtualize servers and the local machine. For instance, you can use it to:

Transfer recorded traffic files from a remote server to your local machine (where you can create Message Responders from the recorded traffic).
Transfer data sources that you have prepared on your local system to a remote server that is hosting virtual assets which use those data sources.
Transfer keystores files from the local system to a remote server.
Transfer CCDT files from the local system to a remote server.

Any files that are in your local VirtualAssets project will be synchronized with this folder. In addition, you can:

Drag and drop files from the remote Files folder to the Local Machine (in the Virtualize Server view).
Drag and drop files from the Virtual Asset Explorer or Navigator views to the remote Files folder to the Local Machine (in the Virtualize Server view).
Right-click a file in the remote Files folder and copy it to your workspace.

Collecting Server Statistics

If your organization wants to monitor asset usage statistics for this server, you can configure the server to collect statistics, then view the collected statistics from either Virtualize or the CTP interface.

Server statistics collection can help you:

Track PVA/responder usage levels and patterns from different groups/divisions over time.
Assess how close you are to reaching the licensed number of hits.
Determine how Virtualize response times influence your performance testing results.

Enabling Statistics Collection

To view and modify server statistics collection:

Start Virtualize Server in GUI mode.
In that GUI, open the configuration panel for the server you want visibility into (double-click its Virtualize Server view node).
In the Server Configuration tab, review and modify the available options:
- Enable the statistics collection service: Enables/disables statistics collection for this server. Collection is enabled by default.
- Statistics provider: Specifies the provider that the statistics service uses. By default, a built-in provider based on ActiveMQ is used. To use another provider, select it from the list of available options, then complete the applicable fields.
- Port: The default service port number 9618. If that port is in use, a different port number will automatically be assigned based on availability. You can also configure the port by setting the following property in your JVM arguments on startup:
  parasoft.server.statistics.broker.port=<port>
- Collection period: Determines the frequency (in seconds) at which statistical usage messages are aggregated and reported.

Reviewing Server Statistics

To see a summary of server statistics in Virtualize, open the Virtualize server’s configuration panel, then review the statistics in the Monitoring tab.

SOAtest and Virtualize with CTP 2022.1 > Working with a Remote Dedicated Virtualize Server > 1.jpg

"Unrecognized" refers to messages that were received by the Virtualize server, but did not match the listening paths on any virtual asset or HTTP proxy.

"Unmatched" refers to request messages that matched a virtual asset, but failed to match any responder correlations. The unmatched hits are grouped according to the request’s source IP/host and the first virtual asset that attempts to serve this request.

Additional details are available for viewing and export in CTP:

SOAtest and Virtualize with CTP 2022.1 > Working with a Remote Dedicated Virtualize Server > 2.jpg

Accessing a Virtualize Server through its API

By interacting with the Virtualize API, you can write custom applications that interact with the Virtualize server. For details, see Managing Virtualize Servers Through the Web Service Interface.