Author |
Message
|
deepeshk79 |
Posted: Tue Jul 29, 2014 2:02 pm Post subject: Special Char causing evaluateXPath to fail |
|
|
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 |
|
 |
kimbert |
Posted: Wed Jul 30, 2014 3:28 am Post subject: |
|
|
 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 |
|
 |
deepeshk79 |
Posted: Wed Jul 30, 2014 11:25 am Post subject: |
|
|
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 |
|
 |
Vitor |
Posted: Wed Jul 30, 2014 11:42 am Post subject: |
|
|
 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 |
|
 |
deepeshk79 |
Posted: Wed Jul 30, 2014 12:26 pm Post subject: |
|
|
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 |
|
 |
mqjeff |
Posted: Wed Jul 30, 2014 12:39 pm Post subject: |
|
|
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 |
|
 |
deepeshk79 |
Posted: Wed Jul 30, 2014 1:47 pm Post subject: |
|
|
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 |
|
 |
fjb_saper |
Posted: Wed Jul 30, 2014 2:26 pm Post subject: |
|
|
 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 |
|
 |
Vitor |
Posted: Thu Jul 31, 2014 4:22 am Post subject: |
|
|
 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 |
|
 |
Vitor |
Posted: Thu Jul 31, 2014 4:23 am Post subject: |
|
|
 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 |
|
 |
Vitor |
Posted: Thu Jul 31, 2014 4:27 am Post subject: |
|
|
 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 |
|
 |
kimbert |
Posted: Thu Jul 31, 2014 7:28 am Post subject: |
|
|
 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 |
|
 |
deepeshk79 |
Posted: Thu Jul 31, 2014 8:48 pm Post subject: |
|
|
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 |
|
 |
kimbert |
Posted: Fri Aug 01, 2014 2:01 am Post subject: |
|
|
 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 |
|
 |
deepeshk79 |
Posted: Fri Aug 01, 2014 7:37 am Post subject: |
|
|
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 |
|
 |
|