Message Sets: Identifying an embedded message by using a Message Path

This technique is used by the MRM domain.

In the diagram, the Message Header and Message Trailer act as an envelope for the message body. Typically, they have a fixed structure, but the Message Body can be defined with many different structures.

A place holder for an embedded message is created by setting the Composition property of the complex type or group of the Message Body element to Message. This enables an embedded message to be added within the outer message, creating a multipart message.

When using the Message Path technique to parse such a multipart message, the embedded message must be identified by a fixed path to the innermost message from the outermost message. For this example, this would be:

Message/Message Body

If the path to the innermost message contains intermediate elements, these intermediate elements must also be included in the path. In the following example, these elements are shown in bold:

Message/Data1/Data12/Message Body

This technique can be used to identify nested embedded messages as well, by extending the path. For example:

Message/Data1/Data12/Message Body/Data2/Inner Message

The path is specified by using one or both of two properties, the Message Type property of an IBM® Integration Bus input node (or MQRFH2 header) and the Message Type Prefix property of the containing message set. These two properties are combined to produce a final path that is used to locate embedded messages.

Message Identity takes priority over Message Path. If both are specified, Message Identity is used. Use only one of these techniques for a given multipart message.

You cannot use the Message Path technique to identify multiple peer embedded messages.