ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » IIB9 - Parsing Error Not Throwing An Exception

Post new topic  Reply to topic
 IIB9 - Parsing Error Not Throwing An Exception « View previous topic :: View next topic » 
Author Message
bdaoust
PostPosted: Thu Nov 03, 2016 9:36 am    Post subject: IIB9 - Parsing Error Not Throwing An Exception Reply with quote

Centurion

Joined: 23 Sep 2010
Posts: 128

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
View user's profile Send private message
Craig B
PostPosted: Thu Nov 10, 2016 3:04 am    Post subject: Reply with quote

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
View user's profile Send private message
timber
PostPosted: Thu Nov 10, 2016 4:02 am    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1280

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
View user's profile Send private message
bdaoust
PostPosted: Fri Nov 11, 2016 7:00 am    Post subject: Reply with quote

Centurion

Joined: 23 Sep 2010
Posts: 128

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
View user's profile Send private message
fjb_saper
PostPosted: Fri Nov 11, 2016 1:38 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
timber
PostPosted: Fri Nov 11, 2016 1:53 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1280

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » IIB9 - Parsing Error Not Throwing An Exception
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.