I have a SOAP webservice for which I consume in a flow service. The output from the connector is a complex document representation of the XML response.
However when I use the documentToJSONString the json tags also have the namespace from the XML output.
How can I eliminate the namespace from the json keys?
Note: A string replacement is not something preferred.
Best Regards,
Franklin
Hi Franklin,
At present, seamless conversion between xml and json is not possible. Therefore, if the document type has the name in the format - prefix:name, the same is assigned as key in JSON.
You may have to modify/cleanup the document names via custom code before you can send it to documentToJSONString service. I know you mentioned this is not preferable, but that is the only way it would work as per your requirements as of now.
Hello @Arpitha_Bhat
Thanks for providing the clarification. I seem to get similar feedback from other folks as well.
What intrigues me is, how is the webMethods API Gateway automatically doing the same conversion without actually showing the namespaces.
I am almost certain they are not using String replacement. Therefore I assume there would be some approach(eventhough it involves code).
Let me know your thoughts.
Best Regards,
Franklin
Hi Franklin,
I checked with the team, they seem to be using custom code to convert XML to JSON using jettison libraries. They also claim that namespace prefixes are not removed…I am not sure of that behavior though.
Thanks,
Arpitha
(The abomination that is XML namespaces continues to deliver challenges 
)
It used to be possible to set namespaces such that the prefix was empty for a given namespace – a default namespace. But since the move from Developer to Designer, Designer forces a prefix, though I have managed to work-around it. Alas, I don’t recall exactly how. 
The ability to do so is definitely present – when you receive an XML doc the sender uses the prefixes they want. They can be anything at all, including nothing. IS XML parsing understands how to translate what the sender sends to the defined prefixes you want/need – including nothing (default namespace).
Although this post does not give the specifics of how because I’ve long forgotten, I thought I’d share that you should be able to do this. The key is defining a document type where the field names do not have prefixes, but are defined with a namespace.
Be aware of the corner cases where XML to JSON has challenges. Single element arrays, attribute naming, complex elements to name a few. All can be addressed but need specific attention/approach
Good luck!
Thank you @Arpitha_Bhat
Is it possible to understand how we can do the same from Integration Server?
Is this implemented as Java Services?
I just validate this and the gateway does remove the namespace.
Below are details of the SOAP service on gateway with namespace hy: and pricePart
As you can see there is a namespace prefix.
The same API when enabled with REST transformation
return the response in JSON and has no namespace prefix
You can ignore the XML attributes which are also seen in the JSON response.
Best Regards,
Franklin
Thanks @reamon
The corner cases are an advanced requirement and I would rather not go there, for now
However I am still intrigued to see that there inst a very straightforward approach for the 80% of the cases of SOAP/XML to REST/JSON transformation.
While going through the forum there are queries from back in 2006 with the exact sample problem. The solution provided mostly are the following
Both options seem to have its pros and cons and many a times people have settled for the second option.
Shouldn’t there be a more cleaner way to do this?
Best Regards,
Franklin
I don’t think this is accurate. I cannot be certain as the screen shot does not show the full namespace declarations. But “pricePart” is either not in a namespace, and would have no prefix, or is in a default namespace, and would have no prefix. “hy” is not the namespace, it is the namespace prefix. I note this to emphasize that there are multiple ways that an element within a namespace can be represented. The lack of a prefix does not mean the namespace is removed.
For the purposes here, it is the namespace prefix that is undesirable. The key here is telling the xmlNodeToDocument service to change the prefix of a given namespace from whatever it is in the document the sender provided to be the prefix you want – which is nothing. The challenge as noted above is how to get the “nothing” defined in Designer – it really wants a var to have a name. I managed to do so some time ago. Here is a screen shot:
The trick is using the “Set a Value” button for the document and then “Add Row” for each namespace. For each namespace, use a literal space for the var name and paste the namespace as the value. Use 1 space for the first namespace, 2 spaces for the next, and so on. This is because they need to be uniquely named.
Here is the example XML I used to demonstrate:
<h:html xmlns:xdc="http://www.xml.com/books" xmlns:h="http://www.w3.org/HTML/1998/html4">
<h:head><h:title>Book Review</h:title></h:head>
<h:body>
<xdc:bookreview>
<xdc:title>XML: A Primer</xdc:title>
<h:table>
<h:tr align="center">
<h:td>Author</h:td><h:td>Price</h:td>
<h:td>Pages</h:td><h:td>Date</h:td></h:tr>
<h:tr align="left">
<h:td><xdc:author>Simon St. Laurent</xdc:author></h:td>
<h:td><xdc:price>31.98</xdc:price></h:td>
<h:td><xdc:pages>352</xdc:pages></h:td>
<h:td><xdc:date>1998/01</xdc:date></h:td>
</h:tr>
</h:table>
</xdc:bookreview>
</h:body>
</h:html>
Downside of this approach is you need to know all the namespaces (not the prefixes) ahead of time. And the funky setting of the nsDecls var. If you’re adventurous you could probably use queryXMLNode to get a list of the namespaces that are present in a given document, then dynamically create the nsDecls var so you wouldn’t need to know the namespaces ahead of time.
HTH.
Dear @reamon
Thanks. This worked exactly as I wanted it to.
Added the empty nsDecls as part of the xmlNodeToDocument call
And output
However I do have a followup situation which if you could assist would be great.
While invoking a soap connector, the XML/SOAP output would be in the form of a document. Therefore I would have to invoke the documentToXMLString and then repeat the steps
Question : Do you foresee any scalability issues with this approach?
Question : Is there a better approach?
Best Regards,
Franklin
It certainly adds a reparse and additional memory usage. Whether or not that would be an issue depends on the size of the documents and how often the service is called.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
