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 » Different MQInput[Failure] processing in MB 6.1 & 7.0FP3

Post new topic  Reply to topic
 Different MQInput[Failure] processing in MB 6.1 & 7.0FP3 « View previous topic :: View next topic » 
Author Message
prasadpav
PostPosted: Thu Feb 16, 2012 9:07 am    Post subject: Different MQInput[Failure] processing in MB 6.1 & 7.0FP3 Reply with quote

Centurion

Joined: 03 Oct 2004
Posts: 142

Hi,
I'm trying to test a message validation scenario, where all message validations from MQInput node (Input message is an XML message) are converted to an error message (XML) and a copy of the input message is also embedded within the error message in a CDATA section. In order to capture the input message after MQInput[Failure], i've the following node wiring:

Code:
  MQInput [Failure terminal] --> RestContentDescritor [To Blob] --> "passthru_node"


MQInput properties, I've set the domain as "XMLNSC, Corresponding message set name" and the validation options are set to Immediate and all other validation options are also set.

The above piece of code works fine in "AIX" with MB 6.1 i.e. I can see the input message converted to BLOB after "Reset content descriptor" node. However, when I test the same in MB 7.0.0.3, I get the following error at "ResetContentDescriptor":

Code:

Text:CHARACTER:A schema validation error has occurred while validating the message tree
                           Insert
                                 Type:INTEGER:2
                                 Text:CHARACTER:5011
                           Insert
                                 Type:INTEGER:2
                                 Text:CHARACTER:2
                           Insert
                                 Type:INTEGER:2
                                 Text:CHARACTER:1
                           Insert
                                 Type:INTEGER:2
                                 Text:CHARACTER:856
                           Insert
                                 Type:INTEGER:5
                                 Text:CHARACTER:Unexpected end element event. The content of element "cs:Body" is not complete.
                           Insert
                                 Type:INTEGER:5
                                 Text:CHARACTER:/Root/XMLNSC


I think it is a product issue. But just want to double check with you guys before raising a PMR. Also, please note that the above code should work when the domain in "ResetContentDescriptor" is reset to "XMLNSC" without any message set because in this case the input XML must be treated as a free-form XML.

Thanks for going through this.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Thu Feb 16, 2012 9:39 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

CDATA does not protect against all forms of bad XML content.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Feb 16, 2012 9:49 am    Post subject: Re: Different MQInput[Failure] processing in MB 6.1 & 7. Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

prasadpav wrote:
I think it is a product issue.


AFAIK the XMLNSC parser was tightened up between v6.1 & v7 (paging Mr. Kimbert!) so some things you might have been able to fluke in v6.1 don't work in v7.

Given that if the input message was valid it wouldn't be going down this line I suspect it won't fit in a CDATA section & probably shouldn't have in v6.1.

Put the original message in the XML as base64 & walk away.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
prasadpav
PostPosted: Thu Feb 16, 2012 9:50 am    Post subject: Reply with quote

Centurion

Joined: 03 Oct 2004
Posts: 142

Quote:
CDATA does not protect against all forms of bad XML content


Wouldn't that be the case when the XML itself is a malformed XML? As long as the input document is a well-formed XML document, CDATA should protect from all XML content. That is the reason why I try to convert to "XMLNSC" (without message set definition) to make sure the XML document is a well-formed XML.
Back to top
View user's profile Send private message
prasadpav
PostPosted: Thu Feb 16, 2012 9:54 am    Post subject: Reply with quote

Centurion

Joined: 03 Oct 2004
Posts: 142

Quote:
Given that if the input message was valid it wouldn't be going down this line I suspect it won't fit in a CDATA section & probably shouldn't have in v6.1.


The input message is a well-formed XML document which may not adhere to XML schema definition, hence, I don't see a reason why I cannot re-parse the input message as BLOB or as a free-form XML using just XMLNSC?

Quote:
Put the original message in the XML as base64 & walk away.


Even if I want to put the original message in a different XML as Base64 encoded message, I first need to convert it to BLOB,which I'm unable to do because of the error that I reported in my first post.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Feb 16, 2012 11:03 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

prasadpav wrote:
Even if I want to put the original message in a different XML as Base64 encoded message, I first need to convert it to BLOB,which I'm unable to do because of the error that I reported in my first post.



You can put anything as a BLOB, not just well formed XML.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
adubya
PostPosted: Thu Feb 16, 2012 11:22 am    Post subject: Reply with quote

Partisan

Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK

prasadpav wrote:
CDATA should protect from all XML content.


Not completely true, there are restrictions as to what can be stored as CDATA. For example CDATA cannot be nested and also the character sequence which terminates a CDATA element ]]> can't be part of a CDATA section.

So if your XML being stored within CDATA contains a CDATA element itself then you're in for trouble
Back to top
View user's profile Send private message Send e-mail
prasadpav
PostPosted: Thu Feb 16, 2012 11:38 am    Post subject: Reply with quote

Centurion

Joined: 03 Oct 2004
Posts: 142

Quote:
Not completely true, there are restrictions as to what can be stored as CDATA. For example CDATA cannot be nested and also the character sequence which terminates a CDATA element ]]> can't be part of a CDATA section.


Agreed. However, we took care of nested CDATA sections to split them into individual CDATA sections. At the moment, I'm storing data as Base64 encoded format only when all other options fail. But I'll however consider storing everything as Base64 encoded based on all your feedback.

Quote:
You can put anything as a BLOB, not just well formed XML.

I know that!! But my problem is, I cannot get the input message as a BLOB when the message validation failed at the input node.

Any comments on the actual problem that is reported .
I thank you all for all the responses I received so far.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Feb 16, 2012 11:42 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

prasadpav wrote:
Quote:
You can put anything as a BLOB, not just well formed XML.

I know that!! But my problem is, I cannot get the input message as a BLOB when the message validation failed at the input node.

Any comments on the actual problem that is reported .


Yes you can. Just not with an RCD that honours the original validation settings. Some ESQL would seem to be the way forward.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
smdavies99
PostPosted: Thu Feb 16, 2012 11:48 am    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

prasadpav wrote:
But my problem is, I cannot get the input message as a BLOB when the message validation failed at the input node.


Have you considered setting the MQInput Node to read the message as a BLOB? Then save it unparsed (ie in the BLOB format that it is already in) and then parse it?

I've had to do that in one case where the input feed was particularly error prone.
_________________
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
View user's profile Send private message
prasadpav
PostPosted: Thu Feb 16, 2012 11:57 am    Post subject: Reply with quote

Centurion

Joined: 03 Oct 2004
Posts: 142

Quote:
Have you considered setting the MQInput Node to read the message as a BLOB? Then save it unparsed (ie in the BLOB format that it is already in) and then parse it?

Yes, that is my work-around solution at the moment.
Back to top
View user's profile Send private message
kimbert
PostPosted: Thu Feb 16, 2012 2:08 pm    Post subject: Reply with quote

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

The comments about the CDATA section are all correct, and are important background. However, the error message clearly says that it is a 'validation error' which means that the XML is well-formed but does not conform with the xsds in the message set.
It sounds as if the RCD node has Validation set to 'None' - if so then I can understand why prasadpav was surprised to get a validation error.
Back to top
View user's profile Send private message
prasadpav
PostPosted: Thu Feb 16, 2012 2:37 pm    Post subject: Reply with quote

Centurion

Joined: 03 Oct 2004
Posts: 142

Thanks Kimbert. The validation option on the RCD node is indeed left as "None" which is the default value.

I tested the same scenario on v7.0 FP2 and it worked perfectly fine as expected i.e. I can use RCD to reset domains to BLOB & XMLNSC (no message set). Hence, FP3 introduced some bug because of which I'm experiencing this. I'll run few more final tests tomorrow and will raise a PMR or downgrade the fix pack to FP2.
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 » Different MQInput[Failure] processing in MB 6.1 & 7.0FP3
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.