Author |
Message
|
bhanu506 |
Posted: Mon Jul 15, 2013 10:25 am Post subject: DFDL is not throwing correct exception |
|
|
Novice
Joined: 15 Jul 2013 Posts: 10
|
Hi
I am using DFDL to parse incoming CSV file and and I have defined a field as an integer and passing character in input.
The incoming file is failing as expected but not giving correct exception.
Foll. is the snip of my exception list.
<Text>An error occurred whilst parsing with DFDL</Text>
<Insert>
<Type>5</Type>
<Text>CTDP3058E: Separator is missing for 'sequence' group contained within element........</Text>
</Insert>
The exception which I see in Exception list is no where related to invalid datatype.
Are there any settings do I need to follow to get exact exception in exception list.
Thanks
Bhanu |
|
Back to top |
|
 |
kimbert |
Posted: Mon Jul 15, 2013 1:23 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
The exception which I see in Exception list is no where related to invalid datatype. |
Have you looked at the DFDL trace yet? The trace will contain a full record of the parser's activities.
DFDL is a backtracking parser. That means that it keeps trying alternative routes through the model until there are no more possibilities. That can mean that the *reported* failure is quite different from the *first* failure. You can either
a) accept this state of affairs, and get into the habit of using DFDL trace to dignose modelling problems
or
b) add discriminators to your model to tell the parser that it is on the correct branch and it should not try alternative possibilities after an error.
In practice, you will need to do a) anyway because modelling a non-XML format is a programming task, and you need all the help you can get. |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Jul 15, 2013 9:17 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Fortunately, the Toolkit DFDL tools allow you to see this trace in Toolkit, when you test parse and test serialize models, without needing to deploy to runtime.
So it's much faster to debug this kind of thing. |
|
Back to top |
|
 |
bhanu506 |
Posted: Mon Jul 15, 2013 10:02 pm Post subject: |
|
|
Novice
Joined: 15 Jul 2013 Posts: 10
|
Thanks Kimbert and mqjeff for your suggestions.
I am able to see the exact error in DFDL trace using test parse Model.
"error: CTDP3043E: Text to number conversion error for string"
But is there any way to fetch this error trace into MB Exception List tree.
Thanks
Bhanu |
|
Back to top |
|
 |
kimbert |
Posted: Mon Jul 15, 2013 11:32 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
But is there any way to fetch this error trace into MB Exception List tree. |
Why would you want/need to do that? |
|
Back to top |
|
 |
bhanu506 |
Posted: Tue Jul 16, 2013 12:58 am Post subject: |
|
|
Novice
Joined: 15 Jul 2013 Posts: 10
|
The user need to be notified that what is wrong with his input.And will be easy for support person to identify the error. |
|
Back to top |
|
 |
kimbert |
Posted: Tue Jul 16, 2013 1:22 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Your problem seems to be as follows:
- Your message flow is parsing an input data format using DFDL
- If it fails, the message gets routed to a support queue
- You want the error message to tell the support engineer exactly what is wrong with the input data.
In general, that is very difficult to achieve but it may be possible to get close if the data format is quite simple. As I explained in my previous reply, you need to tighten up your DFDL model so that the parser does not backtrack after a processing error. To do that, you may need to add discriminators to your DFDL model. Or you may need to set 'initiatedContent' to 'yes' on one or more sequence groups.
If you describe your data format ( and include at least one example input message ) then I will be able to offer more specific advice. Please be sure to describe clearly how the parser knows which type of field/structure it is parsing. |
|
Back to top |
|
 |
|