This describes how you can identify an embedded message using the Message Identity. Using the Message Identity to identify an embedded message is the technique that replaces the use of the Message Key.
The Message Identity technique for identifying embedded messages is useful when a multipart message has a format such as that shown in Figure 1 below.
In this example, the Message Header and Message Trailer act as an envelope for the message body. They typically will 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 allows an embedded message to be added at this point within the outer Message, thus 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 using a Message Identity element. This 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 should have a value which 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, you should use the Message Alias property to specify this value. The MRM parser will try to match on Name first and if that fails it will try to match on Message Alias.
Once 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 then Message Identity is used. You should only use one of these techniques for a given multipart message.
By default an embedded message is assumed to be defined within the same message set as the current message. This can be overridden using a Message Set Identity, which works in a very similar manner to a Message Identity.
An embedded message defined in a different message set must have its message set identified earlier in the message using a Message Set Identity element. This 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 should have a value which corresponds to either the Identifier, Name or Message Set Alias of the message set defining the next embedded message in the bit stream. This enables the MRM parser to correctly identify the message set to use.
For cases where the Message Set Identity element value does not match the Identifier or Name of the message set, you should use the Message Set Alias property to specify this value. The MRM parser will try to match on Identifier first, then on Name, and finally Message Set Alias.
Once 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 reside within different message sets.
The following example of an X12 message shows the use of both Message Identity and Message Set Identity. The field containing 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 to 0015 inclusive.
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!
Both Message Identity and Message Set Identity are applicable to all physical formats. Versions of the TDS physical format prior to Version 6.0 included embedded message identification by Message Key which worked in a similar manner to Message Identity. Message Key has been deprecated and is superseded by Message Identity.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ad00761_ |