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
- 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)
- Update Definition : see below
- Refactor Definition (Pro Only) : Starts the WSDL refactor definition Wizard. Read More Here
- 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 (i.e. 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 updated interface will
be updated as configured above.
- Open Request List - Opens a separate window after the update containing a list of all Requests/TestRequests
that have been modified during the update-procedure (useful 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 Independence - 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 definitions 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 (i.e. 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
|  |
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 credentials. 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 (i.e. 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 explicitly 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:
Interfaces Overview