SOAP, being a mature technology, have a really wide and often differently interpreted standard set. This makes it a nice tool for corporate users to manipulate into their very specific requirements and technology stack, however, for public consumption, this causes issues which sometimes are difficult or impossible to solve without changing code.
A good example here is that in some standard interpretations, SOAP is allowed to define the same type, if in different XSD files. However, when trying to use this in other interpreters this will crash.
Linx, by using the .Net services to call SOAP services, would be following the .Net defined standards, and this would mean, undoubtedly, that there would be SOAP services out there that would not work with Linx directly, as they break the .Net standards for SOAP.
To solve this, we need to look at SOAP a little bit deeper. In essence SOAP, as a technology, is simply a Web (or HTTP) POST call with a specifically formatted XML payload, which the SOAP server is expecting and understands. It then returns a specifically formatted XML response which the client then can parse and use.
That sounds very much like a REST call, and that is exactly what it is. In stead of an API reference, which gives you the Request and Response formats and requirements, SOAP publishes a WSDL.
So if you’ve got one of these SOAP Services which breaks standards, if you can get the text of a successful Request, you can use REST to make the call with that request body.
Feel free to contact support@linx.software and we'll assist.
As an example, I’m going to use a free SOAP web service which works with countries. This example works fine with Linx’s normal CallSOAPWebService function, but to show the REST option, let’s imagine that it will break and we need to use REST to call it.
WSDL url: http://webservices.oorsprong.org/websamples.countryinfo/CountryInfoService.wso?wsdl
Service url: DataFlex Web Service for Country information
First I will use a tool like SoapUI or Postman to try and get a successful call. (Or if you are already given a successful payload, like in this example, you can use that as well: Example Documents for CountryInfoService)
Simply add a new SOAP Project to SoapUI and add the WSDL. We first test if SoapUI gets a successful response back.
SoapUI Screenshot of the required payload (SoapUI gave us ? parameters, which we just changed to logical values) and a successful response:
Now we can set up Linx with a CallRESTWebService function and call the SOAP service.
Important note: Sometimes, as in this example, the SOAP server requires specific Content-Types. Use your successful call from SoapUI to find these instances. In this example the SOAP server wanted a content type of “text/xml;charset=UTF-8” and did not except the default “application/xml”. So we just added in a Header to overwrite the content type.
So in summary, in the screenshot above you can see that we used the “CallRESTEndpoint” function to call the SOAP Web service.
Here’s the Linx Solution. Done in v5.20: CallSOAPwithREST.lsoz (5.4 KB)