XML wire format - Multipart messages

The XML physical format is the simplest of the physical formats for modeling multipart messages, because the content and the structure of the message are both fully described by the bitstream. The logical model must include an embedded message definition at the appropriate position (see Multipart messages), but there are no extra definitions required for the XML physical format.

In the MRM domain, embedded XML messages are recognized by matching their XML tag name against the XML name of a message definition in the message model. If the position of the embedded message corresponds to an embedded message definition in the logical model, the message is recognized.

If the embedded message definition is a complex type, the message definition will contain a complex element based on that complex type. This complex element will have its own tag, which will appear in the bitstream before the tag for the embedded message. If you want to avoid this extra tag, you can create the embedded message definition from a group, and insert the group at the appropriate position in the message model.

Tip: Note that the root tag property of an embedded message is not applicable.
Note: For WebSphere Business Integration Message Broker, when you configure a message flow to process these messages, you can set the Message Type property in the input node properties. Alternatively, you can specify this in the MQRFH2 header of the input message. The value you set must be a path that contains the hierarchy of messages from the outermost message to the innermost message.

You can define the outer message to contain more than one hierarchy of embedded messages, and you can define an embedded message to contain another embedded message. An embedded message, wherever it occurs, must start with the tag for that message.