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 IndexWebSphere Message Broker SupportCDATA Parsing Issue

Post new topicReply to topic
CDATA Parsing Issue View previous topic :: View next topic
Author Message
Orette
PostPosted: Wed Sep 05, 2018 10:50 am Post subject: CDATA Parsing Issue Reply with quote

Newbie

Joined: 22 Mar 2017
Posts: 4

I searched through the forums but could not find a situation that quite paralleled mine.

I have a CDATA response that I am PARSEing using DOMAIN 'XMLNSC'.

Code:
SET OutputRoot.SOAP.Body.Blah.cDataRepsonse = InputRoot.SOAP.Body.*Blah.*:BlahBlah; -- Copying CDATA from InputRoot to OutputRoot

CREATE LASTCHILD OF OutputRoot.SOAP.Body.Blah.cDataRemovedRepsonse DOMAIN 'XMLNSC' PARSE (OutputRoot.SOAP.Body.Blah.cDataRepsonse, 546, 1208);


My hope was that I would receive a response that was the CDATA response but instead simply without CDATA wrapped around the response, which I received for the most part. However, the response before removing the CDATA looked like something along these lines:

Code:
<![CDATA[<Collection name="NAME" type="type">
   <SubCollection name="NAME" type="type2">
      <Column name="NAME_ONE">A_Value</Column>
      <Column name="NAME_TWO"></Column>
      <Column name="NAME_THREE"></Column>
      <Column name="NAME_FOUR">Another_Value</Column>
   </SubCollection>
</Collection>]]>


but while debugging in IIB, I noticed that after I PARSE, I receive something like this:

Code:
<Collection name="NAME" type="type">
   <SubCollection name="NAME" type="type2">
      <Column>A_Value</Column>
      <Column name="NAME_TWO"></Column>
      <Column name="NAME_THREE"></Column>
      <Column>Another_Value</Column>
   </SubCollection>
</Collection>


The name attributes persist only for Columns with empty values. However, for Collection and SubCollection, the name attributes persist, and those two complex elements are certainly not empty. Something strange is going on in using PARSE but I am unsure of what that may be. Has anyone ever seen behavior like this before?
Back to top
View user's profile Send private message
timber
PostPosted: Thu Sep 06, 2018 1:51 am Post subject: Reply with quote

Sentinel

Joined: 25 Aug 2015
Posts: 856

Good problem description.

I don't know exactly what the problem is, but I am quite certain that the XMLNSC parser is not throwing away attributes that exist in its input data. My best guess is that the XMLNSC parser is never receiving those attributes.

Sounds as if you are currently using the debugger for all fault diagnosis. Nothing wrong with the debugger for everyday stuff, but it doesn't give enough detail for this scenario. I recommend that you take a debug-level user trace - it will list the input that was passed to the XMLNSC parser.

btw...you don't need to copy the CDATA section into OutputRoot before you parse it. Why not specify the InputRoot field as the input for the CREATE...PARSE statement?
Back to top
View user's profile Send private message
Orette
PostPosted: Tue Sep 18, 2018 9:20 am Post subject: Reply with quote

Newbie

Joined: 22 Mar 2017
Posts: 4

Turns out that in OutputRoot, it was indeed PARSEing correctly and it just wasn't showing it as I expected it would in the debugger. The problem was that I placed the contents of the OutputRoot in the Environment, and that step was the problematic one. I referenced my Environment copy of the OutputRoot xml when trying to access the fields with their name attributes, and that logic was not working, which led me to believe the PARSEing was the source of the problem.

However, it appears that if you do not inform the Environment of the DOMAIN in which you are PARSEing, it will default to assigning all values as CHARACTERs and remove attributes. I was unaware of this.

To remedy this, I simply PARSEd with DOMAIN XMLNSC directly into the Environment, and now I can reference the Environment copy of the data and they retain their name attributes.
Back to top
View user's profile Send private message
timber
PostPosted: Tue Sep 18, 2018 11:04 am Post subject: Reply with quote

Sentinel

Joined: 25 Aug 2015
Posts: 856

Quote:
it appears that if you do not inform the Environment of the DOMAIN in which you are PARSEing, it will default to assigning all values as CHARACTERs and remove attributes. I was unaware of this.
Most people are unaware of this, but unfortunately it's been a feature of the product since forever and it's far too late to change it now.

The rule is: before copying any message tree into the Environment or LocalEnvironment, make sure that you create the parent node using the DOMAIN clause. Otherwise you will get an 'unlike parser' copy which (helpfully and deliberately) zilches all of the parser-specific field types in case you didn't want them. Unfortunately, that's helpful in about 1% of cases and a trip hazard in the other 99%
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexWebSphere Message Broker SupportCDATA Parsing Issue
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.