This topic explains how to work with Virtualize (and SOAtest) environments. Environments are collections of variables that can be referenced within fields of your responder suite or action suite (Virtualize) and test configuration (SOAtest). By switching which environment is the "active" environment, you can dynamically switch the environment-specific values in Virtualize or the values of your SOAtest test configurations at runtime.
Sections include:
An environment is a collection of variables that can be referenced in your Virtualize Responder suite or action suite. An environment might specify endpoints, connection properties such as usernames and passwords, database table names, etc. Virtualize will substitute the names of variables with the values assigned to those variables in the active environment. By changing which Environment is active, you can quickly and easily change which set of values Virtualize uses. Environments can also be used to switch virtual asset modes. For example, assume you configured a responder to forward traffic to an external endpoint. By using an environment variable for the endpoint (instead of a fixed value), you can easily redirect message forwarding to different endpoints. This allows .pva files to act like proxies; one environment can point to a real asset while another points to a virtual asset. Environments are defined when you automatically generate a Responder suite (e.g., from a WSDL). In addition, you can manually define one as described below. Creating and switching environments is done through the Environments branch of the Responder suite’s Virtual Asset Explorer node. The Environments branch is created by default when a new Responder suite is created. To add a new environment: Environment variables can be accessed in test or tool configuration fields using a special syntax. To reference a variable, enclose the variable name in the following character sequence: For example, if you have a variable named HOST, you would reference the variable in a field by typing: Note To change what environment is active: You may find that many configuration settings, such as server names and ports, will be common across multiple projects. Rather than duplicating these settings, you can export environment settings to an external file and import or reference the values in other projects. To export an environment: The environments configuration will be written in an XML-based text file. If one Environment is selected, a When you import environments, you are bringing a copy of the values from the external environment file into your project. Further modification to the XML file will not be reflected in your project. To import an environment: Referencing environments is the most efficient way to share a single environment configuration across multiple projects. Using environment references, you can easily modify the configurations of multiple projects from a single location. To reference an environment: Note that when an environment configuration is referenced, you cannot edit the environment variables in the environment directly. However, your project will always use the values reflected in the referenced Understanding Virtualize Environments
Manually Defining an Environment in Virtualize
Using Environment Variables in Tests and Tools
${env_name}
.${HOST}
. Variable references may appear anywhere within a field.You can access Environment Variable values from a Extension Tool/Script through the Extensibility API. ExtensionToolContext now has a method called "getEnvironmentVariableValue(String)
" which will lookup and return the current value of an Environment variable. This will allow you to use the value within your scripts.${}
, you can escape the sequence by adding a backslash. For example, if SOAtest or Virtualize encounters the value "\${HOST}
" it will use the value "${HOST}
" and will not try to resolve the variable. Also note that environment variable names are case sensitive.Changing Environments from the GUI
Exporting, Importing, and Referencing Environments
Exporting Environments
*.env
file will be created, containing a single environment. If multiple environments are selected, a *.envs
, or Environment Set, file will be created containing all of the selected environments.Importing Environments
Referencing Environments
*.env
file. Modifying the *.env
file will propagate changes to all projects that reference it.