| Author |
Message
|
| mqlover |
 Posted: Mon Feb 24, 2014 10:20 pm Post subject: How to let the non xml chars to pass through XMLNSC domain |
 |
|
Disciple
Joined: 25 Jul 2010
Posts: 176
|
HI,
Kindly help me on the below query:
I have a XML msg coming, but they are sending & in the xml tag, due to which my message is not passing thru as I have selected XMLNSC parser in the MQInput node. Now the application team wants me to change my code in such a way that even if there are some non XML chars or whatever I should just pass the message to MQOutput node, without throwing any exception.
The other application listening on this queue would reject the message.
How do I handle such a issue? Kindly help me out.
Thanks |
|
| Back to top |
|
 |
| Simbu |
| Posted: Mon Feb 24, 2014 10:41 pm Post subject: |
|
|
Master
Joined: 17 Jun 2011
Posts: 289
Location: Tamil Nadu, India
|
| If you are just passing the message to MQOutput then you can receive the message as BLOB and pass as it is. |
|
| Back to top |
|
|
| mqlover |
| Posted: Mon Feb 24, 2014 10:51 pm Post subject: How to let the non xml chars to pass through XMLNSC domain |
|
|
Disciple
Joined: 25 Jul 2010
Posts: 176
|
Sorry, now found out that the issue is not because of & in the XML structure.
I found that the upstream application is sending <?xml version=1..>
in the middle of the XML message and the broker is throwing error as "XML parser having errors".
When I removed this whole tag in the middle of the msg, I am able to see that broker is able to parse the msg.
Now how can broker handle with XMLNSC parser such messages.
I need to use XMLNSC parser as I have to fetch a field in the XML message and I cannot pass the msg as blob.
Hope am clear with my issue, can anybody help me on this?
Thanks |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Feb 24, 2014 11:20 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I'm guessing that the message you are getting is invalid.
Why not pass it through an XML Validator (plenty on the web) and see.
If it fails the validity test kick the message right back at the people who are sending it to you.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqlover |
| Posted: Tue Feb 25, 2014 1:06 am Post subject: How to let the non xml chars to pass through XMLNSC domain |
|
|
Disciple
Joined: 25 Jul 2010
Posts: 176
|
Yes, I validated and the xml is invalid. But still the upstream appliation wants the broker to pass it to the downstream application and let they validate teh xml.
So how could I do this?
Is it feasible to attach the failure terminal in the MQInput node to the MQOutput node?
Like whatever be the message just put in the output queue? |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Feb 25, 2014 1:48 am Post subject: Re: How to let the non xml chars to pass through XMLNSC doma |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
Sending Applications should send valid XML. Valid XML will/can be processed by the XMLNSC parser.
You are doing Systems Integration with Broker, and you even may agree to compensate inefficiencies of partner/attached systems.
Including that the xml declaration occurs in the middle of a file. This happens if you say, hey, we concatenate some xml-documents and wrap it with a root element (to make it valid xml)....
.... you forgot about the xml-declaration, which NOW occurs somewhere (probably multiple times) in (the middle of) the document/file/msg. BUT: It is only allowed to occur at the beginning ONCE.
First thing to do: Check if you can FIX your logic (on the partner/sending) side. They should be sending VALID (well formed) XML!
Unfortunately it can really/acutally happen that... you can't fix it there (e.g. it has been coded some time ago and people left, there is only something (compiled code) in production. You don't have control (you work in an other department of your company)). Then you may want to do INTEGRATION WORK with Broker (it's a tool for the job):
Take it in as a BLOB, probably cast to string... cut out the xml-declarations (with some logic). Then use a reset content descriptor and parse with XMLNSC 
_________________
Just use REFERENCEs
Last edited by mqsiuser on Tue Feb 25, 2014 2:02 am; edited 2 times in total |
|
| Back to top |
|
|
| Gralgrathor |
| Posted: Tue Feb 25, 2014 1:59 am Post subject: |
|
|
Master
Joined: 23 Jul 2009
Posts: 297
|
MRM takes in XML with invalid characters with no problem, as far as I know. You'll still have problems writing to XML though, so you'll need to do something about that content before passing on the message.
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine. |
|
| Back to top |
|
|
| Simbu |
| Posted: Tue Feb 25, 2014 3:39 am Post subject: |
|
|
Master
Joined: 17 Jun 2011
Posts: 289
Location: Tamil Nadu, India
|
I had the same issue before and as a temporary solution, I followed the below. Permanent solution is source app needs to fix it
1. Read as blob
2. surround the field value(has special character) with CDATA( with REPLACE function)
3. Then parse as XMLNSC. |
|
| Back to top |
|
|
| mban |
| Posted: Tue Feb 25, 2014 5:16 am Post subject: |
|
|
Newbie
Joined: 25 Dec 2013
Posts: 3
|
| Just a thought..can't we use opaque parsing for that field |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Feb 25, 2014 1:12 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
The only reasonable thing to do is to fix the sending application. It is broken. No program is likely to accept that XML document, even if you kludge your message flow to ignore its brokenness.
If you try to 'fix' it by parsing as BLOB and adding a CDATA section then you are likely to get it wrong - unless you write most of an XML parser in ESQL.
Galgrathor: As far as I know, MRM-XML does not accept badly-formed XML documents of any kind. What makes you think that it does?
_________________
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 |
|
|
| mban |
| Posted: Tue Feb 25, 2014 8:54 pm Post subject: |
|
|
Newbie
Joined: 25 Dec 2013
Posts: 3
|
I was thinking we can parse with XMLNSC parser and under parser options tab specify/add opaque element.
From the Infocenter:
When opaque parsing is enabled, some parts of the message are never parsed, and XML that is either badly formed or not valid is allowed to pass through the message flow without being detected
Please correct me if my understanding is wrong. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Feb 26, 2014 12:21 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
It is possible that opaque parsing will allow XMLNSC to create a message tree for this document.
I still recommend that the sending application is fixed.
_________________
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 |
|
|
| smdavies99 |
| Posted: Wed Feb 26, 2014 1:06 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Any 'FIX' that you might put into your code to get over the problem might only work in the short term.
What happens is a different XML-Declaration tag is put into the data?
Can you cater for ALL Possible illegal tag combinations?
My advice would be to throw is back to the originators as Kimbert suggests. Until they send you valid XML then stand your ground.
If you are forced into catering for it then make sure you have documented everything to CYA with your manager (and their boss) so that when it fails in production you can say with honesty, 'I told you so'.
Any fix is a pure BODGE and really has no place in a broker flow. That said, sometimes needs must.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Feb 26, 2014 1:18 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| smdavies99 wrote: |
What happens is a different XML-Declaration tag is put into the data?
Can you cater for ALL Possible illegal tag combinations? |
Probably the OP doesn't have 2 choices, but only one (do it himself).
If you properly understand what is going on (e.g. XML-declarations are coming in through the way I described) and you have a very good understanding of XML-Standards (you should have as a Broker-Developer), then you are probably fine coding in the flow.
It may even be fine to fix your flow (again) later, if problems get detected during testing (öhmmm... pro ... proddd... probably )
| smdavies99 wrote: |
| That said, sometimes needs must. |
Better than having/doing nothing... it all depends on the project.
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
|
|
