The majority of web applications currently utilize RESTful web services for exchanging structured information, however many continue to use SOAP services, especially where security and reliability are paramount factors.
In the world of AIS and Logic Apps, I have often come across on-premises SOAP services that needs to communicate with logic apps. While Azure Logic Apps offers over 325+ connectors to connect to various services, they also allow us to create Logic Apps Custom Connectors that can connect to any HTTP services.
Logic Apps Custom Connectors boasts two modes – SOAP to REST and SOAP pass-through. The SOAP to REST method lets Logic Apps exchange information in json as opposed to xml for the pass-through mode.
Use Case for an On-Prem SOAP Service Connector
In this case I have a stub SOAP service available through a on-premises data gateway and a WSDL file from the service. A new Logic Apps Custom Connector is set up with a SOAP API endpoint with SOAP to REST call mode.
The wsdl definition can be specified from a wsdl file or from a uri. The service is hosted on premises hence the Connect via on-premises data gateway option is enabled.
The connector definition is an OpenAPI standard containing all available SOAP actions as described in the WSDL.
The portal editor features an additional Swagger editor or even lets you edit externally in Swagger platform by letting you download the definition. User-facing visibility can be configured – I have used important which displays the service parameters in a form layout form the Logic Apps designer – one of the other benefits of using SOAP to REST.
Leveraging the connector in Logic Apps
Upon setting up the connector, it will be listed in the Custom tab of Choose an operation dialog box within Logic Apps designer. Because we have configured visibility as important in the connector, all parameters are shown in a form layout which makes it easy to implement and maintain.
Building the Template
Using templates extraction from the portal or using extractor tools, we get the following:
An important note here is the template is incomplete as it requires few other parameters, otherwise the deployed resource would be incomplete.
Firstly, the Swagger definition in the connector is downloaded separately and added to a property named swagger. Furthermore backendService, apiType, wsdlDefinition and capabilities properties also needs to be specified. The wsdlDefinition would contain the importMethod and url/content of the wsdl.
The updated template looks like the following. It is shortened for better readability:
Is Deployment Over Yet?
The template above seems correct however, it would not deploy. Instead, the deployment would get stuck forever with vague internal server error.
I have tried a variety of different approach but have had no success so far.
Manual Workaround
The template can be set up as a soap-passthrough so that we have successful deployment and a skeleton to carry out the changes for SOAP to REST. The url/content needs to be removed and importMethod changed to SoapPassThrough. The rest of the template remains unchanged.
Upon successful deployment, the wsdl can be imported back via the portal. However, the definition is now reset based on the new import. So, any manual changes made to the definition is lost at this point.
We can fix this easily by updating the definition. In the Definition window, hit the Swagger editor switch and replace the swagger definition with the one from the template and voilà, we have our changes in the definition back.
Although painful, this solution somewhat works for us and I do hope you find this useful.
Have you got a question, remark, feedback, or idea for a super-duper addition? Feel free to look at our latest blogs and subscribe to Codit newsletter.
Thank you very much for reading, please do share if you find this useful.
Subscribe to our RSS feed