| Author |
Message
|
| Ramphart |
 Posted: Tue Feb 20, 2007 12:46 am Post subject: Fixed Length Message Issue - WMB 6.0 |
 |
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
- Windows Platform
- Message Broker 6.0 (Ver 6.0.0.1)
- Toolkit 6.0 (Ver 6.0.0.1)
I've migrated a fixed length message set from Ver 2.1 with the following layout:
Sample Input Message (Fixed Length)
NameA..........SurnameA..............<LF>
NameBBB......SurnameBBBBBBB..<LF>
NameCCCCC.SurnameCC...........<LF>
Message Set Structure
-Message ([Ordered Set,Closed] TDS: 'DES' = All elements delimited - 'Delimiter' = <LF> )
--Msg (Local Complex Type, Repeating Element Delimiter <LF>
--- LocalComplexType ([Ordered Set,Closed] TDS: 'DES' = Fixed Length)
----Name (String) length etc
----Surname (String) length etc
Notes:
1. In Ver 2.1 the message parse fine but I get an exception in Ver 6.0 "<Text>Not enough data in bitstream</Text>"
2. The problem seems to be the last <LF> in the message. If I remove it from the message then it parses fine in Ver 6.0
3. Is this a bug in Version 6.0? How can I go about parsing the message as usual without having to remove the last <LF>
4. It's worth noting that if I parse a comma delimited file for instance and thus model a message as "all elements delimited" with say , (comma) as the field separator then a repeated message including the last <LF> parses fine in Ver 6.0
Please assist
_________________
Applications Architect |
|
| Back to top |
|
 |
| kimbert |
| Posted: Tue Feb 20, 2007 1:28 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
In an ideal world, every v2.1 message set would migrate painlessly to v6.0. 
In this case, I suggest you add a Group Terminator of '<LF>' to either Msg or Message. |
|
| Back to top |
|
|
| Ramphart |
| Posted: Tue Feb 20, 2007 2:14 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
| kimbert wrote: |
| I suggest you add a Group Terminator of '<LF>' to either Msg or Message. |
Hi,
I've actually tried the Group Terminator before posting to this site. Did not do the trick. Thats why I'm wondering if it's a bug with the tool.
Please assist.
_________________
Applications Architect |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Feb 20, 2007 2:48 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I've actually tried the Group Terminator before posting to this site. Did not do the trick. |
Can I suggest that you try it again? There is no good reason why it should not work - this is a common scenario, and I've seen it work many times. |
|
| Back to top |
|
|
| Ramphart |
| Posted: Wed Feb 21, 2007 3:26 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
| kimbert wrote: |
| Quote: |
| I've actually tried the Group Terminator before posting to this site. Did not do the trick. |
Can I suggest that you try it again? There is no good reason why it should not work - this is a common scenario, and I've seen it work many times. |
Hi,
I've tried it again and it does not work. It works for a one record message which makes sense because the Group Indicator will consume the <LF>. For more than one record a <LF><LF> will probably be required where one indicates the Group Terminator and the other for the Repeating Element Delimiter.
I'm seriously wondering if this is a bug within the broker because an "All Elements Delimited" type works just fine whether a message has a <LF> or not at the end of the record.
This is becoming critical for me. Can someone please assist. Thx a million.
P.S. It really seems that because the broker finds a <LF> it automatically expects another fixed length record to follow.
_________________
Applications Architect |
|
| Back to top |
|
|
| santy |
| Posted: Wed Feb 21, 2007 3:50 am Post subject: |
|
|
Centurion
Joined: 03 Nov 2006
Posts: 141
|
I think you haven't set the length of the String elements.
Or if you have set then the data is exceeding or is not meeting the actual length of the element.
If you are using fixed length then you have to set the length of the element, and your input message also must meet the length of the element. |
|
| Back to top |
|
|
| Ramphart |
| Posted: Wed Feb 21, 2007 5:12 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
| santy wrote: |
I think you haven't set the length of the String elements.
Or if you have set then the data is exceeding or is not meeting the actual length of the element.
If you are using fixed length then you have to set the length of the element, and your input message also must meet the length of the element. |
Santa - everything is set just fine. The only problem is that the message fails when there is a <LF> at the end of the message. Otherwise it parses fine. Please read the issue carefully from the top.
_________________
Applications Architect |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Feb 21, 2007 6:27 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Hi Ramphart,
Here's what you need:
| Code: |
message1 [ Type='message1Type' ]
Complex Type 'message1Type [ DES=TaggedFixedLength Length Of Tag=0 ]
Local Element 'Msg' [ Type='MsgType' maxOccurs=-1]
Complex Type 'MsgType [ DES=FixedLength Group Terminator=<LF>]
Local Element Name [ length=15 ]
Local Element Surname [ length=15 ]
|
Apologies for not believing you earlier  |
|
| Back to top |
|
|
| Ramphart |
| Posted: Wed Feb 21, 2007 11:56 pm Post subject: |
|
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
Hi Kimbert,
The solution you posted works like a charm.. Thx a million.
Would you mind to explain how the broker interprets the message with the solution that did not work? Or the difference between how the broker interprets the message with the one that works and the one that does not. I just need to make sense of this for future use.
Thx
_________________
Applications Architect |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Feb 22, 2007 1:29 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I'll try...
In the v2.1 solution, the final <LF> was being interpreted as a Repeating Element Delimiter. However, your model also allows for it to be interpreted as a Delimiter for Msg or Message.
The TDS parser has a fairly clear set of rules about how to resolve conflicts like this. If a piece of markup can be interpreted in more than one way, it takes the 'nearest' match first ( i.e. the innermost definition ). So it starts with RED. If that does not work, it tries delimiter for Msg. If that doesn't work, it tries delimiter for Message. That scheme works OK when the lines are All Elements Delimited, because the TDS parser never commits itself to parsing delimited data unless there actually is data present.
However, when the line is Fixed Length the TDS parser must assume that the line is there ( there is no way to tell whether it is there or not ). It attempts to parse the line, finds that it is empty, and throws a parsing exception.
My solution looks at the problem differently. I viewed your message as an unbounded sequence of fixed-length records, each terminated by <LF>. In v6.0 the TDS parser is rather good at handling things which repeat without limit. But what if the final Group Terminator is missing? Well, the TDS parser has always treated Group Terminators as optional - for exactly this reason.
So this is a change of behaviour in the v6.0 TDS parser. That is not ideal, but overall I think the change is good because the v6.0 model is a little cleaner than the v2.1 model ( it only defines the <LF> in one place ). |
|
| Back to top |
|
|
|
|
