| Author |
Message
|
| jbanoop |
 Posted: Thu Mar 26, 2009 4:37 pm Post subject: TDS Message Modelling Question |
 |
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Hi All,
I had a TDS message modelling requirement which I have been working on.
the fixed length structure is :
H010 ........<header fields>
D010 ........<D010 fields>
D020 ........<D020 fields>
T010 ........<Trailer fields>
Here the header (H010) and trailer (T010) occur only once.
However the detail block can have multiple occurances of the D010 and D020 records. They occur in pairs and always alternate (D010 followed by D020).
I am using TDS to model the message, defining a group each for the header, detail and trailer blocks.
The Header has a group indicator of H010 and a group delimiter of <cr><lf>
The Trailer has a group indicator of T010 and a group delimiter of <cr><lf>.
I have tried to model the detail part in this manner:
Detail_block : Group - (Sequence, closed)
- D010_block: Group : grp indicator:D010 Grp Terminator: <cr> <lf> - min and max Occurance 1
- D020_block: Group : grp indicator:D020 Grp Terminator: <cr> <lf> - min and max occurance 1
I have given a reference to the Detail_block group in the message with a min occurence of 1 and max occurence of -1.
While trying to parse the message having one pair of the D010 and D020 records, the parser is parsing the two recrods successfully, but instead of going to the next record (T010) it is trying to search for another occurence of the detail_block and thus erroring out.
Can anyone point out what I am missing (If my explaination of the problem above made any sense)
Regards, |
|
| Back to top |
|
 |
| kimbert |
| Posted: Fri Mar 27, 2009 3:33 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Makes perfect sense. Like many before you, you are expecting the TDS parser to look ahead to the next element ( Trailer ) and see whether it is present *before* parsing another occurrence of your Detail_block group. That is not how it works, and it would be very hard to make it work that way without breaking other scenarios.
You need a model like this
| Code: |
Message
Header
Choice group maxOccurs="-1"
Trailer
Detail_block |
This will force the parser to look for a Trailer block before parsing a Detail_block.
As I have said before, the human brain is so good at parsing text that we don't realise how complex it is. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Mar 27, 2009 5:37 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Your real problem is that you are setting Data Element Separation to 'All Elements Delimited' and using Group Indicators. You should be setting Data Element Separation to 'Tagged Delimited' and using Tags. That will allow you to use this model, which is much more natural:
| Code: |
Message DataElementSeparation="Tagged Delimited" TagLength="4" Delimiter="<CR><LF>"
Header Tag="H010"
Details_group
Detail10 Tag="D010"
Detail20 Tag="D020"
Trailer Tag="T010" |
Credit to mqjeff for prompting me to think some more about this. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Fri Mar 27, 2009 6:20 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi kimbert,
The second solution I understand, but the first one...
Wouldn't it accept the following inputs also, which it shouldn't ?
H010 ........<header fields>
D010 ........<D010 fields>
D020 ........<D020 fields>
T010 ........<Trailer fields>
T010 ........<Trailer fields>
AND
H010 ........<header fields>
D010 ........<D010 fields>
D020 ........<D020 fields>
T010 ........<Trailer fields>
D010 ........<D010 fields>
D020 ........<D020 fields>
Regards. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Mar 27, 2009 7:15 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Hi elvis,
Yes, you're absolutely correct. At the time when I suggested it, I thought that was the only solution. I really shouldn't post that early in the morning  |
|
| Back to top |
|
|
| jbanoop |
| Posted: Fri Mar 27, 2009 9:34 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Kimbert,
Thanks for the suggestions. I will work on modelling it using the second approach. One thing I have always faced when trying to model a message set in MB is which general approach to adopt.
In many cases if I realize that I did not use the correct approach at the outset which was the root cause of the inflexibility in the resuting message set.
I will post the results and the structure I used when I have tried this out. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Fri Mar 27, 2009 10:02 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Kimbert,
I am trying to implement what you have advised. I am dealing with fixed length data, so I presume I should be dealing with 'tagged fixed length'. My understanding of this format is that each data value should be preceded by the tag.
However the data I am dealing with has the record indicator (H010, D010, D020, T010) only at the beginning of the record, followed by fixed length fields.
EG: D010abcd100000.......
Would the approach #2 (using Tagged Fixed Length) work in this case ?
I am not sure if I am asking something basic but message sets never cese to confuse me  |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Mar 27, 2009 12:55 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
These are valid questions. Message sets continue to confuse me as well
Adjusting for the new information, your model should now be something like this:
| Code: |
Message DataElementSeparation="Tagged Fixed Length" TagLength="4" GroupTerminator="<CR><LF>"
Header Tag="H010"
Details_group DataElementSeparation="Tagged Fixed Length" TagLength="4" GroupTerminator="<CR><LF>" maxOccurs="-1"
Detail10 Tag="D010"
Detail20 Tag="D020"
Trailer Tag="T010" |
* "Tagged Fixed Length" is correct for the outermost complex type, and for Details_group because in their case, all of their children *do* have a tag.
* The complex types for Header, Detail10,Detail20 and Trailer should have Data Element Separation of 'Fixed Length' because their children are untagged and fixed length.
You can use User Trace to debug your TDS message definitions - it can be a useful way to see where the parser is going wrong. But disconnect the debugger first. |
|
| Back to top |
|
|
|
|
