This topic introduces the Virtualize Server view, which is where you manage and interact with local or remote Virtualize servers, as well as the virtual assets and proxies that are deployed on them. Topics include:
Understanding the Virtualize Server View
The Virtualize Server view is where you manage and interact with local or remote Virtualize server, as well as the virtual assets and proxies that are deployed on them. From here, you can start/stop servers, start/stop event monitoring, and create/modify/interact with message proxies (e.g., to start or stop recording) as well as Parasoft JDBC Drivers (e.g., to switch between passthrough, record, virtualize, and hybrid modes). For remote servers, it also provides a Files folder designed to allow easy transfer of files between remote Virtualize servers and the local machine.
To open the Virtualize Server view, choose Window> Show View> Virtualize Server. For an overview of the available buttons and commands, see Virtualize Server View - GUI Reference.
The Virtual Assets node in this view is always synchronized with the VirtualAssets project. If the VirtualAssets project includes any .pva files, the corresponding virtual assets will be automatically added to this view’s Virtual Assets node. If virtual assets are organized into a hierarchical structure via the controls in the Virtualize Server view (as described in Organizing Deployed Virtual Assets), those same structural changes will be automatically applied to the VirtualAssets project.
Also note that icons and labels are used to indicate server access and licenses. If your team is using user access control, Virtualize Server view labels indicate your access level to each server. For details on what operations are allowed for each access level, see Understanding Role-Based Permissions.If you have a developer sandbox license (designed for modelling and testing virtual assets), a special icon will be used to mark that server.
Icons also alert you if an artifact is locked—and if so, by which user (and at what access level). For details on how to lock and unlock artifacts, see Locking and Unlocking Virtualize Server Artifacts.
Configuration details for each virtual asset, message proxy, and JDBC controller deployment on the local Virtualize server are saved within a separate XML file within your workspace directory. These files are automatically named based on the deployment name, and use the following extensions: .pvadd (virtual assets), .pmpdd (message proxies), or .pjcdd for (JDBC controllers).
For details on the operations that can be performed from the Virtualize Server view, see the folowing related topics:
- Working with Virtual Assets in the Virtualize Server view: Deploying Virtual Assets.
- Working with Message Proxies in the Virtualize Server view: Enabling and Disabling Proxies.
- Working with Parasoft JDBC Drivers in the Virtualize Server view: Switching Parasoft JDBC Driver Modes.
Refreshing the Virtualize Server View
Refreshing virtual assets ensures that the Virtualize Server view’s tree is in sync with the deployed virtual assets and any changes to the VirtualAssets project.
To refresh the entire Virtualize Server view, do one of the following:
- Right-click the Server node, then choose Refresh from the shortcut menu.
- Select the Server node, then click Refresh.
To refresh a particular Virtualize server (e.g., to display virtual assets recently added by a team member):
- Right-click the related node in the Virtualize Server view, then choose Refresh from the shortcut menu.
Virtualize Server View - GUI Reference
The Virtualize Server view’s toolbar provides the following buttons:
|Start Server||Starts the local server.|
|Stop Server||Stops the local server.|
|Refresh||Refreshes all servers in the tree.|
|Add Server||Allows you to add a remote server to the Virtualize Server view.|
Shortcut (Right-click) Commands
The following shortcut (right-click) commands are available within the Virtualize Server view:
- From the Server node:
- Start Server: Starts the local server.
- Stop Server: Stops the local server.
- Refresh: Refreshes all servers in the tree.
- Add Server: Allows you to add a remote server to the Virtualize Server view.
- From the Local machine node:
- Open: Opens a panel that allows you to configure advanced settings for the local Virtualize server. See Configuring Server and Deployment Settings for details.
- Refresh: Refreshes the local Virtualize server.
- Add Virtual Asset: Allows you to add a virtual asset to the local Virtualize server.
- Re-deploy All Virtual Assets: Re-deploys virtual assets so that modifications are "live."
- From a remote server node:
- Open: Opens a panel that allows you to configure advanced settings for the given Virtualize server. See Configuring Server and Deployment Settings for details.
- Refresh: Refreshes the given server (e.g., to keep it in sync with virtual assets added or removed by other team members).
- Add Virtual Asset: Allows you to add a virtual asset to the given server.
- Re-deploy All Virtual Assets: Re-deploys virtual assets so that modifications are "live."
- Remove Server: Removes a remote server from the Virtualize Server view.
- From a specific virtual asset node (local machine or remote server):
- Open: Opens a panel that allows you to configure advanced deployment settings for the given virtual asset. See Configuring Server and Deployment Settings for details.
- Copy: Allows you to copy a virtual asset so you can paste it from one server to another.
- Paste: Allows you to paste a copied virtual asset from one server to another.
- Disable: Disables the virtual asset (so it is still present, but cannot be accessed).
- Delete: Deletes the virtual asset from the given server.
- Start monitoring/stop monitoring: Tells Virtualize to start/stop reporting the events related to a virtual asset. See Gaining Visibility into Server Events for details.
- Re-deploy Virtual Asset: Re-deploys this virtual asset so that modifications are "live."
- Lock/Unlock: Adds or removes locks that prevent other users from modifying or deleting an artifact you’re working on. See Locking and Unlocking Virtualize Server Artifacts for details.
- Copy to workspace: Copies this virtual asset to your workspace so you modify it.
- Unprocessed Messages: Shows details on messages that were sent, but not processed.
Locking and Unlocking Virtualize Server Artifacts
Virtualize lets you lock artifacts that you're working on to ensure that they are not modified or removed by other users. This functionality is available only if the remote Virtualize Server hosting those artifacts authenticates with Parasoft CTP using a valid username and password. It is supported only when a) the connection to CTP is successful, and b) CTP does not allow anonymous access.
Locking/unlocking functionality is available for artifacts on remote Virtualize Servers (not those on the local machine). Locking/unlocking functionality applies to virtual assets, message proxies, JDBC controllers, and files. Locking/unlocking functionality is also available for Data Repositories; see Locking and Unlocking Repositories in CTP for details.
Any authenticated user can lock a currently-unlocked artifact, modify an artifact that he or she locked, and unlock an artifact that he or she locked.
Admin-level users can also unlock any artifact (no matter which user applied the lock). However, they cannot modify artifacts that other users locked. If they wanted to modify a locked artifact, they would need to unlock it first, then modify it.
Authenticating with CTP
The Virtualize server authenticates with CTP using the credentials specified in that server’s Preferences> Parasoft> CTP. You do not need to enter any CTP credentials from your desktop installation. Just be sure that you specified a valid username and password for connecting to that remote Virtualize server.
Locking and Unlocking Artifacts
To lock an artifact:
- Right-click that artifact in the Virtualize Server view, then choose Lock.
A lock image will be added to the associated artifact icon, and the label will indicate that this artifact is now locked by you. At this point, you are the only one who can modify or delete this artifact.
To unlock an artifact:
- Right-click that artifact in the Virtualize Server view, then choose Unlock. Remember that unless you are an Admin-level user, you can unlock only the artifacts that you previously locked.
Migrating Workspaces from 9.9.3 or Earlier
Virtualize 9.9.3 and earlier saved configuration details for all of the local Virtualize server’s virtual assets, message proxies, and JDBC controllers in single XML file (VirtualAssets.xml) within your workspace directory.
Virtualize 9.9.4 and higher saves configuration details for each virtual asset, message proxy, and JDBC controller deployment on the local Virtualize server within a separate XML "deployment descriptor" file within your workspace directory. This change relieves you from having to use globally-unique names and makes it easier to:
- Associate a deployment with an artifact.
- Perform fully-automated headless installation.
- Configure clustered environments.
If you open a workspace from Virtualize 9.9.3 or earlier in Virtualize 9.9.4 or higher, this migration from a single VirtualAssets.xml files to multiple deployment descriptor files will occur automatically. The deployment descriptor files are automatically named based on the deployment name, and use the following extensions: .pvadd (virtual assets), .pmpdd (message proxies), or .pjcdd (JDBC controllers). If the original virtual asset, message proxy, and JDBC controller name contains characters that are not valid for the new format, the name will be automatically adjusted; for example,
asset#3 would be renamed to
- Back up the VirtualAssets.xml file before the migration.
- If you have a cluster, start with a single node then continue migrating node by node. Migrating the full cluster at once is not recommended.