| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Can I recover from a parser exception ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| WBI_user |
 Posted: Fri Mar 28, 2008 6:09 am Post subject: Can I recover from a parser exception ? |
 |
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
I am running WMB 6 with CSD 5 on AIX.
I have to store the content of a XML message from several external clients. I have no control on the content of each XML tag. I can only treat the message as a well form XML message and use the XMLNS or XMLNSC parser. This gives the external clients the flexibility of adding or changing XML tags that my flow does not care.
My flow is just a MQINPUT -- DB
My ESQL is just
INSERT INTO Database.MSG(COL1, COL2......COLN) VALUES (Root.XMLNS.MSG.FIELD1,........Root.XMLNS.MSG.FIELDN);
One or two of the many XML fields soemtimes contain data that the XML parser does not like and caused a parser exception.
The fileds that caused the exception is not important and we can skip the insert. I am looking for suggestion on how I can handle this.
I think I can
1. Once the parser exception occurs, capture the message on the failure terminal and try to determine which field is causing the problem (I am not sure if the exceptionlist can narrow it down), remove the field and do the insert again.
2. If I can check the fields that I don't care to see if it contains data that XML parser does not like and replace the value with for example "invalid data" before the insert. But I don't know if how I can check individual field and what the XML parser does not like.
Any suggestion ? |
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Fri Mar 28, 2008 7:08 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
If you got a parser exception, then the XML was not well formed.
Or are you saying you get an error on accessing a field that is not there? In that case, check to make sure the field is there and do whatever it is that you do.
Capture one of the messages that fails the parse and look for invalid characters for XML. I'm guessing this is your issue.
This might be a case of GIGO. |
|
| Back to top |
|
|
| WBI_user |
| Posted: Fri Mar 28, 2008 7:36 am Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
I probably used the term "Well formed" in the wrong place. What I like to point out is I can not (prefer not to ) have a message definition to do validation. Even if I can, I will probably just get parser exception in the Input node.
All the fileds I need exist in the XML message. Just the content is no good.
For example I got parser exception on "Invalid character (Unicode: 0x2)".
Message are from external clients and I have no idea how the invalid character gets there. I can only report this back to the client. we do not care about that particular field very much, so we prefer to have the flow completed using option 2 mentioned in my original post by replacing the invald data with "Invalid data" in the column. We still can report the problem base on what is in the column in the DB. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 28, 2008 7:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WBI_user wrote: |
Just the content is no good.
For example I got parser exception on "Invalid character (Unicode: 0x2)".
|
Characters outside the accepted range need to be in a CDATA section, or escaped (e.g. &). No XML parser will produce a tree with that kind of content; it's not a question of validation. There's a clear and documented different between valid XML & well-formed XML - yours is attempting to be the latter and failing. An XML message with that kind of content is as badly formed as one where a closing tag is missing (from a parser's point of view).
Given that, to implement your option 2 you'll need to walk the message manually for the field in question and replace it as parsing will be impossible. That's a lot of work and IMHO you should push these messages back to your clients as they're not XML and hence unprocessable.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Mar 28, 2008 8:54 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
You know, a long time ago in a galaxy far far away...
I was a co-op at a plant that made optical quality plastics and this engineer was explaining to me that the quality of the materials going into the process determined the quality of the product coming out of the process.
Perhaps that is just a contact admin tautology. |
|
| 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
|
|
|
|
