08 May 2007 - 1.7.1 |
soapUI supports the following technologies for working with files and attachments:
(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 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:
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.
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;
Once attached, a file must be assigned to a corresponding message part in the tables Part column:
(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 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:
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:
The MTOM specification describes optimized transport of binary data in SOAP-messages. The corresponding data-type used for the binary-datas message element must be one of the xmime datatypes, 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.
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.
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:
cid:somename
and associating an attached file with the "somename"
part in the same way as in the swaRef/MTOM examples abovefile:filepath
where filepath points to a local fileIn 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.
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.
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. | ![]() |
The resulting multipart part can be seen in the httplog:
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.