26 September 2007 - 1.7.6 | home user-guide eclipse jbossws intellij netbeans maven 1.X/2.X PDF files forums bugs sourceforge

Home
Getting Started
User Guide

- Overview
  - Tabbed Desktop
  - License Management
  - Preferences
  - XPath Selection
  - Script Library
- Workspaces
- Projects
- Interfaces
  - Interface Viewer
- Operations
- Working with Requests
  - Form Editor
  - Overview View
  - Outline Editor
  - Message Inspectors
  - Attachments/Inline Files
- Functional Testing
  - Getting Started
  - TestSuites
  - TestCases
    - Test Requests
      - Assertions
      - Editor Wizards
    - Property Transfers
    - Conditional Gotos
    - Groovy Scripts
      - Examples
      - GroovyUtils
    - Properties Step
    - Delay Step
    - Mock Response
    - DataSource
    - DataSource Loop
  - Property Expansion
- Load Testing
  - Getting Started
  - Limit & Strategies
  - Execution
  - Assertions
  - Diagrams
  - JMeter comparison
- Mocking
  - Getting Started
  - Mock Services
  - Mock Operations
  - Mock Responses
- Usage Scenarios
  - Data-Driven Testing
  - Template-Driven Testing
  - Interactive Testing
  - Surveillance Testing
- Tool Integrations
  - Code Generation
  - WSDL Generation
  - WS-I Tools
  - Apache Tcp-Mon
- CommandLine Tools
  - TestCaseRunner
  - LoadTestRunner
  - MockServiceRunner
  - ToolRunner
- Keyboard shortcuts

IDE/Tool Plugins
Search soapUI site
Project Documentation

- About soapUI
- Project Info
- Project Reports

## Interfaces

In the current implementation of the internal soapUI object model, Interfaces in soapUI correspond to SOAP/HTTP Bindings for a PortType. Once imported using one of the "Import WSDL from.." actions, the interfaces' operations and default requests will be visible in the navigator tree. The actual import process is below described in more detail.

### Interface Actions

The following actions are available from the interface nodes' right-button menu: Open Interface Viewer : Opens the Interface Viewer window Generate -> : Invokes one of the integrated tools as described under Tool Integrations Regenerate with JBossWS : Enabled if this interface was generated using the Generate with JBossWS option in the project menu. Invoking this will regenerate the WSDL and update the definition accordingly Check WS-I Compliance : Invokes the WS-I Basic Profile validation tools for this interface Launch TcpMon : launches TcpMon for this interface as described in TcpMon Integration. Generate TestSuite : Generates a complete TestSuite for this interface (see below) Generate MockService : Generates a complete MockService for this interface (see below) Service Endpoints : Opens a dialog for managing the available service endpoints for this interface (see below) Update Definition : see below Export Definition : prompts for a local folder and saves the entire definition (including imported/included documents) to that folder. Import/Include statements in the exported files will be modified accordingly to maintain the definitions integrity Remove : prompts to remove the interface from its containing project. When removing an Interface, all test-requests associated with operations in that Interface will also be removed from their respective TestCases. Online Help - Displays this page in an external browser |

### Updating the Interface Definition

The "Update Definition" action prompts from where to reload the definition for this interface. Updating will synchronize any changes in the underlying Binding/PortType as best as possible:

- New operations are added as new Operations in the navigator
- Operations not available any more can either be mapped to new ones (if they were renamed) or removed. When removing operations, all test-requests associated with them will also be removed from their respective TestCases.

This action is useful in the following situations:

- When the definition URL for a service/interface has changed (for example moved to another server)
- When the definition itself has changed (for example new operations have been added or the associated XML Schema has been modified

The dialog for updating a definition is as follows:

The options are:

- Definition URL - The URL to the definition (ie WSDL) to update from
- Create New Requests - If there are new operations in the updated WSDL, selecting this option will create new default requests for them
- Recreate Requests - Will recreate all requests in the project that use this definition, including TestRequest steps in associated TestCases.
- Recreate Optional - Set creation of optional elements/attributes when updating requests
- Keep Existing - Keeps existing values in requests that are recreated (this is limited to elements/attributes that have the same namespace/name before and after the update)
- Create Backups - Since recreating requests can potentially invalidate/modify the request in a way not desired, selecting this option will create a backup request or disabled TestRequest Step containing the original request.
- Update TestRequests - All TestRequests in the containing project for the udpated interface will be udpated as configured above.
- Open Request List - Opens a seperate window after the update containing a list of all Requests/TestRequests that have been modified during the update-procedure (usefull for manual post-processing).

If there is no binding in the specified definition matching the previous binding for the selected interface (for example if the binding has been renamed) an error will be displayed.

### Caching Definitions

By default soapUI caches the entire WSDL/XSD definition in the project file, mainly for the following reasons:

- Change Independance - validations, etc are not affected by external changes to the definition. This may be both good or bad
- Work Offline - one can work offline with request generation, validations, tests, etc.
- Fast Access - the soapUI attachments feature always requires access to the interface definition

The major drawback is that the soapUI project-file will grow accordingly; if the definition is a complex one this may take considerable processing power. If you for this or some other reason would like to disable definition caching this can be done either globally in the soapUI Preferences dialog, or on a per-project basis in the Projects Detail Tab.

Turning this option off will clear currently cached defintions first when soapUI restarts. If you want to force the reloading of a WSDL definition (whether it is cached or not) use the Update Definition action described above.

### Interface Details Tab

The "Details" tab shown in the bottom-left shows the following values when an Interface node is selected in the navigation tree PortType (read-only): The name of the WSDL PortType that the Binding exposes Description : an arbitrary description for the interface Definition URL (read-only): the URL where the Interface is defined (ie from where it was imported) Binding (read-only): The name of the WSDL Binding for the interface in `{namespace}name` format SOAP Version : The SOAP Version to use for this interface; SOAP 1.1 or SOAP 1.2. This will affect both generated requests (namespaces and content) and according HTTP Headers Cached (read-only): Shows if this definition is currently cached in memory Style (read-only): Shows if this is a Document or RPC definition |

### Service Endpoints

Selecting the "Service Endpoints" action from the interface context menu opens a dialog showing the available service endpoints for this interface and each endpoints default authentication settings. If the interface was imported from a WSDL definition, that services ports URL will be available in this list, and you are free to add/edit/remove as many service endpoints as you want. If your endpoints are already URL-encoded, you should select the "Preencoded Endpoints" option in the Http Settings dialog to avoid that they get reencoded during requests. When deleting an endpoint, all requests that had that endpoint will have their endpoint set to null.

Specified authentication values will be used for all Requests/TestRequest that use the endpoint, unless any of the values have been overridden at the request level.

The Assign options prompts to assign the selected endpoint to requests, the following options are displayed:

- `- all requests -` : will assign the selected endpoint to all requests for operations in the current interface.
- `- all requests with no endpoint -` : will assign the selected endpoint to all requests for operations in the current interface that have no endpoint.
- `<endpoint>` : will assign the selected endpoint to all requests for operations in the current interface that have this endpoint.

Assigning endpoints with this option will not assign to TestRequests, use the "Set TestCase Endpoint" action in the TestCase Editor for this instead.

When closing the dialog with the "Ok" button, the available endpoints will be selectable in associated operations requests/test-requests editor panes.

### WSDL Importing Details

When importing a WSDL using one of the "Import WSDL .." project actions, the import proceeds as follows;

- The specified WSDL is loaded and searched for defined WSDL Services. If the WSDL is secured soapUI will display an authentication dialog asking for relevant creadentials. Once the WSDL has been loaded, each of the included services' ports' binding is imported as a separate Interface into the soapUI project (provided that it is a SOAP 1.1/1.2 binding). If no services are found, the importer searches for standalone SOAP Bindings that are not bound to any service, these are imported as separate interfaces
- For each imported Binding, its PortTypes Operations are added as Operations and a default request is created (if specified) from the operations request schema.
- Either the name of the Binding or its PortType is used as the Interface name in soapUI, as controlled by the corresponding "Name with Binding" WSDL Setting.

The reasons for mapping Interfaces to WSDL Bindings and not WSDL services directly are:

- A WSDL Service can "implement" multiple bindings (through WSDL ports), each is imported as a separate Interface into soapUI
- A Binding can be "implemented" by several WSDL Services (for example on different servers or as a part of a more complex service interface). soapUI allows association of multiple service endpoints (see below) for a binding so it is easy to work with the same binding (ie Interface) without having to import each separately.
- Bindings can be defined without any referencing service, it should still be possible to work with these from soapUI

When importing the following XML-Schemas are added by default and need not be imported explicitely by the WSDL and/or its contained/imported/included types:

- http://www.w3.org/2004/08/xop/include : XOP includes used by MTOM
- http://www.w3.org/2004/11/xmlmime : xmime types used by MTOM
- http://www.w3.org/2005/05/xmlmime : xmime types used by MTOM
- http://www.w3.org/XML/1998/namespace : XML Namespaces
- http://ws-i.org/profiles/basic/1.1/xsd : swaref types used by SOAP with Attachments support
- http://www.w3.org/2001/XMLSchema : XML Schema itself

It is possible to specify a custom directory containing additional default schemas in the WSDL Settings preferences tab; "Schema Directory". Note that content-changes to an already specified directory will not be detected by soapUI and thus currently require a restart.

Next: Operations