Working with WS Attachments and Inline Files

PDF Print E-mail
User Rating:  / 31
Rate this article: PoorBest 

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

1. The Attachments Tab

The request and response editors contain tabs for adding or accessing attachments for the current request or 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

1.1. Attachment handling for SOAP Testing

The attachment-table contains the following columns:

  • Name - The filename of the attachment, support property-expansion and is relative to ResourceRoot
  • 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 corresponding WSDL
  • Cached - Shows if the attachment is cached in the project file

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.

1.2. Attaching files to a Web Service Test

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 absolute 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 attachments 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 association 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 association 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).

1.3. MIME Attachments for Web Service Testing

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:

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


MIME Attachments in soapUI

swaRef Attachments


The WS-I Attachments Profile defines a special swaRef data type 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=""




<xsd:element name="ClaimForm" type="ref:swaRef"/>


and the corresponding message would contain for example:




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


swaRef Attachments in soapUI

MTOM Attachments for Web Service Testing


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 data types (SoapUI 2.5 removes this requirement all together; all element content will checked for and MTOM encoded if MTOM is enabled and there is an attachment reference as described below). For example if the request operations' schema defines the following:


<wsdl:definitions xmlns:xmime="




<xsd:element name="ClaimImage" type="xmime:base64Binary"/>


and the corresponding message would contain for example:


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

1.4. MTOM Attachments in SoapUI

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 file path 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="




<xsd:element name="ClaimData" type="xsd:hexBinary"/>


and the corresponding message would contain for example:




The c:\data\ 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>", i.e. a space-separated 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.