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 » Special Char causing evaluateXPath to fail

Post new topic  Reply to topic Goto page 1, 2  Next
 Special Char causing evaluateXPath to fail « View previous topic :: View next topic » 
Author Message
deepeshk79
PostPosted: Tue Jul 29, 2014 2:02 pm    Post subject: Special Char causing evaluateXPath to fail Reply with quote

Apprentice

Joined: 25 Mar 2007
Posts: 45
Location: Los Angeles

Hi - below is an issue that we are getting while doing an xpath on a parsed FLM message with message set.
Code is
Code:

List<MbElement> mbElements = (List<MbElement>) rootElmt.getLastChild().evaluateXPath(xPath);

This code works when I have a good character message, but when a special char comes in - it fails xpath evaluation and throws the below exception.
Special Char - check the u with a dash on top..
Code:

BNF BK:ITAúUNIBANCO

Incoming CCSID, encoding is 819, 273
Exception in logs
Code:

2014-07-29 08:55:08,907 - ERROR - Thread-97 - BBAQBKL03EGS100 -  -  -  -  - NonXMLIdentificationStrategy - Failed to Evaluate XPath Expression for MbElement /OOPCDRCZ_REQUEST/OOPCDRCZ_TRAN_ID with [BIPmsgs:5285]BIP5285E: Parsing errors have occurred.  Message set name: OOPTypeV001  Message format: CWF1  Message type path: /msg_CHAPTEROOPCDRCZ/OOPCDRCT_REQUEST/OOPCDRCZ_APPL_REQUEST_DATA/OOPCDRCZ_ISI_TRAIL/OOPCDRCZ_ISI_TRAIL_CR_LF
Review other error messages to find the cause of the errors. : ImbRecoverableException caught from worker->parseNext.
<com.ibm.broker.plugin.MbParserException class:JNI method:MtiImbParser::parseLastChild source:BIPmsgs key:5285 >
 at com.ibm.broker.plugin.MbElement._getLastChild(Native Method)
 at com.ibm.broker.plugin.MbElement.getLastChild(MbElement.java:1787)
 at com.test.rp.engine.v004.broker.id.NonXMLIdentificationStrategy.getMbElementUsingXPath(NonXMLIdentificationStrategy.java:316)
 at com.test.ky.seg.wer.broker.id.NonXMLIdentificationStrategy.identify(NonXMLIdentificationStrategy.java:81)
 at com.test.ky.seg.wer.broker.id.FrameworkIdentificationStrategy.identify(FrameworkIdentificationStrategy.java:31)
 at com.test.ky.seg.wer.broker.BrokerMessageSystem.identify(BrokerMessageSystem.java:199)
 at com.test.ky.seg.wer.broker.BrokerMessageSystem.execute(BrokerMessageSystem.java:87)
 at com.test.ky.seg.wer.broker.framework.AbstractBrokerMessageSystem.execute(AbstractBrokerMessageSystem.java:10)
 at com.test.ky.seg.wer.broker.jcn.MessageSystemJCN.evaluate(MessageSystemJCN.java:179)
 at com.ibm.broker.javacompute.MbRuntimeJavaComputeNode.evaluate(MbRuntimeJavaComputeNode.java:268)
 at com.ibm.broker.plugin.MbNode.evaluate(MbNode.java:1480)

Any inputs on this ? Pls share.
Back to top
View user's profile Send private message AIM Address
kimbert
PostPosted: Wed Jul 30, 2014 3:28 am    Post subject: Reply with quote

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

Probably nothing to do with XPath.
You have set 'Parsing timing' to 'On demand' ( correctly ). So the MRM parser does not do any parsing until you try to access the message tree. Your XPath tries to access the message tree and causes the MRM parser to do some parsing.

In other words, you need to diagnose your parsing problem.
Best way to do that is to get the full text of the error from the MRM CWF parser. User trace or the mqsiexplain command will help you with that.

btw, the BIP5285 is probably a high-level exception detected by the XPath engine. The real error is something else, and will be in the user trace or in the exception list.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too.
Back to top
View user's profile Send private message
deepeshk79
PostPosted: Wed Jul 30, 2014 11:25 am    Post subject: Reply with quote

Apprentice

Joined: 25 Mar 2007
Posts: 45
Location: Los Angeles

Hi Kimbert - below are more details
Incoming fixed length message is of size 1209, so we need to first convert that to size 1697 to match msg set size
Code:

//Convert incoming message to bytes
byte[] bytes = inBody.toBitstream(null, null, null, outEncoding, outCcsId, 0);

//Then get that in String format
msgAsText = new String(bytes);

//Now append spaces to this text to make it 1697 characters
msgAsText = String.format((new StringBuilder("%-")).append(rec.getMaxPadLength()).append("s").toString(), new Object[] {msgAsText});

//Now create outBody again
outBody = outRoot.createElementAsLastChildFromBitstream(msgAsText.getBytes(), parserName, messageName, messageSet, wireFormat, outEncoding, outCcsId, 0);
//MRM msg_CHAPTEROOPCDRCT FixedMsgSet_Req CWF1 273 1208 0


After this we pass this as input to Xpath function as the message now is as per message set
Code:

//Now pass this as input to
MbElement parsedElement =getMbElementUsingXPath(parsedRoot, rule.getName());

//Use Xpath
List<MbElement> mbElements = (List<MbElement>) rootElmt.getLastChild().evaluateXPath(xPath);

I'm still waiting on trace details from support but am I doing something wrong here ?

Thanks
Back to top
View user's profile Send private message AIM Address
Vitor
PostPosted: Wed Jul 30, 2014 11:42 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

deepeshk79 wrote:
Incoming fixed length message is of size 1209, so we need to first convert that to size 1697 to match msg set size


Erm....if the message you're attempting to model is 1209 bytes long, why does the message set that describes it say it's 1697 bytes long?

deepeshk79 wrote:
am I doing something wrong here ?


Well fiddling with the message in Java to make it match the message set is never that good an idea. Given that you have a message with special characters and you're converting it to a string (which may or may not be in a code page which supports those characters), after which you hit a problem handling the special characters does sound slightly suspicious to me.....
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
deepeshk79
PostPosted: Wed Jul 30, 2014 12:26 pm    Post subject: Reply with quote

Apprentice

Joined: 25 Mar 2007
Posts: 45
Location: Los Angeles

Vitor - yes the requirment is that clients can send the last element in the message set of variable length, so the size of input message may vary but the max will be always 1697.

While converting to string - used the same CCSID and Encoding that is used to reconvert to MbElement, will this be a problem then ?
Back to top
View user's profile Send private message AIM Address
mqjeff
PostPosted: Wed Jul 30, 2014 12:39 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

deepeshk79 wrote:
Vitor - yes the requirment is that clients can send the last element in the message set of variable length, so the size of input message may vary but the max will be always 1697.

So change the model to reflect that.
Back to top
View user's profile Send private message
deepeshk79
PostPosted: Wed Jul 30, 2014 1:47 pm    Post subject: Reply with quote

Apprentice

Joined: 25 Mar 2007
Posts: 45
Location: Los Angeles

Jeff I cant change the model as of now

Without a special char this works like a charm...
Back to top
View user's profile Send private message AIM Address
fjb_saper
PostPosted: Wed Jul 30, 2014 2:26 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Your problem could be that the special character has more than 1 byte.
So if your message has a max of x bytes and not y chars you may well be having trouble if you add y-n bytes to make x...

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Thu Jul 31, 2014 4:22 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

deepeshk79 wrote:
Vitor - yes the requirment is that clients can send the last element in the message set of variable length


So why doesn't the message set reflect that the last element is of variable length?
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Jul 31, 2014 4:23 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

deepeshk79 wrote:
Jeff I cant change the model as of now


Why not? Especially as....

deepeshk79 wrote:
Without a special char this works like a charm...


....this sounds like justification for a change.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Jul 31, 2014 4:27 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

fjb_saper wrote:
Your problem could be that the special character has more than 1 byte.
So if your message has a max of x bytes and not y chars you may well be having trouble if you add y-n bytes to make x...


Especially as

deepeshk79 wrote:
While converting to string - used the same CCSID and Encoding that is used to reconvert to MbElement, will this be a problem then ?


I don't think that does exactly what the OP thinks it does. Obviously I'm the last person to talk about Java, but I feel somewhat justified given the problem the OP has posted.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
kimbert
PostPosted: Thu Jul 31, 2014 7:28 am    Post subject: Reply with quote

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

I can believe that changing the model would be tricky for some users.

@deepeshk79: You should be able to debug this yourself. You just need to think about every stage of the conversion. Here is one example of what I mean:
Code:
//Convert incoming message to bytes
byte[] bytes = inBody.toBitstream(null, null, null, outEncoding, outCcsId, 0);

//Then get that in String format
msgAsText = new String(bytes);

...and here is what the JavaDoc for that String constructor says:
Quote:
String(byte[] bytes)
Constructs a new String by decoding the specified array of bytes using the platform's default charset.


I hope you can see straight away that your code is likely to be unreliable.
I am not saying that this is your problem. Even if it is your problem, it might not be the only problem. So you need to look deeper.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too.
Back to top
View user's profile Send private message
deepeshk79
PostPosted: Thu Jul 31, 2014 8:48 pm    Post subject: Reply with quote

Apprentice

Joined: 25 Mar 2007
Posts: 45
Location: Los Angeles

Yes changing model will need a complete rewrite of code at different places. Btw I didnt code that
Back to the problem - Kimbert that's a very good point on String constructor, I changed code to pass Charset as a parameter to String constructor, but no luck - still fails.
Below is some info from trace - does this help ?
Code:

2014.07.31 23:37:34 - ERROR - [ ExceptionUtility-Thread-11 ] - the parent traceText:  ImbRecoverableException caught from worker->parseNext.
2014.07.31 23:37:34 - ERROR - [ ExceptionUtility-Thread-11 ] - level:0 :the child traceText:  ImbRecoverableException caught from worker->parseNext.
2014.07.31 23:37:34 - ERROR - [ ExceptionUtility-Thread-11 ] - the parent traceText:  MTI. Not all the buffer was used when reading message
[/code]

Ideally it should not fail for buffer length because when we convert to String from bytes, we check the length and then pad spaces, so if the length had gone up by 1 byte - the String Builder used to pad spaces should have added one space less.

msgAsText = String.format((new StringBuilder("%-")).append(rec.getMaxPadLength()).append("s").toString(), new Object[] {msgAsText});

String builder will it also need some sort of charset ?
Back to top
View user's profile Send private message AIM Address
kimbert
PostPosted: Fri Aug 01, 2014 2:01 am    Post subject: Reply with quote

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

I suggest that you look at every place in your code where you convert from bytes to characters or vice versa.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too.
Back to top
View user's profile Send private message
deepeshk79
PostPosted: Fri Aug 01, 2014 7:37 am    Post subject: Reply with quote

Apprentice

Joined: 25 Mar 2007
Posts: 45
Location: Los Angeles

Interesting thing is when i change the code to
Code:
msgAsText = String.format((new StringBuilder("%-")).append(rec.getMaxPadLength()-1).append("s").toString(), new Object[] {msgAsText});


It worked i.e. i reduced of spaces to be appended by 1 character rec.getMaxPadLength()-1
I need to go back and see how the String Builder works, my understanding was it dynamically will append spaces to max length i.e. check for incoming string len and then append spaces to make it match max length.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Special Char causing evaluateXPath to fail
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.