| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| TDS Definition Problem[2] |
« View previous topic :: View next topic » |
| Author |
Message
|
| asamanta |
 Posted: Fri Aug 22, 2003 5:55 am Post subject: TDS Definition Problem[2] |
 |
|
Novice
Joined: 20 Aug 2003
Posts: 18
|
Hi,
I've encountered the following
| Code: |
001|HDR|000|abc|def|#
002|SHD|001|0000553766|xyz|0000553766|#
003|ITEM|005|1080846838|003041|#
004|SPEC|010|9911174|000117|34461504|34461505|#
005|SPEC|010|99111 |00010 |33942004|33942005|#
006|SPEC|010|99111 |00010 |03353098|33942005|#
007|ITEM|005|1080846839|003041|#
008|SPEC|010| 911174|000117|33942004|34461900|#
009|ITEM|005|1080846840|003041|#
010|SPEC|010| 91117 |000117|34461504|34461505|#
011|SPEC|010|99111 |00010 |33942004|33942005|#
012|TRL|000|20030529|08:34:12|# |
Each record starts off with a unique line number. Logically it could be represented by
| Code: |
MyMsg
- HDR
- SHD
- ITEM_WRAPPER {Repeating}
- ITEM
- SPEC {Repeating}
- TRLR |
However, due to the presence of line numbers, I couldn't think of a way of using Tags as Data Element Seperation method. Also as correctly specified by CraigB in an earlier communication, since both ITEM_WRAPPER & SPEC use the same delimiter, the parser won't be able to differentiate between start/end of these two copound types.
Could anybody (Craig again!) pls. throw some light on how to model this! I would require to retain the grouping & order in the output
Regards. |
|
| Back to top |
|
 |
| Craig B |
| Posted: Sun Aug 24, 2003 3:35 pm Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
Hi,
Looking at your data then it would appear that this is a sequence of lines where each line has a number at the start, and ends with a |# character sequence. On each line is a part of the message which will either be a HDR, SHD, ITEM, SPEC or TRL record. Therefore this is the simplest way to model this.
| Code: |
Message [CT : AED, Del=|# ]
- lineElement [CT : Seq, AED, Del=| ] {Repeat=Yes, RED = |# }
- lineNumber [ STRING ]
- taggedPart [Nested CT : Seq, TDS=|, Tagged Delimited, Del=|]
- HeaderStructure [Tag = HDR ]
- headerElement1 [ STRING ]
- headerElement2 [ STRING ]
- headerElement3 [ STRING ]
- SHDStructure {Tag = SHD } [CT : AED, Del=| ]
- SHDElement1 [ STRING ]
- SHDElement2 [ STRING ]
- SHDElement3 [ STRING ]
- SHDElement4 [ STRING ]
- ItemStructure {Tag = ITEM } [CT : AED, Del=| ]
- ItemElement1 [ STRING ]
- ItemElement2 [ STRING ]
- ItemElement3 [ STRING ]
- SpecStructure {Tag = SPEC } [CT : AED, Del=| ]
- SpecElement1 [ STRING ]
- SpecElement2 [ STRING ]
- SpecElement3 [ STRING ]
- SpecElement4 [ STRING ]
- SpecElement5 [ STRING ]
- TrailerStructure {Tag = TRL } [CT : AED, Del=| ]
- TrailerElement1 [ STRING ]
- TrailerElement2 [ STRING ]
- TrailerElement3 [ STRING ]
|
I've give this ago, and it parses the sample message you provided. It will maintain the order of your input message and this will be transferred to the output message (Ie the repeating doesnt group elements such that they lose order).
The problem with this simple modelling is that it doesn't work towards having any validation built in to it. Although, the order of the input message is maintained in the message tree, an input message in any order can be sent into the flow. Ie, the parser would accept a message that has SPEC records, Item records, Header, Trailer and SHD records in any order, and of any amount.
So based on this, it is now your choice as to whether you wish to pursue a more complex TDS model that would support validation of a single HDR record, single SHD record, followed by any number of Item records, that in turn could have any number of Spec records, and finally followed by a trailer record.
Alternatively, you could go with the simpler TDS model, and put the validation in your ESQL as you process the input message tree. So as an example, you may start off with something like :
| Code: |
DECLARE inputRef REFERENCE TO InputRoot.MRM.lineElement[1];
DECLARE currentLine REFERENCE TO InputRoot.MRM.lineElement[1];
DECLARE expected CHAR 'HeaderStructure';
WHILE LASTMOVE(inputRef) DO
MOVE currentLine TO inputRef;
--Move to the line Number
MOVE currentLine FIRSTCHILD;
--Move to the structure in this line record
MOVE currentLine NEXTSIBLING;
IF POSITION(FIELDNAME(currentLine) IN expected) = 0 THEN
THROW USER EXCEPTION VALUES('Msg Content Sequence Error');
END IF;
IF FIELDNAME(currentLine) = 'HeaderStructure' THEN
-- Process header record as required
SET expected = 'SHDElement';
END IF;
...
....
IF FIELDNAME(currentLine) = 'SpecStructure' THEN
-- Process the spec structure as required
SET expected = 'SpecStructure:ItemStructure:TrailerStructure';
END IF;
MOVE inputRef NEXTSIBLING NAME 'lineElement';
END WHILE;
....
|
You may find this easier to ensure order than handle MRM parser errors, but that is your choice. If you would prefer to keep the validation within the MRM parsing stage, then let me know. But for know I hope this helps and gives you some pointers.
_________________
Regards
Craig |
|
| Back to top |
|
|
| asamanta |
| Posted: Mon Aug 25, 2003 1:29 am Post subject: |
|
|
Novice
Joined: 20 Aug 2003
Posts: 18
|
Much obliged Craig! Thnaks to your answer, I now have a clearer perspective of how to model similar TDS messages
I believe that from maintenance angle, the present structure along with the eSQL code sample provided by you should suffice.
However for knowledge enrichment of I & fellow mqseries.net users it would be helpful if you could find time to elaborate on introducing message validation within the message structure making the eSQL code redundant!
Best regards, |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
