| Author |
Message
|
| duffMan |
 Posted: Tue Sep 30, 2008 1:12 pm Post subject: tranforming xml string to xml |
 |
|
Voyager
Joined: 03 Jun 2002
Posts: 75
|
I have this odd requirement. My "customer" will be sending a data string with an element that contains another XML document. This customer is not using CDATA, MIME, nor is encoding the XML. They are simply escaping the XML tags.
i.e.
<myXMLString><?xml version="1.0"?><RootTag>Element1>value</Element1></RootTag></myXMLString>
Aside from telling the customer to send it properly (they already send the same data stream to other parties), how would one go about reparsing this with Message Broker?
Essentially I want to end up with:
<RootTag>
<Element1>value</Element1>
</RootTag>
I've played around a bit with CREATE xxxx statements, ASBITSTREAM statement without success.
Any suggestions would be appreciated. |
|
| Back to top |
|
 |
| kimbert |
| Posted: Tue Sep 30, 2008 2:03 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
The character entities will automatically be decoded by the XML parser, so the string in the message tree will be the string that you want, but in UTF16 ( like all other character data in the broker's message tree ) .
Then all you have to do is a CREATE with PARSE to produce the XMLNSC tree that you are aiming for. Don't forget to specify the code page - it will be UTF16, which is 1200. |
|
| Back to top |
|
|
| duffMan |
| Posted: Tue Sep 30, 2008 2:13 pm Post subject: |
|
|
Voyager
Joined: 03 Jun 2002
Posts: 75
|
Thanks. I first had to cast my "xmlString" into a BLOB and then proceed as suggested.
DECLARE xmlString CHARACTER InputRoot.XMLNSC.myXMLString;
DECLARE xmlBLOB BLOB CAST(xmlString AS BLOB CCSID InputProperties.CodedCharSetId );
CREATE LASTCHILD OF OutputRoot DOMAIN('XMLNSC') PARSE(xmlBLOB);
The message tree now has what used to be an "escaped" XML string all nicely layed out and ready to be referenced as good 'ol XML.
.. using the XMLNSC parser of course for those who are sensitive to such things. |
|
| Back to top |
|
|
| duffMan |
| Posted: Tue Sep 30, 2008 7:07 pm Post subject: |
|
|
Voyager
Joined: 03 Jun 2002
Posts: 75
|
Well it seems this only half works....
in my test scenario I was injecting XML with the escape characters into an MQInput node with XMLNSC as the parser. A trace node immediatly after the MQInput reveals that the parser already converted the < and > to < and > respectively, although the 'XML' document was still a single value of the myXMLString element.
I made the false assumption that the HTTPInput node would work the same. A trace node immediately following this node with XMLNSC as the parser reveals that it DOES NOT convert the escape chars as noted above with the MQINPUT.
So... by the time I do my CAST and reparse the the < and > are still in the bit stream and the DOMAIN('XMLNCS') PARSE(xmlBLOB) complains about the bit stream not being well formed XML.
At first I thought my test tool (IH03) may have been converting the &'s but it is not. There appears to be a difference in the parser for MQInput and HTTPInput..... unless I'm missing something here.
So I guess I'm still stuck for now. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Tue Sep 30, 2008 8:07 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| duffMan wrote: |
in my test scenario I was injecting XML with the escape characters into an MQInput node with XMLNSC as the parser. ...
I made the false assumption that the HTTPInput node would work the same. |
Are you sure your MQInput node and HTTPInput node are using the same parser? Compare 'Properties->Input Message Parsing' and 'Parser Options' properties.
| duffMan wrote: |
| So... by the time I do my CAST and reparse the the < and > are still in the bit stream and the DOMAIN('XMLNCS') PARSE(xmlBLOB) ... |
Shouldn't that be "DOMAIN('XMLNSC') ..."?
cheers, |
|
| Back to top |
|
|
| duffMan |
| Posted: Tue Sep 30, 2008 8:35 pm Post subject: |
|
|
Voyager
Joined: 03 Jun 2002
Posts: 75
|
I think I know what is going on 
Of course testing this is not easy because my test case is basically an embedded xml doc inside an xml tag, with all the escape characters and all.
For the MQ request I'm using ih03 which appears to be PUTTING the message as is.
However, for the HTTP test I'm using the Web Services Explorer test harness in the Toolkit. When I paste my string value of:
<?xml version="1.0"?><RootTag>Element1>value</Element1></RootTag>
into the text box representing the soap:body root element the test harness is actually escaping the escape characters with:
&lt;?xml .... and so on...
So, when the broker parses this is resolves
&lt; -------> <
but doesn't do < --------> '<'
at least not in one shot. I'll bet if it PARSE it twice I'll get what I want.
But of course this is not what will happen in production as this is a result of my test tool of choice. So I think I'll build my own test harness as a flow rather than use the Toolkit Web Service tester...at least in this instance.
I'll post my result of the double parse as well as my own flow as a test web services client.....
hopefully this may prove usefull for someone, but gawd help us if parsing escaped xml embedded as a sting inside a real xml tag is common. |
|
| Back to top |
|
|
|
|
