SMO attachments

Edit online
Draft comment:
This topic only applies to BAW, and is located in the BAW repository. Last updated on 2025-03-13 12:15
The service message object (SMO) contains an attachments element for each attachment associated with a SOAP message.

Introduction

The SMO attachments elements let you send and receive SOAP messages that have attachments of various types.

You might want to send SOAP messages with attachments and let the attachments pass through the mediation flow unchanged, or you might want to create new attachments, perhaps from information in the message or from an external source.

Details

A SOAP/HTTP message with attachments consists of a MIME multipart message in which the SOAP body is the first part and the attachments are subsequent parts (as defined in the SOAP Messages with Attachments specification External link opens a new window or tab and in the SOAP Message Transmission Optimization Mechanism (MTOM) specification External link opens a new window or tab).

Each attachment in the SOAP message has an associated attachments element in the SMO. The way an attachment is represented in the SMO depends upon whether the attachment is referenced or unreferenced.
  • Referenced attachments, which are defined in a WSDL port type as parts within an input or output message and which have a binary type, do not have their data stored in the SMO; instead, the path to the message body element that holds the data is contained in the bodyPath element.
  • Unreferenced attachments, which are not defined in a WSDL port type, have their data placed in the data element in the SMO and have no bodyPath element.
Each SMO attachments element contains the following information:
  • A contentID element

    The contentID element contains the value of the Content-ID header of the MIME part and uniquely identifies the attachment in the message.

  • A contentType element

    The contentType element contains the value of the Content-Type header of the MIME part and defines the type of data held by the attachment (for example, text/xml or image/gif).

  • A bodyPath element (used for referenced attachments only)

    The bodyPath element contains the path to the message body element where a referenced attachment is held.

    Note that MTOM can support attachment elements within nested structures meaning that the bodyPath for MTOM attachments are the xpath location for the element where the MTOM attachment is held. The computing logic for bodyPath is strictly following the schema to generate the xpath location as shown in the examples below:
    • For a non-array type (maxOccurs is 1): /sendImage/input/imageData
    • For an array type (maxOccurs > 1): /sendImage/input/imageData[1]
  • A data element (used for unreferenced attachments only)

    The data element contains the attachment data for unreferenced attachments.

You can propagate SOAP attachments into and out of your module if it uses any of the following bindings:
  • Web service binding: SOAP 1.1/HTTP using JAX-WS
  • Web service binding: SOAP 1.2/HTTP using JAX-WS
  • SCA binding
You cannot propagate SOAP attachments if you use web service bindings that are based on JAX-RPC. In addition, you cannot propagate SOAP attachments across any component types other than the mediation flow component. Therefore, if you have a module that contains other types of component you must store the attachment somewhere and retrieve it later. For example, you could use a Message Element Setter mediation primitive to copy an attachment from the SOAP attachments element to the userContext object.
An attachment cannot exist without a message body.
Important: As described in XML representation of SMO, the Mapping mediation primitive transforms messages using an XSLT 1.0 transformation or XSLT 2.0 transformation. The transformation operates on an XML serialization of the SMO. The Mapping mediation primitive allows the root of the serialization to be specified, and the root element of the XML document reflects this root.
When you are sending SOAP messages with attachments, the root element you choose determines how attachments are propagated.
  • If you use /body as the root of the XML map, all attachments are propagated across the map by default.
  • If you use / as the root of the map, you can control the propagation of attachments.