WSDL Refactoring Download Trial - Free 14 day evaluation

Adding Headers and Attachments

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

Since the underlying protocol used for SOAP Requests is HTTP, it is possible to add both custom HTTP Headers (for example for authentication or sessions) and Attachments. Lets have a look at these two.

1. Custom HTTP Headers

Adding custom HTTP Headers is straight-forward; the Headers inspector at the bottom of the XML editor allows for this:

wsdl-request-headers-tab

Here we’ve add a custom Content-Type header which will override the standard Content-Type used for the SOAP Request (“text/xml; charset=utf-8”). Sending the request and looking the Raw Request Viewer reveals

wsdl-request-custom-header-in-raw

You can of course add as many desired headers as required, and their value can contain property expansions as usual.

The corresponding Headers tab for the response message not surprisingly shows all HTTP Headers in the response:

wsdl-response-http-headers

2. Attachments and 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 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.

Attachments in soapUI are managed in the attachment tab at the bottom of the request editor:

wsdl-request-attachments-tab

The highlighted properties to the left are all related to how attachments are handled.

Let’s start with a simple example; the following message defines a ClaimImage element containing base64 data:

wsdl-request-content-attachment

We’ve attached a file from our file-system and refer to it using the cid: notation, which sets its type to “CONTENT”. When adding the file we selected to cache it in the project file for easy redistribution of the tests (otherwise soapUI stores the absolute path to the attachment in the name column). If we now send this request and look in the Raw Request tab we see:

wsdl-request-content-attachment-in-raw

Here you can see the file has been read and converted to base64 data. If we instead want to send the file using MTOM we can enable this in the properties to the left an resent the message, giving us

wsdl-request-attachment-as-mtom

Here you can see that:

  • The outgoing message is being sent as a Mime Multipart message with the corresponding MTOM Content-Type
  • The first Mime Part contains the message, the second contains the attachment
  • The ClaimImage element in the message contains an XOP Include element referring to the second Mime-Part (highlighted)

Looking back in the attachments tab we can see that soapUI now sets the attachment type to XOP (an MTOM term):

wsdl-request-attachment-xop-type

2.1. MIME Attachments

MIME Attachments is an older way of specifying attachments in a WSDL (MTOM is the agreed on standard today), using it you defined the attachment in the binding of the WSDL in accordance with the SOAP with Attachments specification. When adding a file it must be associated with its corresponding MIME Part in the attachments tab. For example, if the request operations' binding defines the following:

wsdl-request-mime-attachment-binding

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

wsdl-request-mime-attachment

2.2. 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-request-swaref-attachment-def

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

wsdl-request-swaref-attachment-def

2.3. 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 "" part from the part dropdown. For these you will also need to set a content id in the ContentID column if required.

wsdl-request-anonymous-attachment

2.4. Inline Files

Inlining files is another way of attaching file content to a request. Set the “Enable Inline Files” property to true and specify a file with “file:”. For example if we go back to the first example above and just insert a file:

wsdl-request-inline-files

The specified file is now inserted into the request just as if it had been an attachment.

2.5. 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 " ", 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.

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