This section describes additional configuration settings for SOAtest and Virtualize available in the Parasoft> Preferences menu.
The Browser panel lets you set options related to Web scenario recording. Available settings include:
Firefox Executable Path: Specifies the path to the Firefox executable. On Windows machines, SOAtest and/or Virtualize will attempt to detect a Firefox installation automatically. Linux users will have to browse to the Firefox executable.
Browser Timeout Settings: Specifies the length of delay (in milliseconds) after which SOAtest and/or Virtualize should stop waiting for browser startup or a user action and consider it to be "timed out."
Wait Condition Default Timeout Settings: Specifies the length of delay (in seconds) after which SOAtest and/or Virtualize should stop waiting for the activity specified in the wait condition to occur and consider it to be "timed out."
Debug Options> Print debugging information: During recording of a web scenario, it is possible that an action taken is not recorded by SOAtest and/or Virtualize. Enabling this option will allow messages to be printed to the message console during recording, with information about what events SOAtest and/or Virtualize handled, any locators that may have been generated, and if applicable, any exceptions that took place during recording.
Browser Contents Viewer Rendering Engine: Enables you to specify what browser is used for the Browsear Contents Viewer tool(described in Browser Contents Viewer) , which can be attached to the Browser Playback tool.
When Internet Explorer is selected, the version of IE that is used depends on what version of IE is installed on the machine running SOAtest and/or Virtualize. The Internet Explorer option is available only on Windows.
When Firefox is selected, the version of Firefox that is used depends on what Eclipse is being used to run SOAtest and/or Virtualize. It can range from Firefox 3.0.1 to Firefox 10, depending on what OS is being used.
HTML Content Fetch Mode: Enables you to determine whether the contents of hidden frames are displayed in the pre- and post-action HTML viewer. This can impact record and playback speed, as well as file size. It is possible to use one mode on some of your team’s SOAtest and/or Virtualize machines (e.g., desktop installation), and a different mode on others (e.g, the Server machine running in command-line mode).
Fetch all HTML content Choose this option if you want to see the contents of hidden frames in the pre- and post-action HTML viewer (in the Browser Playback tool, Browser Contents Viewer, Browser Data Bank, and Browser Validation tool). This is desirable if you want to create validations/extractions in hidden iframes. This mode will significantly slow down recording and playback. Moreover, it will significantly increase .tst file size if your application uses hidden iframes.
Fetch content for all content except hidden frames: Choose this option if you do not need to see the contents of hidden frames in the pre- and post-action HTML viewer.(in the Browser Playback tool, Browser Contents Viewer, Browser Data Bank, and Browser Validation tool). In this mode, the browser will still retrieve all frames from the server and it can still perform validations and extractions on the hidden iframes. However, it will not display the contents of hidden frames in the pre- and post-action HTML viewer.
When you record or run web scenarios in a browser, the proxy settings in the browser are set to an internal proxy maintained by SOAtest and/or Virtualize. All communication to and from the browser during recording and playback goes through the internal proxy, which is an intermediary used to capture traffic and otherwise facilitate execution. During recording and playback, SOAtest and/or Virtualize temporarily creates this proxy on localhost using the port specified by the Browser Playback setting’s Proxy port option.
The default host and port for the internal proxy is localhost:55555. Change the port number if this port is already in use using the controls Proxy port field. Do not change this from within the browser.
If your machine is configured to use your own proxy, you should configure SOAtest and/or Virtualize to point to that proxy. This enables SOAtest and/or Virtualize to configure its internal proxy to forward all traffic to the specified proxy configured in Proxy Settings.
SOAtest and Virtualize modify the global registry settings prior to starting its instance of the browser. If an instance of Internet Explorer was running on the machine prior to launching SOAtest or Virtualize (not recommended), the global registry settings will not be set in the existing browser instance.
In these cases, check the Internet Options panel in the existing browser instance while a web scenario is running to verify that the settings point to SOAtest’s or Virtualize's proxy and click OK in the Internet Options panel. If you click OK, the proxy settings are updated in the existing browser instance. If you click Cancel, or do not go to the Internet Options panel, then the existing browser instance never picks up the proxy settings and should continue to navigate fine.
Proxy settings may not be reset properly if the browser exited abnormally, if there is a hanging browser process, etc. Such issues can affect new browser instances (or other programs that connect to the internet). If this happens, you can resolve it by resetting your machine’s proxy settings to the appropriate settings or killing any hanging browser processes.
The Console panel allows you to determine the amount of information that is reported to the Console view and whether it is automatically activated when it contains messages.
If you have Continuous Testing Platform (CTP) and a valid license, you can configure your connection to CTP:
Global Data Sources can be reused and shared outside of a single SOAtest project and across Virtualize deployments. The Global Data Source panel lets you determine how information about global data sources is saved.
The Dictionary panel allows you to customize the dictionary that the Spell tool uses to identify misspelled words.
To add words to the dictionary:
You can also add reported misspelled words to the dictionary from the Quality Tasks view. Just right-click the reported misspelled word, then choose Add to Dictionary.
You can expand SOAtest’s built-in dictionary by extending it with additional sets of ispell-format dictionaries (such as dictionaries for language other than English, dictionaries of industry-specific terms, etc.). Each dictionary set has a name and one or more dictionaries.
To add an additional dictionary set:
By default, SOAtest treats non-text characters as white space and does not allow you to add dictionary words that contain non-text characters. If you want SOAtest to consider a designated non-text character as a valid character within a word (rather than as one unit of white space), you need to add that character to the list of allowable non-text characters. This allows you to identify spelling errors in words that contain allowed non-text characters and to add dictionary words that contain allowed non-text characters.
To add non-text characters to the list of allowable non-text characters:
The MIME Types panel lets you add and remove MIME types. In addition, it lets you specify the location of your preferred text and XML editors and lets you specify what editor you want to use to edit all files that have a particular MIME type.
To add, edit, or remove a MIME type:
The Misc panel allows you to set the following miscellaneous settings:
Auto Beautify: Tells SOAtest to automatically beautify XML messages in the selected tool or tools (Traffic Viewer, Diff, Editor) if the message is under the specified size (10 KB is the default setting).
Save settings: Specifies what file format to use for saving project files (e.g., .pva, .pvn, .tst, .changetemplate).
See Understanding the Available Project File Formats in SOAtest for additional information about each type, including performance and forward compatibility.
The Proxy panel controls how SOAtest and/or Virtualize works with proxy servers. It does not control the separate intermediary proxy used for web scenarios (for details on this other proxy, see Proxy Configuration Details).
Otherwise, select Enable proxy and manually enter the correct settings. These settings should be equivalent to what you would use in the browser outside of SOAtest/Virtualize.
file:///c:/Users/user/scripts/proxy.pac. On Linux, it might be
HTTP proxies that do not require authentication can be used while managing remote SOAtest and Virtualize servers. HTTP proxies that require authentication will not be applied when adding a remote SOAtest or Virtualize server to the server tree.
This Scanning panel specifies settings related to how SOAtest scans Web applications. Available options include:
The Scripting panel allows you to specify properties used for custom scripts.
Java: For Java, you can specify the Java home directory and the path to the
javac compiler. You need to specify these parameters if you want to compile Java methods in the editor.
Jython: For Jython, you can specify the jython.home and jython.path variables. Both variables are used to locate Jython modules. Jython code that does not import any Jython modules can use the Jython scripting support without setting either variable. If you set the jython.home and jython.path variables, you need to restart SOAtest or Virtualize before the changes will take effect.
Timeout Settings: Specify how many minutes SOAtest or Virtualize should wait before attempting to stop an unresponsive script and log an error message.
The Security panel allows you to set the following security settings:
Check Ticket: This will execute a simple test to locate a cached Kerberos TGT (Ticket Granting Ticket) to grant access to the service. SOAtest and/or Virtualize will not be able to communicate with the service if it cannot first locate a valid TGT. For more information about Kerberos, see Configuring Kerberos Authentication.
Trust all certificates: Enable this option to accept any certificate. This is useful if you want to load pages whose certificates are not "trusted."
Use default Java cacerts: Enable this option to accept only certificates from the standard list of Java-trusted certificate vendors.
In order to perform operations that use the XML Signature Verifier, XML Signer, or XML Encryption tools, or if using Key Stores, you will need to download and install the Unlimited Strength Java Cryptography Extension. For details, see JCE Prerequisite.
Keystores are specified at the test or responder suite level. If this option is selected, the following options are available in the Certificate and Private Key tabs:
Kerberos authentication is known as a trusted third-party authentication mechanism. A client requests access to a service not directly, but from another service: the Key Distribution Center, which manages network-wide authorization. This mechanism facilitates Single Sign-On (SSO) so that a client need only provide authorization credentials once in a given time period (usually 8-10 hours). The authorization is granted in the form of a ticket which can then be cached and reused throughout the granted time period without re-authenticating.
Entities in a Kerberos-protected network, such as clients and servers, are known as principals. The network-space that Kerberos protects is known as a realm. Microsoft's IIS (Internet Information Services) Server provides HTTP-based services with Kerberos through the Negotiation protocol. Other server vendors provide their own implementations of Microsoft's Negotiate protocol.
The ticket that is received upon initial authentication is known as a Ticket Granting Ticket, or TGT. For example, in a Windows environment, the TGT is generated when first logging on to the workstation in the morning. SOAtest and/or Virtualize authorizes itself to use a Kerberos-protected service by retrieving a user's TGT from the system cache.
For tips on common Kerberos errors and how to solve them, see.
Kerberos realm: Specify the Kerberos realm associated with your network. By convention, this is typically your domain name in all caps (e.g. PARASOFT.COM).
KDC server: Specify the hostname of your Key Distribution Center (e.g. kdc.parasoft.com).
Check Ticket: Click to execute a simple test to locate a cached Kerberos TGT (Ticket Granting Ticket) to grant access to the service. SOAtest and/or Virtualize will not be able to communicate with the service if it cannot first locate a valid TGT.
Configure the following options from the security panel of the Transport tab:
Service Principal: Specify the name of the service/server as defined in the Kerberos database (e.g. HTTP/soatest.parasoft.com).
Kerberos provides a mechanism to prevent so-called "replay" attacks where a user tries to provide captured duplicate credentials for a service in order to gain access to them.When performing a load test, where multiple virtual users provide the same user credentials, the KDC will respond as if a replay attack is occurring and errors will be thrown. This is expected behavior and it is uncertain at this point whether there is a work-around.
In order to perform security operations that use XML Signature Verifier, XML Signer, or XML Encryption tools—or to use Key Stores— you will need to download and install the Unlimited Strength Java Cryptography Extension. You can do this as follows:
[Parasoft Test install dir]\[Parasoft Test version number]\plugins\com.parasoft.xtest.jdk.eclipse.core.[platform]_[jre version]\jdk\jre\lib\security
US_export_policy.jarfiles with the new ones that you downloaded.
Restart SOAtest and/or Virtualize.
To see exactly where Unlimited JCE policy files should be added on your system, look at the message shown if you view keystore settings in the preferences for two-way SSL.
This "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files may need to be installed" message is displayed only if Unlimited JCE policy files are not yet installed to the JRE that is running on. After the files are installed properly and product is restarted, the message will no longer be shown.
The Server panel allows you to configure the following settings for the SOAtest and/or Virtualize server. The SOAtest server allows you to work with the Call Back tool and Asynchronous testing—as well as Message Stub tools integrated into end-to-end test scenarios.
Start server: Enable this option to automatically start the server when SOAtest and/or Virtualize starts up.
SOAtest can create tests that enforce policies applied to Web service assets that are declared in a BEA AquaLogic Enterprise Repository or Software AG Centrasite repository as described in Using Oracle or BEA with SOAtest and Using Software AG CentraSite Active SOA with SOAtest. The SOA Registry panel allows you to specify settings that SOAtest will use by default in forms that reference such repositories. For instance, if you specify settings for BEA ALER here, SOAtest will use these values by default in the wizard for creating tests from BEA ALER.
The SOAP panel allows you to specify the following settings:
Attachment Encapsulation Format: Allows you to choose MIME, DIME, or MTOM, for the default attachment encapsulation. See Working with Attachments for details.
You can also customize how SOAtest and/or Virtualize serialize the SOAP objects they transmit and deserialize the SOAP messages they receive, but you cannot do so within the Preferences panel.
SOAP messages are deserialized from XML into some native format and objects are serialized into XML format so that they can be sent as responses.
To add a
For Axis, you can retrieve the TypeMappingRegistry used by calling soatest.api.SOAPUtil.getDefaultAxisRegistry(). After you retrieve that registry, you can use the Axis API to register the serializer as needed.
The System Properties panel lets you add JAR files, class folders, and Java projects to the classpath if needed. Use the available controls to add or remove JAR files, class folders, and Java projects. The specified JAR files, classpaths, and Java projects will be added to the system's classpath and the corresponding classes will be loaded into the JVM after SOAtest or Virtualize is restarted.
Click Reload to force classes from the class path entries to reload.
Enable the Automatically reload classes option if you want SOAtest/Virtualize to reload classes from your Eclipse project after being modified or recompiled.
If you want to quickly add a large number of jar files—or add jars to a headless instance of your Parasoft solution— copy them into one of the following directories within your workspace:
On a headless instance, if you want to reload the jars without having to restart SOAtest or Virtualize, call post /v<version>/preferences/systemProperties/reload from the REST API.
The UDDI panel lets you set the UDDI inquiry endpoint, which is the endpoint that you want SOAtest to reference when performing dynamic router resolution. If you specify a UDDI registry here, the SOAP Client tool can search for a service by querying that registry using the UDDI serviceKey specified in the SOAP Client parameters. If you do not specify a UDDI registry here, you have to configure your SOAP Client tool so that the server endpoint is hard-coded as a router value.
The WSDL panel lets you review or modify the WSDLs that have been used in tools and projects. These WSDLs will be available for selection in relevant drop-down boxes. This way, if you need to specify the same WSDL multiple times, you don’t need to constantly type it in over and over again.
Enable the Save WSDLs used in message responders, SOAP clients, and projects if you want SOAtest/Virtualize to save tests' or assets' WSDL URIs. If you are using SOAtest only, the option will read Save WSDLs used in SOAP clients and projects. If you are using Virtualize only, the option will read Save WSDLs used in message responders and projects.
The WSDL URI field lists the WSDL URIs that will be available in tools’ WSDL URI drop down menu. By default, all WSDL URIs used in related tools are added to this list. Click on a URI in the field and click Refresh WSDL to refresh the WSDL from the given location URL and re-parse it.
Enable the WSDL/Schema Parsing section to check all schema locations in order to locate components belonging to a give target namespace. Disable this option to use only the first schema location encountered in order to resolve components for a given target namespace.
The XML Conversion settings panel lets you register data models for fixed length messages.
For details on using this setting, see Fixed Length Client and Fixed Length Call Back.
The XML Schema History panel lets you review or modify the XML Schemas that have been used in Messaging Clients (SOAtest), message responders (Virtualize), and projects. These Schemas will be available for selection in relevant drop-down boxes. This way, if you need to specify the same Schema multiple times, you don’t need to constantly type it in over and over again.
The XML Schema Locations panel lets you view, add, and remove schema locations.The XML Validator tool needs to know where to find the schema that it should use to validate the document of concern. In most cases this is a URI and is supplied within the document being validated. If, however, the URI for the schema is not supplied or if you want to use a different location, then disable the Use namespace as location URI for Schemas option for the XML Validator tool. For more information on the XML Validator tool, see XML Validator. When the tool is run with this option disabled, SOAtest will use the schema location(s) indicated in this panel. To add a new schema location:
To specify namespaces to skip:
To add OASIS XML Catalog Locations: