|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
XMLNSC Parsing Error - flow amending XML to be valid |
« View previous topic :: View next topic » |
Author |
Message
|
matthewmatcham |
Posted: Thu Aug 26, 2010 12:47 am Post subject: XMLNSC Parsing Error - flow amending XML to be valid |
|
|
Novice
Joined: 06 Sep 2006 Posts: 12 Location: UK
|
Broker 6.1.0.2 on Windows.
I'm passing an XML message over MQ to a flow without a final closing tag character '>' to test out some error handling. I've set the Message Domain to XMLNSC on the MQInput node, I've wired my Out terminal to a trace node (which encounters the parsing error by accessing Root), and also wired the Catch terminal to some error handling logic. The offending message and error details get stored away by another flow, and everything looks good (helpful error message, Parsing exception details etc).
The issue I'm seeing is that when I retrieve the details to look at the offending message, I see a valid XML structure. The closing character '>' has mysteriously appeared on the end of the data, which might seem like a nice touch but isn't very helpful here.
In the Debug view - I know, it's not always the most reliable - I can see that immediately after the MQInput node, on the catch wire, I have a seemingly valid XML structure in the variables view, alongside my exception list etc. So that would explain where this mysterious 'XML repair' happened.
I can get around this by blanking out the Message Domain on the MQInput node and adding a ResetContentDescriptor node later in the flow (the error occurs and I get the poison message logged correctly), just wondering if anyone knows why this is happening?
Thanks |
|
Back to top |
|
 |
ccrandall |
Posted: Fri Aug 27, 2010 7:18 am Post subject: |
|
|
Acolyte
Joined: 23 Oct 2008 Posts: 52
|
Sorry, I don't have an answer for you, but that's interesting behavior you are seeing. I'd be curious to see what the answer to this is.
Just one suggestion, though, instead of blanking out the parser on the MQInput, try setting it to BLOB... or maybe that's what you meant. In our app, we usually start with a BLOB and then use an RCD to set it to the appropriate domain later. That helps us in situations like this where a message is malformed and then we might have the ability to recover from that by tweaking the message. |
|
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
|
|
|
|