webMethods

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.

image1007×647 33.8 KB

However when I use the documentToJSONString the json tags also have the namespace from the XML output.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/399384aea48ca99fd0b63a968d2568a9c3087a6d_2_775x489.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/399384aea48ca99fd0b63a968d2568a9c3087a6d.png 2x" data-dominant-color="F4F5F7">

image972×613 29.6 KB

How can I eliminate the namespace from the json keys?

image1024×472 13 KB

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!

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

• 1)Define another document without namespace and map the elements again.
• 2)Use string replacement

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

image850×683 28 KB

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.

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

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/e456a5b325a7d516f73a7a320a0fedaf4cc335a4_2_1035x183.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/e456a5b325a7d516f73a7a320a0fedaf4cc335a4.png 2x" data-dominant-color="EEEDF5">

image1341×238 21.9 KB

As you can see there is a namespace prefix.
The same API when enabled with REST transformation

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/4e4383612282cb37479297a9f2b59432cbc0ed75.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/4e4383612282cb37479297a9f2b59432cbc0ed75.png 2x" data-dominant-color="F4F2F1">

image819×525 30 KB

return the response in JSON and has no namespace prefix

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/d64428126eb452c0682ba0d56419d6efcb5e00d4.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/d64428126eb452c0682ba0d56419d6efcb5e00d4.png 2x" data-dominant-color="FAF8F8">

image653×607 25.6 KB

You can ignore the XML attributes which are also seen in the JSON response.

Best Regards,
Franklin