Author |
Message
|
MQEnthu |
Posted: Thu Aug 09, 2012 6:33 am Post subject: Missing fields at end for fixed length message |
|
|
 Partisan
Joined: 06 Oct 2008 Posts: 329 Location: India
|
Hi,
I am reading a fixed length message where in the couple of fields at the end of record are missing.
I am using MRM fixed length data seperation method for parsing this message. And it gives exception saying not enough data for the missing fields as expected.
I was woundering if the fields at the end are missing, if there is an option to set at message set level, so that it does parse the message. But I could not find any thing like that.
Could you please let me know if it is possible to set this option for normal fixed length messages?
Thank you. _________________ -----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Aug 09, 2012 6:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You can mark the fields as occurring 0 to 1 times. This marks them as optional.
However, if there is no way to determine that you have reached the end of one record, you may find that a pure-fixed length model decides that the fields at the start of the next record are actually part of this record.
So you may need to use Variable length elements delimited and a delimiter to indicate that the record has finished.
Otherwise, you'll have to use a data pattern, and hope that you can tell the difference between the last optional field of one record and the start of the next record. |
|
Back to top |
|
 |
MQEnthu |
Posted: Mon Aug 13, 2012 12:44 am Post subject: |
|
|
 Partisan
Joined: 06 Oct 2008 Posts: 329 Location: India
|
Yes, I have marked the fields as optional by setting min occurance to 0. However it is not working.
I have the delimiter new line between each record. And record containing many fields have been modelled as fixed length. And couple of fields in the end of each record are optional. If the fields are missing in between, they are sending the spaces, but if it is at the end, they do not send any space. And in that case my message set does not parse the input. _________________ -----------------------------------------------
It is good to remember the past,
but don't let past capture your future
Last edited by MQEnthu on Tue Feb 11, 2014 1:47 am; edited 1 time in total |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Aug 13, 2012 4:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Okay, so you have a delimiter at the end of the record.
It may occur immediately after the last non-optional field in the record, right?
so first question- is Broker processing the record with the missing fields correctly, and then NOT parsing everything else correctly?
Or is it not parsing the record with the missing fields correctly?
There is also a difference between TDS and CWF. I assume you're using TDS. |
|
Back to top |
|
 |
MQEnthu |
Posted: Mon Aug 13, 2012 5:58 am Post subject: |
|
|
 Partisan
Joined: 06 Oct 2008 Posts: 329 Location: India
|
yes, I am using TDS.
And if the last optional fields presnt, then it works all fine. If they are missing it gives parsing error. And I am reading the message.
sorry, Did you mean, CWF will do if the last optional fields are missing? _________________ -----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Aug 13, 2012 6:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
MQEnthu wrote: |
yes, I am using TDS.
And if the last optional fields presnt, then it works all fine. If they are missing it gives parsing error. And I am reading the message.
sorry, Did you mean, CWF will do if the last optional fields are missing? |
No, CWF is the wrong thing to use. TDS is the right thing.
When the message fails to parse, what is the last field that it parses?
Is it the last field before the optional ones? Or is it one of the fields after the optional one.
You may need to run a User Trace (this is *not* a Trace node) to find out this information. |
|
Back to top |
|
 |
MQEnthu |
Posted: Mon Aug 13, 2012 6:10 am Post subject: |
|
|
 Partisan
Joined: 06 Oct 2008 Posts: 329 Location: India
|
I could see it in the debug mode that it is parsing till the optional fields. _________________ -----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Aug 13, 2012 6:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
MQEnthu wrote: |
I could see it in the debug mode that it is parsing till the optional fields. |
Take a User Trace.
The complex type that contains the optional fields (call it RecordA) should be fixed length.
The complex type that contains the complex type RecordA (call it Body) should be either variable length elements delimited or tagged-delimited.
The delimiter should be set on Body, not on RecordA. |
|
Back to top |
|
 |
MQEnthu |
Posted: Mon Aug 13, 2012 6:20 am Post subject: |
|
|
 Partisan
Joined: 06 Oct 2008 Posts: 329 Location: India
|
Yes, thats absolutely how our message is modelled. Body has been set to tagged delimited and delimiter and length of tag has been set at body. Tag has been set at RecordA.
I will try to get the trace and post it _________________ -----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
Back to top |
|
 |
Vitor |
Posted: Mon Aug 13, 2012 6:22 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
MQEnthu wrote: |
I could see it in the debug mode that it is parsing till the optional fields. |
Two things to remember:
- The debugger has to parse the message itself to show it in the tree
- The debugger shows you what's happened, not how it happened. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
kimbert |
Posted: Tue Aug 21, 2012 12:52 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
You will need to set Data Element Separation to 'Use Data Pattern'. That is the only way to parse those optional fields at the end of the record.
If you want to continue using 'Fixed Length' for the non-optional fields then create a structure like this:
Code: |
element record
complex type
sequence DataElementSeparation='Tagged Delimited' TagLength=0 delimiter='<CR><LF>'
sequence DataElementSeparation='Fixed length'
nonOptionalField1 length=5
nonOptionalField2 length=10
...
sequence Data Element Separation='Use Data Pattern'
optionalField1 dataPattern='([^\r]){5}' minOccurs=0
optionalField2 dataPattern='([^\r]){10}' minOccurs=0
... |
Not tested, and the data patterns might be syntactically wrong, but that's the best approach. |
|
Back to top |
|
 |
|