| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Another TDS Definition Problem |
« View previous topic :: View next topic » |
| Author |
Message
|
| TDS_tds_tds |
 Posted: Thu Aug 28, 2003 3:01 pm Post subject: Another TDS Definition Problem |
 |
|
Novice
Joined: 31 Jul 2003
Posts: 16
|
I am working on TDS message set and awfully struck with definition/design issues.
As you see below, the input message encompasses 2 different header-body structures. First set of Header-structures starts with @@@ and ends with PERSONAL . Second set of Header-structures starts with @@@ and ends with NEWSINFO .
And each Header-Body structure can repeat n times. Headers ending with keyword PERSONAL would
appear ahead of records ending with keyword NEWSINFO.(.ie they are sorted records)
Both Header structures are of same length & starts with @@@ character and ends with either PERSONAL or NEWSINFO.
Body elements are comma delimited and fixed length.
I 've gone through some of the postings by Craig B and few other experts.But could not devise a solution from the postings.
Sample Message:
| Code: |
@@@ABC08282003PERSONAL
"Mike J ","ABC","NY","11234"
"Donald K ","DEF","CA","56742"
@@@XYZ11251999PERSONAL
"Marcus P ","HHH","MI","34764"
"Peter N ","ZZZ","KY","89076"
"Eric ","AAC","MD","76540"
@@@KLM10162000PERSONAL
"Robert P ","KLM","UT","57758"
@@@AAA12301995NEWSINFO
"NYTIMES","SPORTS "
"CNN ","WEATHER"
@@@ZZZ12301995NEWSINFO
"LANEWS ","HOME "
"CNN ","VIDEO "
|
I 've tried creating MESSAGE SET as follows :
| Code: |
- MyMessage [Nested CT : Seq, VLED, Del=<LF>]
- PERSONALHeader [CT, Seq, FL]
- headerElement1 [ STRING ] length:3
- headerElement2 [ STRING ] length:3
- headerElement3 [ STRING ] length:8
- headerElement4 [ STRING ] length:8
- PERSONALRecord [CT : VLED, Del=, {Repeat=Yes, RED=<LF>} ]
- PERSElement1 [ STRING ]
- PERSElement2 [ STRING ]
- PERSElement3 [ STRING ]
- PERSElement4 [ STRING ]
- NEWSHeader [CT, Ordered, FL]
- headerElement1 [ STRING ] length:3
- headerElement2 [ STRING ] length:3
- headerElement3 [ STRING ] length:8
- headerElement4 [ STRING ] length:8
- NEWSRecord [CT : VLED, Del=, {Repeat=Yes, RED=<LF>} ]
- NEWSElement1 [ STRING ]
- NEWSElement2 [ STRING ]
|
This above structure would not work.
I am sure that I missed few settings in the defintions. I am hoping this group has a solution for this problem.
Many Thanks in adv.
| Quote: |
Note: CT -> Compound Type, FL -> Fixed Length,
TD -> Tagged Delimited, LOT -> Length of Tag,
VLED -> Variable Length Elements Delimited,
Del -> Delimiter
RED -> Repeating Elements Delimiter
|
|
|
| Back to top |
|
 |
| TDS_tds_tds |
| Posted: Fri Aug 29, 2003 5:15 am Post subject: |
|
|
Novice
Joined: 31 Jul 2003
Posts: 16
|
| has anyone got a chance to look into this TDS problem ?? |
|
| Back to top |
|
|
| Craig B |
| Posted: Fri Aug 29, 2003 6:45 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
Hi,
I managed to have a quick glance at this when it was posted. There are a few alternatives that you could model to parse a message of this format. You can use a combination of Tagged structures and delimited children. Or you could use Data Pattern data element seperation to identify you elements (if you are feeling brave) or you could use multi-part messaging, where there are sub messages for the PERSONAL and NEWSINFO definitions, and you can use a message key to pick these up.
My own personal preference (which may not be yours) would be to aim for the first of these which would involve tagged and delimited data element separation techniques.
Before offering a structure that would parse this definition, it would be useful to have an extra piece of information. In your example you have double quotes (") in the message. Are these really in the message, or were you using them to highlight strings in your sample data. If they are in your message data, are they always in your message data? If they are always in your message data, do you mind if they do not appear in the data in your message tree?
_________________
Regards
Craig |
|
| Back to top |
|
|
| TDS_tds_tds |
| Posted: Fri Aug 29, 2003 7:32 am Post subject: |
|
|
Novice
Joined: 31 Jul 2003
Posts: 16
|
Thanks Craig for your quick response.
I now got lil confidence that I can solve this with your help.
For the questions regarding the double quotes,
Yes double quotes (") will always appear in the message data.
And they do not really need to be appear in the message tree.
This is sort of my first time to handle a complex TDS structure like this.
I feel that I quite did not understood all the three approaches posted.Pls bear with me if I post simple questions.
Yesterday,I attempted using multipart message pattern. But the Parser was unable to repeat
the PERSONAL and NEWSINFO sub messages 
Looking forward for your help.
Thanks again, |
|
| Back to top |
|
|
| Craig B |
| Posted: Wed Sep 03, 2003 2:14 pm Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
Hi,
Sorry for the delay in the response ... have been a bit tied up recently (not literally!). I've come up with one solution that will parse your message that you can take a look at and see if it fits your needs. When dealing with an unlimited number of repeats then you need to help the TDS parser out and give it some indication of when to stop these repetitions. When dealing with Tags then this is easy to do, but when dealing with Delimited elements then it becomes very difficult to say where the repetitions terminate. This because especially difficult when the repeating delimiter is the same delimiter as a parent. In this case, you have a situation where you have lines of an input message that are delimited by carriage returns, but once you identify PERSONAL or NEWSINFO records then you also have to rely on carriage return and line feed characters to control the repeating. When dealing with unbounded delimited repetitions then the design of the TDS parser is such that it looks for an omitted element to indicate the repetitions are complete. However, the users input bitstream is of a fixed format where an omitted element cannot be injected into the bitstream to terminate the repetitions. If this not possible, then some considerations need to be made in the MRM-TDS model to assist the TDS parser in its identification of when repeating starts and more importantly when it stops. In my previous update I asked if you wanted the double quotes in the message tree. This was important for coming up with a quick solution since we can make use of these double quotes to control the parsing.
In your message you have the main lines that start @@@ which have an element at the end which indicate whether PERSONAL records are to come, or NEWSINFO records are to come. The presence of another @@@ then indicate that the repeating PERSONAL or NEWSINFO records have stopped. For this reason, we defined a repeating master record that is within a tagged environment. This single repeating child has a tag of @@@. There are then two fixed length elements of lengths 3 and 8, and then we meet the characters that will define whether PERSONAL or NEWSINFO records are two come. We then enter a second tagged structure where the tag is identified by the Carriage return characters and a double quote (Tagged Data Separator in this case). This will then put us into a NEWSINFO structure or a PERSONAL structure. We now move away from the tagged environment and move into a delimited environment. Each line of the message now has four elements and these are separated by a comma. We then can have any number of lines one for each of the record we are dealing with and these are separated by carriage returns and line feed characters. This is where the problems start because the rest of the message also contains carriage return and line feed characters, meaning that the rest of the message will be consumed if a maxOccurs has not be set. So we give the parser a hand here and give it a way of identifying way it ends. Since we dont care about double quotes being in the data in the message tree, we use these in the mark-up. So the elements within each PERSONAL or NEWSINFO record are separated by "," characters. For the whole structure we then set a repeating element delimiter of carriage return, line feed and double quote "<CR><LF>". When another record is found then this will move us into the next repetition. But when the next line starts with @@@ then we will not get a match on this repeating delimiter and so this terminates the repetitions. It will leave us with a " and a carriage return and so we set group terminates are the tagged delimiter structure and the master repeating structure for @@@. We do this to absorb the "<CR><LF> left over at the end of the repeating block, and the single " at the end of the message where the last line doesnt have a <CR><LF> at the end of the line. Now Ive explained to you the method behind the madness, heres what it looks like as a model :
| Code: |
message [DES=TD, LOT=3, Del=N/A]
- masterRecord (E) {Tag=@@@, Repeat=Yes} [Seq, GT=<CR><LF>, DES=AED, Del=N/A]
- masterTypeFixed (CT) [DES=FL]
- masterElement1 (E) {Length=3}
- masterElement2 (E) {Length=8}
- masterTypeTagged (CT) [Seq, GT=",TDS=<CR><LF>",DES=TD,Del=N/A]
- personalRecords (E) {Tag=PERSONAL} [DES=AED,Del=","]
- personalRecord (E) {Repeat=YES} [DES=AED,Del="<CR><LF>"]
- personalElement1 (E)
- personalElement2 (E)
- personalElement3 (E)
- personalElement4 (E)
- newsRecords (E) {Tag=NEWSINFO} [DES=AED,Del=","]
- newsRecord (E) {Repeat=YES} [DES=AED,Del="<CR><LF>"]
- newsElement1 (E)
- newsElement2 (E)
|
Where :
(E) denotes an element or compound element.
(CT) denotes a direct nested compound type to change current parsing technique.
{} indicate attributes for the current element
[] indicates attributes for a compound type that the current entity is based on.
- DES = Data Element Seperation.
- Del = Delimiter
- LOT = length of tag
- Seq = Sequence
- GT = Group terminator.
I created a messageSet to test this out and this gave a message tree like the following :
| Code: |
(0x1000021)MRM = (
(0x1000013)masterRecord = (
(0x300000B)masterElement1 = 'ABC'
(0x300000B)masterElement2 = '08282003'
(0x1000013)personalRecords = (
(0x1000013)personalRecord = (
(0x300000B)personalElement1 = 'Mike J '
(0x300000B)personalElement2 = 'ABC'
(0x300000B)personalElement3 = 'NY'
(0x300000B)personalElement4 = '11234'
)
(0x1000013)personalRecord = (
(0x300000B)personalElement1 = 'Donald K '
(0x300000B)personalElement2 = 'DEF'
(0x300000B)personalElement3 = 'CA'
(0x300000B)personalElement4 = '56742'
)
)
)
(0x1000013)masterRecord = (
(0x300000B)masterElement1 = 'XYZ'
(0x300000B)masterElement2 = '11251999'
(0x1000013)personalRecords = (
(0x1000013)personalRecord = (
(0x300000B)personalElement1 = 'Marcus P '
(0x300000B)personalElement2 = 'HHH'
(0x300000B)personalElement3 = 'MI'
(0x300000B)personalElement4 = '34764'
)
(0x1000013)personalRecord = (
(0x300000B)personalElement1 = 'Peter N '
(0x300000B)personalElement2 = 'ZZZ'
(0x300000B)personalElement3 = 'KY'
(0x300000B)personalElement4 = '89076'
)
(0x1000013)personalRecord = (
(0x300000B)personalElement1 = 'Eric '
(0x300000B)personalElement2 = 'AAC'
(0x300000B)personalElement3 = 'MD'
(0x300000B)personalElement4 = '76540'
)
)
)
(0x1000013)masterRecord = (
(0x300000B)masterElement1 = 'KLM'
(0x300000B)masterElement2 = '10162000'
(0x1000013)personalRecords = (
(0x1000013)personalRecord = (
(0x300000B)personalElement1 = 'Robert P '
(0x300000B)personalElement2 = 'KLM'
(0x300000B)personalElement3 = 'UT'
(0x300000B)personalElement4 = '57758'
)
)
)
(0x1000013)masterRecord = (
(0x300000B)masterElement1 = 'AAA'
(0x300000B)masterElement2 = '12301995'
(0x1000013)newsRecords = (
(0x1000013)newsRecord = (
(0x300000B)newsElement1 = 'NYTIMES'
(0x300000B)newsElement2 = 'SPORTS '
)
(0x1000013)newsRecord = (
(0x300000B)newsElement1 = 'CNN '
(0x300000B)newsElement2 = 'WEATHER'
)
)
)
(0x1000013)masterRecord = (
(0x300000B)masterElement1 = 'ZZZ'
(0x300000B)masterElement2 = '12301995'
(0x1000013)newsRecords = (
(0x1000013)newsRecord = (
(0x300000B)newsElement1 = 'LANEWS '
(0x300000B)newsElement2 = 'HOME '
)
(0x1000013)newsRecord = (
(0x300000B)newsElement1 = 'CNN '
(0x300000B)newsElement2 = 'VIDEO '
)
)
)
)
)
|
If this is any use to you, then send me a private message with your email address and ill email you the MRP file that parses this sample message. if this doesnt meet your needs then we can make some refinements on the model.
Hope this helps.
_________________
Regards
Craig |
|
| 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
|
|
|
|
