This section describes additional configuration settings for SOAtest and Virtualize available in the Parasoft > Preferences menu.

Authors

The Authors configuration screen enables you to specify how code authors are mapped to usernames and email addresses when quality tasks are generated. See Specifying Author-to-Author and Author-to-Email Mappings for details.

Browser Settings

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.

• Chrome Executable Path: Specifies the path to the Chrome executable. Paths set here will be used in web recording wizards and other applicable areas. On Linux, choose google-chrome (for example, /opt/google/chrome/google-chrome)—not chrome.
• Safari Executable Path: Specifies the path to the Safari executable.
• Proxy port: Specifies the proxy port. See Proxy Configuration Details below for more information and tips.
• Browser communication port: Specifies the browser communication port.

• Browser Timeout Settings: Specifies the length of delay (in seconds) 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.

• Allowable Binary Files in Traffic Viewer and Outputs: Allows binary files with the specified extensions or MIME types to be used in the Traffic Viewer and output. By default, only text files will be allowed.

Proxy Configuration Details

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.

Console Settings

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.

Continuous Testing Platform Settings

If you have Continuous Testing Platform (CTP) and a valid license, you can configure your connection to CTP:

• Use DTP settings: Enable this option to use the connections settings specified in DTP. See Connecting to DTP. 
• Server Name: Specifies a name for the server you are connecting to CTP. This is the name that will be used to identify this server within CTP.
• CTP URL: Specifies the location of the CTP to which you are connecting (for example, http://emdemo:8080).
• Username: Specifies the username for logging into CTP.

• Password: Specifies the password for logging into CTP.

  If OpenID Connect authentication is enabled, the Username and Password fields do not appear. Instead, you will see a notice that OIDC authentication is in use with a button to test that connection.

Global Data Source Settings

Global data sources can be reused and shared outside of a single SOAtest project. The Global Data Source panel lets you determine how information about global data sources is saved. For information on how to configure global data sources, see Adding a Data Source at the Test Suite, Project, or Global Level.

Technical Support Settings

Use the Technical Support interface to create a zip archive containing the related files if you are experiencing issues. Send the zip file to Parasoft's support team so that they can assist you. SOAtest can automatically create an archive when problems occur. Archives are approximately half a megabyte and are created in about 60 seconds.

By default, an archive is not created when problems occur. You can either manually prepare and send a support archive when needed, or you can modify Parasoft  archive creation options so that the product automatically prepares and sends an archive when problems occur.

To configure the product to automatically prepare and send archives when problems occur:

1. Open the Technical Support panel by going to Parasoft > Preferences, then selecting the Parasoft > Technical Support category.
2. Check Enable auto-creation of support archives.
3. Customize additional options as needed. Note that Enable auto-creation of support archives and Send archives by email are not applicable to Virtualize.
4. Click Apply, then OK.

To manually create a support archive:

1. Go to Parasoft > Preferences and click the Technical Support category.
2. Choose your archive options and click Create Archive.

To open the Technical Support Archive Manager, which allows you to review, e-mail, or delete recent support archives:

1. Go to Parasoft > Preferences and click the Technical Support category.
2. Click Browse Recent Archives.

Enabling Debug Logging

You can add the following system properties when starting SOAtest from the command line to enable debug logging and to ensure that all relevant information is included when creating a support archive.

-J-Dparasoft.logging.config.jar.file=/com/parasoft/xtest/logging/log4j/config/verbose.console.xml

-J-Dparasoft.logging.config.file=<PATH_TO_LOG4J_CONF_FILE>

Dictionary Settings

The Dictionary panel allows you to customize the dictionary that the Spell tool uses to identify misspelled words.

Adding Words

To add words to the dictionary:

• To add a new word, click Add, then enter it in the dialog that opens.
• To import a set of words from a text file, click Import, then specify the file that contains the set of words you want to import.
• To remove a word, select it in the list of words, then click Delete. You can select more than one word, then delete all selected words with one click.
• To export a list of words into a text file (for example, to export your User Added Words list so that your team members can import them) click Export, then indicate what file you want to contain the exported words.

Adding Dictionaries

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, and so on). Each dictionary set has a name and one or more dictionaries.

To add an additional dictionary set:

1. Save the dictionaries in the SOAtest installation directory.
2. Click Add and use the file chooser to select the set of dictionaries you want to add.

Adding Non-Text Characters or Words Containing Non-Text to the Dictionary

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:

• Enter them in the Allowable non-text characters field. If you want to allow multiple non-text characters, list them one after the other; do not separate them with a space character, comma, or other delimiter.

MIME Type Settings

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:

• To add a MIME type, click Add MIME Type, enter the new MIME type in the dialog box that opens, then enter the file extensions that you want to assign to this MIME type, and (optionally) indicate the implied MIME type by checking the appropriate check boxes. If you enter multiple extensions for a MIME type, separate the extensions with one space character.
• To edit a MIME type’s settings, select the MIME type whose settings you want to edit, then modify the settings as needed.
• To remove a MIME type, select the MIME type that you want to remove, then click Delete MIME Type.

Miscellaneous Settings

The Misc panel allows you to set the following miscellaneous settings:

• Show tool descriptions: Enables/disables showing tool descriptions in applicable wizards.
• 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).
• Masked Environment Variables: Enable to hide any masked environment variables from traffic viewers, REST Clients, JSON/XML Data Banks and Assertors, and in the Event Monitoring Details. See Masking a Variable Value for more information about masking environment variables.
• Character Encoding: You can enable System default to configure SOAtest to use the default character set for the particular system being used. Enable Custom to encode characters from the list of encodings available on the JVM being used.
• Default timeout (milliseconds): Allows you to enter the length of delay (in milliseconds) after which SOAtest should consider your FTP, telnet, or HTTP requests to be “timed out.” The default is 30000 milliseconds.
• Report each duplicate error that occurs on the same line: Tells SOAtest to show only the first instance of duplicate errors that occur for the same line of code.
• Reset Cookies: Allows you to clear the current global cookies so that next HTTP invocations start a new session.
• Save settings: Specifies what file format to use for saving project files (for example, .tst, .changetemplate). See Understanding the Available Project File Formats.
• Enable the Automatically backup project files option and specify a file size threshold for .tst files in the Warn on file size large than (MB) field to be notified when the size of the file exceeds the threshold. You can then reduce the size (and prevent performance problems) by dividing it into smaller files.

OpenAI

The OpenAI panel allows you to configure the application to use your OpenAI or Azure OpenAI account to assist you when creating test scenarios. The model of OpenAI that is used must support function calling. Functionality has been tested on GPT-3.5 turbo and GPT-4 and the embedding model text-embedding-ada-002. Note this functionality is only supported with a license that has "LLM Integration" enabled.

Using OpenAI to create test scenarios requires access to your OpenAI or Azure OpenAI account. To enable it, set the following preferences:

• Enable: When enabled, OpenAI is available when creating test scenarios from an OpenAPI/Swagger definition.

• Provider: Your OpenAI provider. Choose between OpenAI and Azure OpenAI.
• Configuration (OpenAI)
  • API key: Your OpenAI token.
  • Organization ID: The Organization ID you want to use when accessing the OpenAI client. Optional. If no Organization ID is supplied, the default organization ID for your account will be used.
  • Test Connection: Click to test the connection to OpenAI.
  • GPT: The name of the GPT model you are using, for example gpt-3.5-turbo-16k or gpt-4.
  • Embedding: The name of the Embedding model you are using, for example text-embedding-ada-002.
• Configuration (Azure OpenAI)
  • Resource Name: The Azure resource that contains your deployed Azure OpenAI model.
  • API key: Your Azure OpenAI token.
  • GPT: The deployment name of your Azure OpenAI GPT model.
  • Embedding: The deployment name of your Azure OpenAI Embedding model.
  • Test Connection: Click to test the connection to Azure OpenAI.

Note: OpenAI may produce inaccurate information, which may affect product features dependent on OpenAI.

OpenID Connect

The OpenID Connect panel allows you to configure the application to authenticate users via your OpenID Connect server by setting the following:

• Enable: When enabled, OpenID Connect is available for authentication.
• Server
  • Issuer URI: The URI of your OpenID Connect server.
  • Client ID: The ID registered on your OpenID Connect server.
  • Client Secret: The application's password to the OpenID Connect server.
  • Scopes: A space-separated list of scopes used during authentication to authorize access to a user's details.
  • Callback host: The local callback host required to communicate with the OpenID Connect server. The following options are available:
    • localhost: The localhost address will be used for communication.
    • 127.0.0.1: The loopback IP address 127.0.0.1 will be used for communication.
  • Callback port: The callback port number for communication with the OpenID Connect server. The following options are available:
    • Automatically select an open port: Automatically selects an open port (recommended).
    • Use port: Allows you to manually specify the port number.
  • Callback timeout: Specifies, in seconds, the maximum time the browser will wait for user credentials.
  • Test Authentication: Click to open the OpenID Connect authentication page in your browser. You may be asked to provide your credentials in the browser window that opens.
• Status: Shows the current OpenID Connect authentication status.

Proxy Settings

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). 

• If Windows and IE (which use the same settings) are configured to properly use the proxy to access the relevant websites, select Use system proxy configuration.

• 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.

  • To use an automatic configuration script, select Use automatic configuration script and enter the proxy address in the Address field.
  • If you want to use the same proxy server for all protocols, enable Same proxy server for all protocols, then enter the address and port of the proxy server you want to use in the Proxy Address and Proxy Port fields.
  • If you want to use different proxy servers for different protocols, disable Same proxy server for all protocols, then enter the address and port of each proxy server you want to use in the Proxy Address and Proxy Port fields.
  • If your proxy server requires authentication, enable Enable proxy authentication, then enter a valid username and password in the Username and Password fields.
  • If you want to allow Web traffic from designated IP addresses to pass through directly (avoiding the proxy), enter those IP addresses in the Proxy Exceptions text field. If you enter multiple addresses, use a semicolon (;) to separate the entries.
  • The Proxy Address value should be a URL to the script: either an HTTP(S) URL or a file URL. File URLs should be formatted as "file:///" followed by the file system path where the proxy autoconfiguration script lives. For example, on Windows this could be file:///c:/Users/user/scripts/proxy.pac. On Linux, it might be file:///home/machine/scripts/proxy.pac.

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.

Scanning Settings

This Scanning panel specifies settings related to how SOAtest scans Web applications. Available options include:

• Agent name: Determines the user agent that SOAtest uses to identify itself.
• FTP Log: Determines whether (and how) to create a log of FTP connections made to scan Web resources from SOAtest.
• Script options:
  • Script extensions: Determines what files SOAtest considers "scripts".
  • Limit the number of script items per page to: Determines the maximum number of script items per page that SOAtest will consider. If a page has more script items than the number that you allow, SOAtest will place a "red flag" icon next to the related Project tree node.
  • Load JavaScript: Determines whether or not SOAtest loads JavaScript.
  • Simulate JavaScript events: Determines how SOAtest simulates JavaScript events (such as opening and closing additional windows, running timers, and so on). If you choose single time, SOAtest triggers each handler once, with default arguments. If you choose multiple times, SOAtest tries to create multiple kinds of events while loading a site (in order to find new links).

Scripting Settings

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.   

  Note

  The javac compiler is not included.

  • Java home: Specifies the Java installation directory.
  • Javac classpath: Specifies the Java classpath.
• JavaScript: If you create scripts using JavaScript, you can specify a script template in the Script Template field.
  • Script Template: 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; they do not apply to JavaScript that runs in a browser context.

• Jython: If you are using Jython scripts, you can specify the Jython Path variable. Jython scripting support can be used without setting this variable by specifying a script template in the Script Template field.

  • Jython Path: Specifies a list of directories to search for python modules that are not already included with Jython. Separate multiple directory paths using the OS default path separator (";" for Windows and ":" for Linux and macOS). If you set the Jython path then you need to restart SOAtest or Virtualize for the change to take effect.
  • Script Template: Code specified in this field sets a default template for Jython scripts used in the tool.

• Timeout Settings: Specify how many minutes SOAtest or Virtualize should wait before attempting to stop an unresponsive script and log an error message.

Security Settings

You can configure default security settings for clients used in your projects. In most cases, the security settings can be overridden by configurations set locally in your suites:

Global HTTP Authentication Properties

Configure global HTTP authentication properties that can be used when configuring HTTP protocols within an applicable tool.

1. Enable the Perform Authentication option and enter the Username and Password to authenticate the request.
2. Choose the authentication type from the drop-down menu. Supported types are Basic, NTLM, Kerberos, or Digest.
3. If you are using Kerberos authentication, enter the Service Principal to authenticate the request. If the correct username and password, or the correct service principal, are not used, the request will not be authenticated.
   1. Kerberos realm: Specify the Kerberos realm associated with your network. By convention, this is typically your domain name in all caps (for example, PARASOFT.COM).
   2. KDC server: Specify the hostname of your Key Distribution Center (for example, kdc.parasoft.com).
   3. 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.

About Kerberos Authentication

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.

Configuring Kerberos Authentication for Tools

1. Select the tool for which you intend to use Kerberos authentication.
2. Select the Transport tab and select Security from the left pane of the Transport tab. 
3. Configure the following options from the security panel of the Transport tab:
   1. Perform Authentication: Select this option to activate authentication.
   2. Use Global Preferences: Select this option if you have authentication properties setup in Security Preferences.
   3. Type: Select Kerberos to perform Kerberos Authentication.
   4. Service Principal: Specify the name of the service/server as defined in the Kerberos database (for example, HTTP/soatest.parasoft.com).

Now when you invoke your tool, the required Negotiate token will automatically be generated and send as an HTTP header. 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.

Server Certificate Settings

Enable the Trust all certificates option to accept any certificate. This is useful if you want to load pages whose certificates are not "trusted."

Enable the Use default Java cacerts option to accept only certificates from the standard list of Java-trusted certificate vendors.

Client Key Store Settings

Enable the Use client keystore option to specify settings for both the server side and client-side certificates for SSL through the Client Keystore options.

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:

Certificate Tab

• Use same key store for private key: Select if the Key Store contains private keys for the certificate.
• Key store file: Specify the key store file by clicking Browse and using the file chooser that opens. If you want the path saved as a relative path (for example, to facilitate project sharing), enable Persist as Relative Path.
• Key store password: Specify the Key Store password.
• Key store type: Specify the type of Key Store being used (for example, JKS, PKCS12, BKS, PEM, UBER).
• Load: Click to populate the aliases with the available certificates/keys if the path, type, and key store password are valid.
• Certificate alias: Specify the certificate alias.

Private Key Tab

• Key store file: (Only available if the Key Store Contains Keys option is not selected in the Certificate tab) Specify the key store file by clicking Browse and using the file chooser that opens. If you want the path saved as a relative path (for example, to facilitate project sharing), enable Persist as Relative Path.
• Key store password: (Only available if the Key Store Contains Keys option is not selected in the Certificate tab) Specify the Key Store password.
• Key store type: (Only available if the Use same key store for private key option is not selected in the Certificate tab) Specify the type of Key Store being used (for example, JKS, PKCS12, BKS, PEM, UBER).
• Load: Click to populate the aliases with the available certificates/keys if the path, type, and key store password are valid.
• Private key alias: Specify the private key alias.
• Private key password: Specify the private key password.

MQ SSL

You can specify the trust store, key store, and key store password for clients that interact with AUTs over MQ SSL. These settings are not applicable to Virtualize. 

JCE Prerequisite

SOAtest and Virtualize ship with their own instance of Java that include the Unlimited Strength Java Cryptography Extension so that they can perform security operations that use XML Signature Verifier, XML Signer, XML Encryption tools, and Key Stores. If you installed SOAtest or Virtualize from the update site (see Eclipse p2 Update Site Installation) and are using your instance of Java, you will need to download and install the unlimited JCE if it's not already on your system. Refer to the Oracle website for downloads and documentation. MacOS users should install Java 8 newer than update 161 to get the unlimited JCE.

Server Settings

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.  

• Server port: Specifies the ports that the server use for HTTP/HTTPS.

SOAP Settings

The SOAP panel allows you to specify the following settings:

• Default Transport: Allows you to set the default transport protocol.

• Attachment Encapsulation Format: Allows you to choose None, MTOM always, or MTOM optional for the default attachment encapsulation. See Working with Attachments for details.

• SOAP Version: Allows you to select SOAP 1.1 or SOAP 1.2.
• Outgoing Message Encoding: Allows you to choose the encoding for outgoing messages. You can choose any Character Encoding you wish to read and write files, but the Outgoing Message Encoding provides additional flexibility so you can set a different charset encoding for the SOAP request.

System Properties Settings

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.

UDDI Settings

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.

WSDL History

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 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.

XML Conversion Settings

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.

XML Schema History Settings

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.

XML Schema Locations Settings

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 Use namespace as location URI for Schemas 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:

1. Click Add beneath the Namespace and Location columns.
2. In the dialog that opens, specify the Namespace and Schema Location.
3. Click OK after you have added all of the necessary locations.

To specify namespaces to skip:

1. Click Add beneath the List of namespaces to skip during XML Validation table.
2. In the dialog that opens, specify the namespace you want to skip.
3. Click OK.

To add OASIS XML Catalog Locations:

1. Click Add beneath the OASIS XML Catalog Locations section of the Schema Locations tab. The Location dialog box appears.
2. Type in the OASIS XML Catalog Location or navigate to it by clicking Browse.
3. Click OK after you have added all of the necessary locations.