| Author |
Message
|
| sleepyjamie |
 Posted: Mon Aug 10, 2015 11:25 am Post subject: CDataSection to XML |
 |
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
I've found some examples and IBM documentation on how to attach XML to an element's CDataSection. I am trying to do the opposite, read the CData and insert it into the root's XML.
I have a soap response that contains XML inside a CData which I want to convert to XML and pass it to the OutputRoot. Here is my code, however it isn't working (hence my post):
SET OutputRoot.XML = InputRoot.SOAP.Body.v1:retrieveEventResponse.(XML.CDataSection)EventMessage; |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Aug 10, 2015 11:39 am Post subject: Re: CDataSection to XML |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
Here is my code, however it isn't working (hence my post):
SET OutputRoot.XML = InputRoot.SOAP.Body.v1:retrieveEventResponse.(XML.CDataSection)EventMessage; |
Problems with this code include (but are not limited to):
- You're using the XML domain which is depreciated. Use OutputRoot.XMLNSC
- The SOAP domain uses the XMLNSC parser under the covers (because the XML domain is depreciated) so the constant XML.CDataSection isn't describing the CData section in the InputRoot
- If it was, you'd be trying to assign a string to an XML object within the XML (or XMLNSC) domain. This won't work as the string needs to be parsed first.
If you'd shown some effort in describing how you'd come up with this code, or what you'd tried to resolve it, I'd be more inclined to offer hints. As you came in with "it isn't working" with no supporting comments, I'm not.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Mon Aug 10, 2015 11:43 am Post subject: Re: CDataSection to XML |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
Here is a work around I developed.
DECLARE EventMessage REFERENCE TO InputRoot.SOAP.Body.v1:retrieveEventResponse.EventMessage;
DECLARE xml CHARACTER;
-- Remove the CData
SET xml = SUBSTRING(EventMessage from 10 for LENGTH(EventMessage) - 12);
CREATE LASTCHILD OF Environment.MyData DOMAIN('XMLNSC') PARSE(xml, InputProperties.Encoding, InputProperties.CodedCharSetId);
It's not an ideal solution. I would prefer to extract the text from the CData and parse to XMLNSC, without having to do a Substring. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 10, 2015 11:47 am Post subject: Re: CDataSection to XML |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| sleepyjamie wrote: |
| It's not an ideal solution. I would prefer to extract the text from the CData and parse to XMLNSC, without having to do a Substring. |
Yes?
So why don't you just get the value of the CDATA section? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 10, 2015 11:50 am Post subject: Re: CDataSection to XML |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
| Code: |
| CREATE LASTCHILD OF Environment.MyData DOMAIN('XMLNSC') PARSE(xml, InputProperties.Encoding, InputProperties.CodedCharSetId); |
It's not an ideal solution.
|
You got that right. Why are you now suddenly putting this in the Environment tree when you want it in OutputRoot? At least you figured out the PARSE.
| sleepyjamie wrote: |
I would prefer to extract the text from the CData and parse to XMLNSC, without having to do a Substring. |
See my comment above on how XML.CDataSection doesn't work with the XMLNSC domain.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Mon Aug 10, 2015 11:55 am Post subject: Re: CDataSection to XML |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| mqjeff wrote: |
| sleepyjamie wrote: |
| It's not an ideal solution. I would prefer to extract the text from the CData and parse to XMLNSC, without having to do a Substring. |
Yes?
So why don't you just get the value of the CDATA section? |
That is what I am trying to do, hence my original question with sample code.
-- This doesnt work
DECLARE g CHARACTER;
SET g = InputRoot.SOAP.Body.v1:retrieveEventResponse.(XML.CDataSection)EventMessage;
-- This doesnt deploy
DECLARE g CHARACTER;
SET g = InputRoot.SOAP.Body.v1:retrieveEventResponse.(XMLNSC.CDataSection)EventMessage; |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 10, 2015 11:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Can you show the XML that includes the CDATA section?
What does it complain about when it doesn't deploy? |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Mon Aug 10, 2015 11:57 am Post subject: Re: CDataSection to XML |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| Vitor wrote: |
| sleepyjamie wrote: |
| Code: |
| CREATE LASTCHILD OF Environment.MyData DOMAIN('XMLNSC') PARSE(xml, InputProperties.Encoding, InputProperties.CodedCharSetId); |
It's not an ideal solution.
|
You got that right. Why are you now suddenly putting this in the Environment tree when you want it in OutputRoot? At least you figured out the PARSE.
| sleepyjamie wrote: |
I would prefer to extract the text from the CData and parse to XMLNSC, without having to do a Substring. |
See my comment above on how XML.CDataSection doesn't work with the XMLNSC domain. |
I put it in an Environment tree because the Output Root will be a child within the parsed XML. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 10, 2015 12:18 pm Post subject: Re: CDataSection to XML |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
| I put it in an Environment tree because the Output Root will be a child within the parsed XML. |
That doesn't make sense. Either what you've written, or what I'm reading, makes no sense.
The OutputRoot won't be a child of anything. It can't be.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 10, 2015 12:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| What does it complain about when it doesn't deploy? |
It complains that XMLNSC.CDataSection isn't a valid field type.
The field type isn't called that 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Mon Aug 10, 2015 12:32 pm Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
Yeah I tried XMLNSC.Value and XMLNSC.CDataValue both returned null.
Here is what is showing in the debugger underneath my retrieveEventResponse element.
retrieveEventResponse
EventSubscriber:CHARACTER:ESBTEST
EventTopic:CHARACTER:MCP
EventType:CHARACTER:OFF
EventMessage:CHARACTER:<![CDATA[<Test name="Test" version="6.2" xmlns="http://wbe.ibm.com/6.2/Event/Test" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
</Test>]]> |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 11, 2015 5:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
| Here is what is showing in the debugger underneath my retrieveEventResponse element. |
The reason you'll find multiple threads in here recommending the use of user trace over the debugger (especially for parsing problems like this) is:
a) what you see in the debugger is the visual representation of what the debugger thinks the message tree looks like. Because it's been parsed and converted for display, it's not what's in the runtime
b) the debugger (at best) shows you what the tree looks like. The user trace shows the logic being executed by the runtime in response to your ESQL. This is the difference between working out why a car crashed from a photo of a car wrapped round a tree, and a video of the car heading towards the tree.
Take a user trace, ideally with a Trace node to display the full message tree before the Compute, and see what that tells you.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Tue Aug 11, 2015 6:29 am Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| Vitor wrote: |
| sleepyjamie wrote: |
| Here is what is showing in the debugger underneath my retrieveEventResponse element. |
The reason you'll find multiple threads in here recommending the use of user trace over the debugger (especially for parsing problems like this) is:
a) what you see in the debugger is the visual representation of what the debugger thinks the message tree looks like. Because it's been parsed and converted for display, it's not what's in the runtime
b) the debugger (at best) shows you what the tree looks like. The user trace shows the logic being executed by the runtime in response to your ESQL. This is the difference between working out why a car crashed from a photo of a car wrapped round a tree, and a video of the car heading towards the tree.
Take a user trace, ideally with a Trace node to display the full message tree before the Compute, and see what that tells you. |
Agreed. I do use trace nodes for capturing errors/exceptions, however for generic tracing between nodes I try to avoid them because they often make a mess of the flow. It would be nice if IIB had a way to enable tracing at the input and output of a node without having to physically drop a trace node onto the palette. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 11, 2015 6:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You said you stuffed it into the Environment Tree. If you did not set up a parser to that part of the Environment Tree there is no guarantee to what happened to your CDataValue section. That section only makes sense with an XMLNSC parser. The Environment Tree on the other hand is known to have no parser by default... So no saying what happens to such a section when moved to the Environment Tree without the benefit of an XMLNSC parser...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Tue Aug 11, 2015 6:54 am Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
I just realized in my SOAPUI that the response is returning a CData nested inside another CData, which contains a sibling CData. So I have a feeling this is also causing issues in IIB.
 |
|
| Back to top |
|
|
|
|
