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 one of 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 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 TDS format: Multipart messages.
For more information about path concatenations,
see Message set properties.