Product/components used and version/fix level are you on:

API GATEWAY & IS 10.5

Detailed explanation of the problem:

I have a SOAP service publised in API GATEWAY. It works well. Ive enabled REST transformation feature in API Gateway in order to get JSON REST requests. But when I receive the información on IS, the request look like this:

As you see, some variables have the “axis2ns355” prefix. Actually those variable are the “Optional” and “Null” variables on the request document:

I cant change all the request variables to required. How can I solve this by API Gateway side?

I receive the pipeline well when I send it by SOAP request. If I try to send it across the REST API enabled by REST transporfation the request comes with that prefix. Thats the problem.

#API-Management
#Integration-Server-and-ESB
#API-Gateway
#webMethods

This is one of the challenges with generically translating SOAP/XML and JSON. The XML namespaces and associate prefixes are not something that can be generically dealt with. A default namespace adds even more interest to the mix.

Is there a specific need to have the API GW pass JSON to IS in this case? Why not just receive the original XML (is this actually SOAP or is it plain XML – cannot tell for sure from the screen shot)?

One of the things that might cause an issue is when translating from XML to JSON, there is no way to know for sure if an XML element is supposed to be in an array or not. A single-item list in XML is indistinguishable from a stand-alone element. In this case, the translation will be wrong because the generic translation will not know to place the single item into a list.

If you really need to translate XML to JSON, I would suggest doing so within IS with the help of doc types and XSD. The generic translation in API GW has limitations due to ambiguities of XML.

#API-Gateway
#API-Management
#Integration-Server-and-ESB
#webMethods

I agree to Reamon mostly. You should never convert XML to JSON or JSON to XML unless you don’t have any other option. There is a way to know if an XML element is single element or an array (minOccurs and maxOccurs attributes in the XSD, without an XSD it is impossible) but it usually messes everything up and this is not the only problem, there is no standard on defining null’s in XML. It can be </tag> or it can be nill attribute or it can be empty string; either way it will never be an actual null in the document. Sometimes it will fail to map null to empty field, sometimes you will have a @nill in the attributes, or sometimes you will have an empty string.

XML - Json conversions will cause more harm then the minimal good you are aiming for and there is nothing you can gain from this conversion.

#API-Gateway
#Integration-Server-and-ESB
#webMethods
#API-Management

I would refine this to say “don’t try to generically convert XML/JSON.” Conversion is fine if you apply the usual “hints” for properly parsing XML, such as doc type, XSD or the arrays/makeArrays input to xmlNodeToDocument. One of the big lies of XML is that it is “self-describing.” In many ways, it is. But in multiple important ways it is decidedly not.

Although XML has no explicit definition of null, there is a widely accepted and defined way. xsi:nil is used to indicate a valid element with no content even if that elements content type normally doesn’t allow empty elements. An empty tag is not null – it is an empty value, which is different from null. In some languages/environments, empty is equivalent to null but that assumption is not a safe one in XML.

If one is using wM IS for brokering the interaction between 2 applications, there certainly is good case for it. Accept XML from a caller, convert that to JSON to call the provider, then reverse it on the way back. This indeed is one of the core aspects of using an integration tool.

But I think we agree – generic translation between XML/JSON might work for rather simple data documents. But anything with even a little bit more than just a flat set of fields will quickly fail in some scenarios. Proceed with extreme caution. And in any case, I strongly recommend NOT using the XML/JSON transformation feature of API GW. It will very likely bite you at some point.

#API-Gateway
#API-Management
#webMethods
#Integration-Server-and-ESB

Yes, I meant generic conversions. It is OK to convert them to document and then map them properly and then export as json or xml string as long as you have the correct document type.

#webMethods
#API-Management
#API-Gateway
#Integration-Server-and-ESB

What I looking for is the client can consume my API like a REST API. I have a Flow Service as a operation in WS. This WS is published in API Gateway and the client is currently consuming the API Gateway SOAP method. Now, the client can NOT consume as a SOAP service. He needs consume my API as a JSON REST API. So, Ive used the rest transformation API GATEWAY feature to do that but the request in IS arrives like the previous images that you saw in this thread.

Client consume REST API by rest transformer API GATEWAY feature in order to send a json message, in IS arrives as a document type but with the underisable prefixes.
In the other hand, why am not I using the REST RESOURCE and REST API DESCRIPTOR feature on IS and then publish them on API Gateway? That’s because and error when Im creating the RES API DESCRIPTOR, I dont know the reason but when I create a REST API DESCRIPTOR then it get corrupt

The REST API Descriptor doesnt even open correctly and a error message “Descriptor nameofdescriptor not exists”. Thats the reason why Im not using and API Descriptior

#API-Gateway
#API-Management
#webMethods
#Integration-Server-and-ESB

I would venture to say that you should avoid the generic “REST Transformation” feature. Even though snippet of the document shared does not show a list, I would venture to guess that there is indeed one or more them present. This will cause issues because XML must have help to know when a single element is an entry of a list.

I might also suggest that you might consider the so-called “legacy” REST approach to do what you want. We avoid RAD (and WSDs) because they tend to be in the way more than they help, for the most part. I’m not suggesting never use them, just use them judiciously. They tend to want to enforce every little thing about an API. Which can be good but when using wM IS for the usual “mediator” role of providing just enough help to get from A to B, it can be in the way.

Of course, that approach can run into challenges with API GW where it really wants expose exactly what the API exposes and try to help enforce those aspects.

As always, just my $0.02. Lots of ways to tackle this one with pros/cons to consider.

#API-Gateway
#Integration-Server-and-ESB
#webMethods
#API-Management