|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
|
|
IIB9 - Parsing Error Not Throwing An Exception |
« View previous topic :: View next topic » |
Author |
Message
|
bdaoust |
Posted: Thu Nov 03, 2016 9:36 am Post subject: IIB9 - Parsing Error Not Throwing An Exception |
|
|
Centurion
Joined: 23 Sep 2010 Posts: 130
|
Hello everyone:
I'm seeing the following error after the input bode in the MRM Message Tree:
ImbRecoverableException caught from worker->parseNext. Looking at the trace it's due to invalid data against the decimal data type defined in the message model.
According to the information I read in the docs, there is sometimes some handling of a bad datatype, but the request of the message tree isn't complete, so it looks like it just stopped building the tree, didn't throw an exception (ExceptionList is null) and moved on.
Also in the documentation, reads:
"A limited amount of validation occurs by default if you leave the validation settings unaltered. At this default level, an exception is thrown if one of the following statements is true:
A data mismatch occurs; for example, the parser cannot interpret the data that is provided for the field type specified. "
So the trace is telling me that the data is invalid for the defined data type, but it's not throwing an exception.
Do I really need to turn on validation in the input node to ensure proper data structure? The above paragraph appears that is not the case, but an exception is definitely not being thrown.
Thanks,
Brian |
|
Back to top |
|
|
Craig B |
Posted: Thu Nov 10, 2016 3:04 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003 Posts: 316 Location: UK
|
You should get a parser exception from the MRM parser when it cannot form a message tree value. If it can form a valid value then you would need validation to check that value against the logical constraints defined in the MRM message model.
From the description you are getting a parser exception:
ImbRecoverableException caught from worker->parseNext.
But what is confusing is that you say you are getting this as part of message body in the MRM tree.
The only time I have ever seen this happen is when the Flow Debugger is attached and your are viewing the tree in the flow debugger. This is done to show the user that the tree is not complete and had an error.
Are you using the flow debugger? If so you will find that when you run the flow without the flow debugger attached it will throw an exception with an Exception List that you can handle. _________________ Regards
Craig |
|
Back to top |
|
|
timber |
Posted: Thu Nov 10, 2016 4:02 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015 Posts: 1290
|
I agree with CraigB - this is almost certainly caused by the debugger. Arguably it's a defect, because the debugger should not change the behaviour of the message flow.
Most experienced IIB developers use the debugger at first, but fall back to user trace/Trace nodes when the debugger's limitations start to show.
btw...is there a good reason why you are using the MRM domain? Is your input an XML message, or something else? |
|
Back to top |
|
|
bdaoust |
Posted: Fri Nov 11, 2016 7:00 am Post subject: |
|
|
Centurion
Joined: 23 Sep 2010 Posts: 130
|
timber / Craig B :
Thank you for the replies.
I've actually adopted this message flow and I believe it was written a long time ago. Most of our flows use the MRM. Basically the input message is from our mainframe system, so we apply a copybook definition as the message model and usually converted it to XML for the output. If there is a better way to do this or things to think about, I'm always eager to learn and try new approaches and not afraid to change things up.
You're both right. I was using the debugger. I can only use Trace nodes as I don't have direct access to the server the broker runs on. Is it safe to assume that a true user trace can only be viewed if I had access to the server? I've tried doing a trace node output to a file with the pattern of ${Root}. Does that give me everything a user trace would? I thought I remember the answer to that is no.
Anyway, I'm just surprised that according to the error, there seems to be a datatype mismatch, but there is nothing populated in the exception tree after the input node. I'm trying to figure out how I can check for data type errors and throw it to an exception so that I can alert the mainframe guys there might be bad data in the records. Perhaps I just need to do some checking in an ESQL node and do a throw? Or am I over complicating it?
Thanks,
Brian |
|
Back to top |
|
|
fjb_saper |
Posted: Fri Nov 11, 2016 1:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003 Posts: 20729 Location: LI,NY
|
I do think you're overcomplicating it....
By the way if you have IIB you should be using a DFDL model. Just like with MRM import the COBOL copy book.
Have fun _________________ MQ & Broker admin |
|
Back to top |
|
|
timber |
Posted: Fri Nov 11, 2016 1:53 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015 Posts: 1290
|
Quote: |
Basically the input message is from our mainframe system, so we apply a copybook definition as the message model and usually converted it to XML for the output. |
As fjb_saper says, DFDL can do everything that MRM can do. For the output side, you should really be using XMLNSC and not MRM. But that's just a comment about best practices; switching to DFDL/XMLNSC will not fix the issue that you asked about.
Quote: |
I can only use Trace nodes as I don't have direct access to the server the broker runs on. Is it safe to assume that a true user trace can only be viewed if I had access to the server? |
Yes, and that's by design. A message flow developer should have full access to the development server for exactly these reasons. But looks as if you are limited to using the debugger and Trace nodes for now.
Quote: |
I've tried doing a trace node output to a file with the pattern of ${Root}. Does that give me everything a user trace would? I thought I remember the answer to that is no. |
No - not even close to same level of detail.
Quote: |
I'm just surprised that according to the error, there seems to be a datatype mismatch, but there is nothing populated in the exception tree after the input node. |
Me too, but product defects tend to be surprising. If you disconnect the debugger it should stop this happening. The exception will have its normal effect, your standard exception handling code will kick in, and you should see the error logged in whatever location your message flow uses for unhandled exceptions.
Quote: |
I'm trying to figure out how I can check for data type errors and throw it to an exception so that I can alert the mainframe guys there might be bad data in the records. Perhaps I just need to do some checking in an ESQL node and do a throw? Or am I over complicating it? |
Yes, you are. There is nothing special about data parsing errors. They are just 'recoverable exceptions' like all the others. Disconnect the debugger and relax |
|
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
|
|
|
|