The Message Path technique for identifying embedded messages is useful when the multipart message contains no information as to the identity of an embedded message.
In figure 1 below, 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 allows an embedded message to be added at this point within the outer Message, thus 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 simply be:
Message/Message Body
If the path to the innermost message contains intermediate elements then they must be included in the path as well. 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 simply extending the path. For example:
Message/Data1/Data12/Message Body/Data2/Inner Message
The path is specified using one or both of two properties, the Message Type property of a WebSphere Message Broker input node (or MQRFH2 header) and the Message Type Prefix property of the containing message set. These two properties are combined together to produce a final path that is used to locate embedded messages.
Message Identity takes priority over Message Path. If both are specified then Message Identity is used. You should only use one of these techniques for a given multipart message.
This is not supported by the Message Path technique.
Message Path is applicable to all physical formats.