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 » Anyway to avoid parsing error

Post new topic  Reply to topic
 Anyway to avoid parsing error « View previous topic :: View next topic » 
Author Message
KIT_INC
PostPosted: Thu Jul 19, 2018 11:42 am    Post subject: Anyway to avoid parsing error Reply with quote

Knight

Joined: 25 Aug 2006
Posts: 589

We are handling messages from external vendor and were told to accept as much garbage as we can. We have seen messages that looks like
<Msg>
<data1>123</data1>
<data2>I am sending you <garbage> please handle</data2>
</Msg>

The input node has only XMLNSC specified and parsing on demand. The field data2 is not used at all. However I think the xmlnsc parser is looking for a well formed XML. So it failed on parsing error complaining that there is no matching end tag </garbage>. I also tried specifying data2 as opaque with no luck.
One way I can think of is to receive the message as BLOB, drop the data2 element and RCD back to XMLNSC to continue. Is there any better way ? I am on IIB V10.
Back to top
View user's profile Send private message
timber
PostPosted: Thu Jul 19, 2018 1:31 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1280

Quote:
were told to accept as much garbage as we can
Come on, you've been on this forum for long enough to know the answer

The vendor is not sending XML. They are claiming to send XML, but no XML parser in the world would accept it (easy to prove by loading it into a browser).
The pain should be placed where it belongs - on the vendor and their illiterate developers. If your employers cannot or will not fight that war then you'll have to fix up the incoming 'XML' before parsing it using XMLNSC.
Back to top
View user's profile Send private message
mpong
PostPosted: Thu Jul 19, 2018 1:42 pm    Post subject: Reply with quote

Disciple

Joined: 22 Jan 2010
Posts: 164

ask them to wrap the garbage within CDATA on element 2.
Even if you receive as BLOB and try to parse as xmlnsc using RCD, it will still return the same parser error.

Fix the problem at the source
Back to top
View user's profile Send private message
KIT_INC
PostPosted: Fri Jul 20, 2018 4:47 am    Post subject: Reply with quote

Knight

Joined: 25 Aug 2006
Posts: 589

Quote:
Come on, you've been on this forum for long enough to know the answer

Yes, you are right. Sorry for the stupid question. I have already approach their management to fix the source. Just hoping for some miracle. I was told that the output was from their MB. I wonder how they did it without putting it as CDATA and not rejected by the parser at output.
Back to top
View user's profile Send private message
joebuckeye
PostPosted: Fri Jul 20, 2018 6:22 am    Post subject: Reply with quote

Partisan

Joined: 24 Aug 2007
Posts: 364
Location: Columbus, OH

I would create an initial flow called TurnGarbageToXML and put all the ugly BLOB to XML cleanup code in there and then have the real XML flow separate.

This would be an easy way to show management how much crap you have to do to turn their non-XML messages into XML.
Back to top
View user's profile Send private message
timber
PostPosted: Fri Jul 20, 2018 6:28 am    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1280

Quote:
I wonder how they did it without putting it as CDATA and not rejected by the parser at outpu
Not all XML processing engines check their output. And the sender may not even be using an XML processor to produce this 'XML'. They may be building up the output using string operations.

I like joebuckeye's suggestion. That way, when the vendor cleans up their act you can just delete the TurnGarbageIntoXML message flow.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Sun Jul 22, 2018 3:42 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

timber wrote:
Quote:
I wonder how they did it without putting it as CDATA and not rejected by the parser at outpu
Not all XML processing engines check their output. And the sender may not even be using an XML processor to produce this 'XML'. They may be building up the output using string operations.
I like joebuckeye's suggestion. That way, when the vendor cleans up their act you can just delete the TurnGarbageIntoXML message flow.

Agree. The errant < > should be represented as &lt; and &gt; . Push back hard. If they continue to produce invalid XML, refuse to support it. It is a source data issue. Do not give in.
_________________
Glenn
Back to top
View user's profile Send private message
KIT_INC
PostPosted: Tue Jul 24, 2018 4:40 am    Post subject: Reply with quote

Knight

Joined: 25 Aug 2006
Posts: 589

Quote:
Push back hard. If they continue to produce invalid XML, refuse to support it. It is a source data issue. Do not give in


Will do. Thanks for all the useful advises
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Anyway to avoid parsing error
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.