If you have defined a multipart message, you have at least one message embedded within another. Within the overall complex type that represents the outer messages, you can model the inner message in two ways.
SET OutputRoot.MRM.E_outer1.M_inner1.E_inner11 = 'FRED';
SET OutputRoot.MRM.M_inner2.E_inner21 = 'FRED';
If you copy message headers from the input message to the output message, and your input message type contains a path, only the outermost name in the path is copied to the output message type.
When you configure a message flow to handle embedded messages, you can specify the path of a message type in either an MQRFH2 header (if one is present in the input message) or in the input node Message Type property in place of a name (for example, for the message modeled above, the path could be specified as M_Outer/M_Inner1/M_Inner2 instead of just M_Outer).
If you have specified that the input message has a physical format of either CWF or XML, any message type prefix is concatenated in front of the message type from the MQRFH2 or input node, giving a final path to use (for more information refer to Message Sets: Multipart messages). The MRM uses the first item in the path as the outermost message type, then progressively works inwards when it finds a complex type with its Composition property set to Message.
If you have specified that the input message has a physical format of TDS, a different process that uses message keys is implemented. This is described in MRM TDS format: Multipart messages.
For more information about path concatenations, see Message Sets: Message set properties.