See information about the latest product version
Accessing embedded messages in the MRM domain
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.
- An element (named E_outer1 in the following example) with its Type property set to a complex type that has been defined with its Composition property set to Message
- A complex type with its Composition property set to Message (named t_Embedded in the following example)
- An outer message M_outer that has its Type property set to t_Outer.
- An inner message M_inner1 that has its Type set to t_Inner1
- An inner message M_inner2 that has its Type set to t_Inner2
- Type t_Outer that has its first child element named E_outer1 and its second child defined as a complex type named t_Embedded
- Type t_Embedded that has its Composition property set to Message
- Type t_Inner1 that has its first child element named E_inner11
- Type t_Inner2 that has its first child element named E_inner21
- Type t_outer1 that has its Composition property set to Message
- Element E_outer1 that has its Type property set to t_outer1
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.