Author |
Message
|
gags0409 |
Posted: Tue Apr 02, 2019 3:06 am Post subject: xml opening & closing tag issues in IIB |
|
|
Novice
Joined: 25 Mar 2019 Posts: 22
|
Hi Guys, i am facing one issue , when I am passing an xml message with one tag for instance <Name > xxxxx </Name> in one of my IIB service the output is displaying in soap ui <Name> xxxxx </Name> , but when i am sending something like this
<idValue>yyyy</idValue>
<idName>xxxx</idName> the output is as expected working fine .
Input I am sending as
<![CDATA[some stuff]]> via soap ui . So the issue is when I am sending data with one tag. |
|
Back to top |
|
 |
timber |
Posted: Tue Apr 02, 2019 3:32 am Post subject: |
|
|
 Grand Master
Joined: 25 Aug 2015 Posts: 1292
|
You are probably taking the value of the CDATA section (which is just text) and assigning it to OutputRoot.XMLNSC.Name. The text value is actually XML, so it contains < and >. So IIB (correctly) escapes those characters.
If you want to emit a proper XML document then you will need to parse the content of the CDATA section using CREATE...PARSE. The resulting message tree should be assigned as the first child of OutputRoot.XMLNSC.Name. There are many posts on this forum describing how to do that. |
|
Back to top |
|
 |
gags0409 |
Posted: Tue Apr 02, 2019 4:34 am Post subject: |
|
|
Novice
Joined: 25 Mar 2019 Posts: 22
|
Hi Timber,
I am not facing issue while sending
<![CDATA[
<data>
<idValue>yyyy</idValue>
<idName>xxxx</idName>
</data>
]>
only when I am trying to send a single tag its creating issues
<![CDATA[
<data>
<idValue>yyyy</idValue>
</data>
]>
I am trying to save this payload in one variable and pass that as a parameter to an service call , since the payload gets converted into
<data>
<idValue>yyyy</idValue>
</data>
Its creating issues |
|
Back to top |
|
 |
timber |
Posted: Tue Apr 02, 2019 6:47 am Post subject: |
|
|
 Grand Master
Joined: 25 Aug 2015 Posts: 1292
|
Please do the following:
- Add a Trace node after the input node
- Add a Trace node after the output node (connected to its Output terminal)
- Set the Pattern property to ${Root} on both Trace nodes
- Post the output of the Trace nodes for both of the scenarios that you have described (single tag and multipe tags). |
|
Back to top |
|
 |
gags0409 |
Posted: Tue Apr 02, 2019 7:30 am Post subject: |
|
|
Novice
Joined: 25 Mar 2019 Posts: 22
|
Hi,
I tried that in trace I am getting proper xml with <> , but somehow its not working real time . I am not sure why it works when two fields are there but for one it doesn't . |
|
Back to top |
|
 |
rekarm01 |
Posted: Tue Apr 02, 2019 11:37 am Post subject: Re: xml opening & closing tag issues in IIB |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
gags0409 wrote: |
Hi Guys, i am facing one issue , when I am passing an xml message with one tag for instance <Name > xxxxx </Name> in one of my IIB service the output is displaying in soap ui <Name> xxxxx </Name> |
Just to clarify, is the issue that, in some cases, the parser changes how the XML message escapes character data, where the input message escapes character data using a CDATA section, but the output message escapes the same character using entity references instead? And is this causing a problem for some downstream component, outside the message flow?
Code: |
Input:
"<![CDATA[<data><idValue>yyyy</idValue></data>]]>"
Output:
"<data><idValue>yyyy</idValue></data>" |
Also to clarify, this only happens for smaller CDATA sections, (containing one escaped element), but not for larger CDATA sections (containing two or more escaped elements)? In the input message, is there any extra text (including whitespace) before or after the CDATA sections?
timber wrote: |
Post the output of the Trace nodes for both of the scenarios that you have described (single tag and multiple tags). |
When posting the output, it probably isn't necessary to post the message headers too, so "${Root.XMLNSC}" might work better as a Trace node pattern. Also, try to trim the input messages as much as possible, while still reproducing the issue, or else try trimming some of the irrelevant parts from the Trace node output, to make it easier to find the elements containing the CDATA section or escaped text.
gags0409 wrote: |
I tried that in trace I am getting proper xml with <> |
Escaping character data (whether by CDATA section, or by entity references) only occurs in the serialized message, (outside the message flow), not within the parsed message tree.
[Edit: Please, also use [code] tags when posting Trace node output; this makes it easier to read.]
Last edited by rekarm01 on Tue Apr 02, 2019 4:32 pm; edited 1 time in total |
|
Back to top |
|
 |
timber |
Posted: Tue Apr 02, 2019 1:17 pm Post subject: |
|
|
 Grand Master
Joined: 25 Aug 2015 Posts: 1292
|
Quote: |
I tried that in trace I am getting proper xml with <> |
You should not see < and > in the Trace node output. The Trace node shows the structure of the internal messagee tree, so it should contain names and values only.
If you post the trace node outputs for both scenarios then we should be able to assist. Please remove headers etc as suggested by rekarm01. |
|
Back to top |
|
 |
gags0409 |
Posted: Wed Apr 03, 2019 12:58 am Post subject: |
|
|
Novice
Joined: 25 Mar 2019 Posts: 22
|
Also to clarify, this only happens for smaller CDATA sections, (containing one escaped element), but not for larger CDATA sections (containing two or more escaped elements)? In the input message, is there any extra text (including whitespace) before or after the CDATA sections?
Yes for smaller CDATA sections, for example
<![CDATA[
<data>
<idValue>yyyy</idValue>
</data>
]> |
|
Back to top |
|
 |
gags0409 |
Posted: Wed Apr 03, 2019 1:03 am Post subject: |
|
|
Novice
Joined: 25 Mar 2019 Posts: 22
|
trace for both scenarios are :
Smaller CDATA ( which is not working :
(0x03000001:CDataField):Payload = '<data><idValue>yyyy</idValue></data>' (CHARACTER)
CDATA ( which is working :
(0x03000001:CDataField):Payload = '<data><idValue>yyyy</idValue><idValue>yyyy</idValue></data>' (CHARACTER) |
|
Back to top |
|
 |
gags0409 |
Posted: Wed Apr 03, 2019 2:06 am Post subject: |
|
|
Novice
Joined: 25 Mar 2019 Posts: 22
|
CDATA causing ISSUE
(0x01000000:Folder):XMLNSC = ( ['xmlnsc' : 0x2aa51d20]
(0x01000400:XmlDeclaration):XmlDeclaration = (
(0x03000100:Attribute):Version = '1.0' (CHARACTER)
(0x03000100:Attribute):Encoding = 'UTF-8' (CHARACTER)
)
(0x01000000:Folder ):InRequest = (
(0x01000000:Folder):inputRequest = (
(0x03000000:PCDataField):Id = 'ABC123' (CHARACTER)
(0x03000001:CDataField ):Payload = '<table><idValue>XXXXX Health</idValue></table>' (CHARACTER)
)
)
)
CDATA WORKING
(0x01000000:Folder):XMLNSC = ( ['xmlnsc' : 0x2aa51d20]
(0x01000400:XmlDeclaration):XmlDeclaration = (
(0x03000100:Attribute):Version = '1.0' (CHARACTER)
(0x03000100:Attribute):Encoding = 'UTF-8' (CHARACTER)
)
(0x01000000:Folder ):InRequest = (
(0x01000000:Folder):inRequest = (
(0x03000000:PCDataField):Id = 'ABC123' (CHARACTER)
(0x03000001:CDataField ):Payload = '<table><idValue>xxxx </idValue><idValue>xxxx</idValue></table>' (CHARACTER)
)
)
) |
|
Back to top |
|
 |
gags0409 |
Posted: Wed Apr 03, 2019 3:09 am Post subject: |
|
|
Novice
Joined: 25 Mar 2019 Posts: 22
|
JFYI: This is a rest call , I am using SOAP UI and rest Client to invoke the HTTP service |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Apr 03, 2019 5:20 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
If you look at your working request you have folders:
Quote: |
InRequest
inRequest |
On the not working part your folder names are:
Quote: |
InRequest
inputRequest |
Hope it helps  _________________ MQ & Broker admin |
|
Back to top |
|
 |
rekarm01 |
Posted: Wed Apr 03, 2019 4:56 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
Please post all four Trace node excerpts, for both the input and output messages, for both scenarios. If the message flow has any transformations relating to the CDATA section, then post that as well.
And please also use [code] tags when providng the Trace node excerpts or other code, to visually separate it from the rest of the post; this makes it easier to read. |
|
Back to top |
|
 |
|