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

## Working with Attachments / Inline Files

soapUI supports the following technologies for working with files and attachments:

- MTOM - a technology for optimized transfer of binary data in SOAP Messages
- SOAP with Attachments in accordance with Attachments Profile - a MIME-based attachment mechanism for the SOAP/HTTP binding
- Inline files for binary content - soapui-specific functionality for simplifying handling of binary message content

(since the industry (for now) seems to be moving towards MTOM, we currently have no plans for supporting any other attachment technology, for example DIME)

Both MTOM and Inlining of files require internal processing and can be disabled for better performance in the Request Details Tab. Also, when disabling this feature, soapUI will no longer be required to load the WSDL Definition (either cached or remote) before sending a request.

### The Attachments Tab

The request/response editors contain tabs for adding/accessing attachments for the current request/response messages. For request messages, this tab contains a table of files that have been attached to the current request. For the response, the table contains attachments in the response. The tabs are always available since they can always be used for both MTOM attachments and File Inlining as described below

The attachment-table contains the following columns:

- Name (read-only) - The filename of the attachment
- Content-Type - The mime content-type of the attachment
- Size (read-only) - The size of the attached file
- Part - The part this attachment should be associated with (see below)
- Type (read-only) - The type of attachment (depends on the attachments Part, see below)
- ContentID - Allows overriding of the content ID taken from the mime-part definition in the correspondning WSDL

Double-clicking an attachment in either message will attempt to save the attachment to a temporary file (unless it is relative as described below) and open that file in the systems web-browser.

### Attaching files

A file can be attached to a request message either by dragging it from the file-system into the request attachments table or by selecting the "Add File" button which will open a file-selection dialog. When adding a file, soapUI will prompt if the file should be cached by soapUI or added as a file reference;

- Caching the attachment will result in soapUI creating a local copy of the attachment in the attachment folder configured in the soapUI Preferences dialog (see more below)
- Not caching the attachment will result in soapUI storing only the absolut file path to the selected file in the project

Once attached, a file must be assigned to a corresponding message part in the tables Part column:

- If the operation is defined to use MIME attachmentes in its WSDL, the dropdown displayed in the Part column will contain all defined mime-parts. Just select which part the attachment should be assigned to.
- If the request message contains SOAP-with-Attachments swaRef elements containing a "cid:XXX" value, that XXX value will be available in the part-dropdown allowing assocation of swaRefs with attached files.
- If the request message contains binary (base64 or hex) elements which contain a "cid:XXX" value, that XXX value will be available in the part-dropdown allowing assocation of binary elements with attached files.

(all/any of these may be possible depending on message definition and content)

Selecting an attachments part will also update the attachments type column, which will display one of MIME (for a mime attachment), XOP (for a MTOM attachment), CONTENT (for an inline file attachment), SWAREF (for a swaRef attachment), UNKNOWN (for unassigned attachments).

### MIME Attachments

MIME attachments have been defined in the operations WSDL-defined as described in the SOAP with Attachments specification. When adding a file it must be associated with its corresponding Mime-Part as described above.For example, if the request operations' binding defines the following:

    <wsdl:definitions xmlns:ref="http://ws-i.org/profiles/basic/1.1/xsd"
    ...
      <wsdl:operation name="SendClaim">
                <soapbind:operation soapAction="http://example.com/soapaction"/>
                <wsdl:input>
                    <mime:multipartRelated>
                        <mime:part>
                            <soapbind:body use="literal"
                                           parts="ClaimDetail"
                                           namespace="http://example.com/mimetypes"/>
                        </mime:part>
                        <mime:part>
                            <mime:content part="ClaimPhoto"
                                          type="image/jpeg"/>
                        </mime:part>
                    </mime:multipartRelated>
                </wsdl:input>
                <wsdl:output>
                    <soapbind:body use="literal"
                                   namespace="http://example.com/mimetypes"/>
                </wsdl:output>
            </wsdl:operation>

This would result in the following option in the Part combo-box:

### swaRef Attachments

The WS-I Attachments Profile defines a special `swaRef` datatype which can be used in a schema for designating attached binary content. In soapUI, elements of the swaRef type should contain a value in the form of `cid:somename`, which will result in "somename" being available in the attachment part dropdown. For example, if the request operations' schema defines the following:

    <wsdl:definitions xmlns:ref="http://ws-i.org/profiles/basic/1.1/xsd"
    ...
      <wsdl:types>
      ...
    	 <xsd:element name="ClaimForm" type="ref:swaRef"/>

and the corrsponding message would contain for example:

    <ClaimForm>cid:claimForm</ClaimForm>

this would result in the following option in the Part combo-box:

### MTOM Attachments

The MTOM specification describes optimized transport of binary data in SOAP-messages. The corresponding data-type used for the binary-data message element should be one of the xmime datatypes (soapUI 1.7.6 removes this requirement; all binary content will be MTOM encoded if MTOM is enabled). For example if the request operations' schema defines the following:

    <wsdl:definitions xmlns:xmime="http://www.w3.org/2005/05/xmlmime
    ...
      <wsdl:types>
      ...
    	 <xsd:element name="ClaimImage" type="xmime:base64Binary"/>

and the corrsponding message would contain for example:

    <ClaimImage xm:contentType="image/gif">cid:claimImage</ClaimImage>

this would result in the following option in the Part combo-box:

Since not all servers support MTOM, you can disable this feature in the Request Details Tab which will result in the file-data being inlined in the outgoing message in the same way as described for Inline Files below. You can also force the use of MTOM even if there are is no binary content in the request using the "Force MTOM" request property.

### Anonymous Attachments

Sometimes you may want/need to attach files although this is not specified in the WSDL, for this soapUI allows "anonymous" attachments by selecting the "<anyonymous>" part from the part dropdown. For these you will also need to set a content id in the ContentID column if required.

### Inline files

soapUI also has the option of "inlining" binary files into request messages when they are sent; if a message contains base64Binary or hexBinary data elements, these can be "filled" using an attached file in 2 ways:

1. By specifying a value of `cid:somename` and associating an attached file with the "somename" part in the same way as in the swaRef/MTOM examples above
2. By specifying the value `file:filepath` where filepath points to a local file

In both cases, the associated file will be inlined into the message with either base64 or hex encoding. For example if the request operations' schema defines the following:

    <wsdl:definitions xmlns:xmime="http://www.w3.org/2005/05/xmlmime
    ...
      <wsdl:types>
      ...
    	 <xsd:element name="ClaimData" type="xsd:hexBinary"/>

and the corrsponding message would contain for example:

    <ClaimData>file:c:\data\mydata.zip</ClaimData>

The c:\data\mydata.zip file would be inlined into the outgoing message using hex encoding.

### Attachment Caching

When adding an attachment as described above, soapUI gives an option to cache the attachment locally. If selected, the file will be saved in the soapUI project file (compressed), otherwise the project file will keep an absolute path reference to the selected file.

### Multipart Attachments

For anonymous, MIME, swaRef and MTOM attachments it is possible to associate multiple files with the same attachment part. This will result in soapUI first building a MIME Multipart message containing the associated files and then attaching that multipart-message to the corresponding part definition using the "multipart/mixed" content-type, a feature that can be turned off in the Requests Details tab ("Enable Multiparts"). If you need to set the ContentID for both the multipart attachment and the contained attachments, set the first attachments ContentID to "<attachment contentid> <multipart contentid>", ie a space-seperated string where the first token is the id of the attachment inside the multipart and the second token is the id of the multipart attachment itself.

### Response Attachments

The response attachments table lists all attachment available in the response with their corresponding name, content-type, size, etc. Double-click an attachment to view it with the local web-browser.

Next: Functional Testing