Message Sets: Identifying an embedded message by using a Message Identity

You can identify an embedded message by using the Message Identity. This technique is used by the MRM domain, and replaces the use of the Message Key.

Tip: Multipart messages are used when working with messages that are modeled by using message sets.

The Message Identity technique for identifying embedded messages is useful when a multipart message has a format such as that shown in the diagram:

In this example, the Message Header and Message Trailer act as an envelope for the message body. They typically have a fixed structure, although 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 enables an embedded message to be added within the outer Message, creating a multipart message.

When using the Message Identity technique to parse such a multipart message, the embedded message must be identified earlier in the Message Header by using a Message Identity element. A Message Identity Element is a string element (or attribute) that precedes the embedded message in the model and whose Interpret Value As property is set to Message Identity.

When a multipart message is input to a message flow, the Message Identity element must have a value that corresponds to either the Name or the Message Alias of the next embedded message in the bit stream. This enables the MRM parser to correctly identify the embedded message in the model.

For cases where the Message Identity element value does not match the Name of the message, use the Message Alias property to specify this value. The MRM parser tries to match on Name first, and if that fails, it tries to match on Message Alias.

When the MRM parser has encountered a Message Identity element, its value applies to all embedded messages that are contained immediately within the current message. This does not apply to embedded messages within embedded messages; any embedded message must have its identity provided by a Message Identity element within its immediate parent message.

If a second Message Identity element is encountered within the current message, its value overrides any previously held. This enables different peer embedded messages to exist within a given message.

Message Identity takes priority over Message Path. If both are specified, Message Identity is used. Use only one of these techniques for a given multipart message.

Embedded messages defined in different message sets

By default, an embedded message is assumed to be defined within the same message set as the current message. This can be overridden by using a Message Set Identity, which works in a similar manner to a Message Identity.

An embedded message that is defined within a different message set must have its message set identified earlier in the message, by using a Message Set Identity element. A Message Set Identity Element is a string element (or attribute) that precedes the embedded message in the model and whose Interpret Value As property is set to Message Set Identity.

When a multipart message is input to a message flow, the Message Set Identity element must have a value that corresponds to either the Identifier, Name, or Message Set Alias of the message set that defines the next embedded message in the bit stream. This enables the MRM parser to correctly identify the message set to use.

If the Message Set Identity element value does not match the Identifier or Name of the message set, use the Message Set Alias property to specify this value. The MRM parser tries to match on Identifier first, then on Name, and finally on Message Set Alias.

After the MRM parser has encountered a Message Set Identity element, its value applies to all embedded messages that are contained within the current message. It also applies to embedded messages within embedded messages, unless an embedded message also contains a Message Set Identity element.

If a second Message Set Identity element is encountered within the current message, its value overrides any previously held. This enables peer embedded messages to be contained within different message sets.

The following example of an X12 message shows the use of both Message Identity and Message Set Identity. The field that contains 004010X092 within the GS segment on line 0002 holds the Message Set Identity as a Message Set Alias. The 207 on line 0003 in the ST segment is the Message Identity held as a Message Alias. The embedded message is from line 0004 - 0015 inclusive.

Note: The line numbers and spaces at the beginning of each line are for illustrative purposes only and do not exist in the actual message.

0001  ISA*00*          *00*          *30*12-3456789     *ZZ
      *9876543-21     *000104*1820*U*00401*000000001*0*T*:!
0002  GS*HS*HOSP CLAIM*PAYER ADJDEPT*20000104*1820*1*X*004010X092!
0003  ST*270*1234!
0004  BHT*0022*13*10001234*19990501*1319!
0005  HL*1**20*1!
0006  NM1*PR*2*ABCCOMPANY*****PI*842610001!
0007  HL*2*1*21*1!
0008  NM1*1P*2*BONE AND JOINT CINIC*****SV*2000035!REF*N7*234899!
0009  N3*55*HIGH STREET!
0010  N4*SEATTLE*WA*98123!
0011  HL*3*2*22*0!TRN*1*93175-12547*9877281234!
0012  NM1*IL*1*SMITH*ROBERT*B***MI*11122333301!
0013  REF*1L*599119!
0014  DMG*D8*19430519*M!
0015  DTP*472*RD8*19990501-19990515!EQ*30**FAM!SE*17*1234!
0016  GE*1*1!IEA*1*000000001!

Physical format considerations

Both Message Identity and Message Set Identity are applicable to all physical formats.