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.

About this task

You can model the inner message in the following 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)
The ESQL that you need to write to manipulate the inner message varies depending on which of the above models you have used. For example, assume that you have defined:
  • 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
If you want to set the value of E_inner11, code the following ESQL:
SET OutputRoot.MRM.E_outer1.M_inner1.E_inner11 = 'FRED';
If you want to set the value of E_inner21, code the following ESQL:
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.