This topic provides an overview of issues related to SOAtest' s and Virtualize’s extensibility (scripting) capabilities and their various applications. Sections include:

Understanding the Extensibility Feature

The SOAtest & Virtualize extensibility feature allows you to apply custom scripts (using Java, JavaScript, Oracle Nashorn, Groovy, or Jython) to perform any specific function that would be helpful to you while working with SOAtest & Virtualize. It also supports other scripting engines that implement the JSR 223 "Scripting for the Java Platform" specification. This feature gives you the ability to customize SOAtest & Virtualize to your specific needs without learning an application-specific language.

If you work with SOAtest, you can also use scripting to customize rules you create with RuleWizard. For details on this feature, see the RuleWizard User’s Guide.

Setting Your Environment for Scripting

If you are using Jython scripts, you might need to specify your jython.home and jython.path variables in the Scripting tab of the Preferences panel. Both variables are used to locate Jython modules, and Jython code that does not import any Jython modules can use the Jython scripting support without setting either variable. jython.home specifies the Jython installation directory. jython.path is used to add to your path modules that are not in your jython.home/Lib directory. Multiple paths can be listed in jython.path, while jython.home must be a single directory. If you set the jython.home and jython.path variables, you need to restart SOAtest or Virtualize before the changes will take effect.

If you are using Java for scripting and want to use Virtualize to recompile modified Java files, see Using Eclipse Java Projects in Virtualize for details on how to set your environment on scripting.

Specifying the Script

To define a script from SOAtest or Virtualize GUI controls that provide a scripting option:

  1. If your Java class is from a Java project in your Eclipse workspace, add the Java project to the classpath. 
  2. From the Language box, indicate the language that the script will use.
  3. Define the script to be implemented in the large text field.

Using Script Templates

If you create scripts using Jython or JavaScript, you can specify a script template in the SOAtest  or Virtualize Preference panel’s Script Template field (in the Scripting page). Whatever code is specified in this field will be used as the default code for inlined scripting in the language with which the field is associated. This is primarily useful for setting default inputs and common global variables.

Script templates apply to scripts used in Extension tools, SOAP services, and scripted SOAP inputs.

Interacting with SOAtest and Virtualize

If you need your scripts to interact with the SOAtest or Virtualize program, you can do so using the SOAtest or Virtualize Extensibility API. For example, you can use the SOAtest or Virtualize Extensibility API to send results of a script to a SOAtest or Virtualize Message window or pass specific values to specific SOAtest or Virtualize.

You can access documentation for the Extension framework API via the Parasoft> Help menu (look for the book titled "

Accessing Required Jar Files

If your Java code uses the Extensibility API and you want to compile the code within the


environment, use the Java Project wizard. This wizard will create a new Eclipse Java project that has access to the Extensibility API. For details, see 

Using Eclipse Java Projects in Virtualize

for details.

If you want to compile the code outside of the


 environment, you will need the following jar files:

These jar files are available at


<Virtualize Installation Directory>\plugins\com.parasoft.xtest.libs.web_<Virtualize version>\root

If you’re building your Java project with Apache Maven,  you can add the following to your project's pom.xml:

		<version>9.9.0</version>  <!-- should match product version -->
  </dependencies>   ...
		<name>Parasoft Public Repository</name>

Additionally, if scripts need to use other functionality beyond these API classes, you may need to add additional (3rd party or open source) jars to your classpath. For example:

Setting the Context Classloader

The Extension tool runs in the classloaders. Certain APIs, such as JNDI, are sensitive to the context classloader. There may be cases where your code must explicitly set the context classloader before performing a particular API call. For more information, see

Script Variables

You can declare and use variables in SOAtest and Virtualize scripts.

Variable declaration must start with a keyword "var" followed by an equals sign "=" followed by a variable value. Each variable must be declared on a separate line. Variables can be declared anywhere in the script, a variable can be used immediately after its declaration. To assign an existing variable a new value, "re-declare" the variable.

A variable can be referenced in a script as follows: ${varName}.

Configuring Jython Preferences

Jython Version

The Jython 2.5.2 version that ships with SOAtest and Virtualize does not include some of the standard Jython libraries, such as the os module. If you are used to using these modules and would like to access to them in SOAtest or Virtualize, you can point SOAtest or Virtualize to an external Jython installation as follows:

  1. Install Jython in a location of your choice; we will refer to this location as <Jython Install Directory>.
  2. Open SOAtest or Virtualize.
  3. Choose Parasoft> Preferences.
  4. Select Scripting.
  5. In the Jython Home field, enter <Jython Install Directory>.

  6. Restart SOAtest or Virtualize.

Jython Syntax Coloring

Jython syntax coloring for the Extension tool is enabled using the PyDev plugin ( This plugin must have its jython interpreter configured for advanced functionality such as code auto completion. For more details, see

Accessing Data Sources from Scripts

If you use SOAtest, you can make a data source available to a script by selecting the data source in the top of the tool’s configuration panel, and then enabling the Use Data Source option.

Within other methods in your script, or within any method in the script if you use Virtualize, store a value from the data source into a variable "x" with the line:

x = context.getValue("Data Source Name", "Column Name")

For more information on scripting, see the documentation for the Extension framework API. Choose Parasoft> Help, then look for the book titled "Parasoft SOAtest Extensibility API" (for SOAtest) or "Parasoft Virtualize Extensibility API" (for Virtualize).

For example, let's say you have a test that looks similar to that in the following image:

The name of the table data source is Data Source Name. Not pictured are the following important facts:

  • The table Data Source Name has a column labeled Column Name.
  • The XML Data Bank contains a column labeled Test 1: Result.
  • The XML Data Bank and Writable Data Source belong to a data source labeled Generated Data Source.

In order to make one of these data sources available to your script, select the data source in the top of the Extension tool’s configuration panel, then check Use Data Source


When opening older files (created prior to SOAtest 6.1), note that Browser Data Bank Tool column names are automatically transformed to "Extracted:xyz", where "xyz" was the column name that you specified. This provides support for legacy scripts that reference "Extracted:xyz". You can change the column name in the Browser Data Bank to just "xyz" or "abc."

For more information on scripting, see the documentation for the Extension framework API. Choose Parasoft> Help, then look for the book titled "Parasoft SOAtest Extensibility API".

Language-Specific Tips




For details on Jython (an implementation of Jython that is integrated with Java), including information on how to write Jython and also how to invoke Java classes from inside Jython, visit Note that SOAtest and Virtualize ship with Jython 2.5.2.


Here is a sample Groovy script:

import com.parasoft.api.*;
boolean customAssertion(Object input, ScriptingContext context) {
    String value = context.getValue("Books", "title");
    Application.showMessage("Value from data source is " + value)
    Application.showMessage("Value from SOAP response is " + input.toString())
    return input.toString().contains(value);

JSR 223 Scripting Languages

 You can configure SOAtest and Virtualize to recognize any scripting engines that implement the JSR 223 "Scripting for the Java Platform" specification.  Oracle Nashorn is available by default; others can be added.

Oracle Nashorn JavaScript 

The Oracle Nashorn ECMAScript engine is available by default because it is included with Java. Here is a sample Oracle Nashorn script:

var Application = Java.type("com.parasoft.api.Application")
function customAssertion(input, context) {
    value = context.getValue("Books", "title");
    Application.showMessage("Value from data source is " + value)
    Application.showMessage("Value from SOAP response is " + input.toString())
    return input.toString().contains(value);

Mozilla Rhino JavaScript 

Mozilla Rhino is the original ECMAScript engine included with the Java runtime.  It is the predecessor to Oracle Nashorn, which has replaced Mozilla Rhino as of Java 8. SOAtest and Virtualize versions prior to 9.10 shipped with Java 7, which included Mozilla Rhino. Scripts saved in earlier versions of SOAtest and Virtualizewith the Mozilla Rhino engine will now run in the new Oracle Nashorn with Mozilla compatibility extensions loaded. The compatibility extensions are provided by Oracle as part of Nashorn and are intended for such purposes. By loading the compatibility extensions, scripts will continue to function as before, but with significantly improved runtime performance.

Scripts originally saved using Mozilla Rhino will now show JavaScript (Mozilla Rhino compatible) in the Language selection box, indicating that the script will run with Nashorn but with the Mozilla compatibility extensions. If you create a new script, the JavaScript (Mozilla Rhino compatible) option will not be available; you will see only JavaScript (Oracle Nashorn), which does not load the Mozilla compatibility extensions. If you need to load the compatibility extensions in this case, simply add load("nashorn:mozilla_compat.js"); to the top of your script. For more detail, see

Since Oracle Nashorn is the replacement for Mozilla Rhino, use of Mozilla Rhino is not recommended. However, Mozilla Rhino can be made available to SOAtest and Virtualize in the same manner as any other JSR 223 compatible script engine (see Other JSR 223 Scripting Languages). Mozilla Rhino includes two jars which must be added to the classpath in the Preferences panel (under System Properties): Rhino js.jar and js-engine.jar. For details, see

Pre-built jars can also be found on maven central:

Other JSR 223 Scripting Languages

To make another JSR 223 scripting language available, add the appropriate engine’s scripting engine to the classpath (go to the Parasoft Preferences panel and add it under the System Properties area).

For example, you could add the JRuby scripting engine, which implements JSR 223. To do this, you would download JRuby from then add jruby.jar to the classpath.

Here is a sample JRuby script:

require 'java'
Application = com.parasoft.api.Application
def doSomething(input, context)
    Application.showMessage("hello world")

Additional Extensibility Resources

For details on how to create and apply an Extension tool that executes a custom script you have written, see Extension Tool for Custom Scripting