SOAP services support in Azure Logic App


Fresh off the press, native support for SOAP services in Logic App!

This feature builds upon the custom OpenAPI connectors recently released for Logic Apps. You now have the option to create SOAP connectors in Logic Apps, by importing a WSDL file instead of an OpenAPI / Swagger definition. Specifically you can try the Fazio sample public SOAP service. Other services you can try out include:

If you have other public SOAP Service to share, please do so in the comments below.

Comments (20)

  1. iamjonathan says:

    Great news 🙂 Thank you for implementing this.
    I did come accross a German Bankleitzahl service when I was testing SOAP using the Http Connector in Logic Apps

    http://www.thomas-bayer.com/axis2/services/BLZService?wsdl

    For instance BLZ code 31470004 returns Deutsche Bank.

  2. Manoj Kumar says:

    i keep getting “The gateway did not receive a response from ‘Microsoft.Web’ within the specified time period.” or “Both WSDL ‘content’ and ‘url’ properties can not be set for a custom API.” when uploading the WSDL

    1. David Burg says:

      Thank you for reporting the issue. My apologies about that, I will investigate it shortly.

    2. David Burg says:

      There was a configuration error on our part in East US2 region which we have manually corrected and are further deploying a hot fix for. I am further investigating issue translating parsing error for unsupported SOAP capabilities to the user interface resulting in incorrectly displaying “Establishing connection with the service failed with code ‘WsdlParsingFailed’. ” instead of the actual parsing error details.

      1. David Burg says:

        East US2 region hot fix deployment is complete.
        Parsing error translation issue has a fix for which is being deployment in the next deployment train for Logic App.

        1. David Burg says:

          Parsing error translation deployment is about to reach production regions. You will be able to see errors such as “The parsing of the WSDL document failed with error ‘Could not resolve type tns:PutObject.’. Check the validity of the WSDL document.” instead of the previous “Establishing connection with the service failed with code ‘WsdlParsingFailed’.”

    3. David Burg says:

      I have reproduced the “Both WSDL ‘content’ and ‘url’ properties can not be set for a custom API.” when providing either then the other. We will fix this issue. As a temporary workaround for the issue you can create a new Logic App Custom Connector so you can successfully provide either the URL or the file for the WSDL.

      1. David Burg says:

        We have a fix in review internally for the error “Both WSDL ‘content’ and ‘url’ properties can not be set for a custom API.”

    4. David Burg says:

      “The gateway did not receive a response from ‘Microsoft.Web’ within the specified time period.”

      This happens when SOAP pass-through is selected. Only SOAP to REST is implemented at the moment. The SOAP pass-through option is been removed from the UI pending a delayed deployment by the UI owners (sorry it shouldn’t have shown would the deployment not have been delayed). We have not completed the backend support for SOAP pass-through and the middle-layer is not interpreting properly the 500 NotSupportedException returned by the backend (we are also fixing the middle-layer).

      1. Michael Fierro says:

        I have been receiving “The gateway did not receive a response from ‘Microsoft.Web’ within the specified time period.” today. Is there an ETA for being able to add a SOAP Http Connector?

        1. David Burg says:

          The deployment of the UI update to no longer display SOAP pass-through option is complete (we will re-enable this at a later date when ready).

          Also I made a mistake during the deployment of the WSDL parser such that created SOAP connectors are internally duplicating the relative path after the SOAP server url. I am correcting the deployment and already fixed regions west central US, west US 2. South east Asia, east Asia and north Europe are been deployment currently. I will correct the rest of the Azure regions on Monday (PST timezone).

          There is further a correction to the Logic App middle-tier to provide actionable parsing error back to the UI which we will release in the days to come.

          1. Michael FIerro says:

            Thanks for the feedback. I’ll try creating one in west central and see what happens!

          2. I tried making a connector in West Central US and I am still getting ‘The gateway did not receive a response from ‘Microsoft.Web’ within the specificed time period.’

            However, I tried one of the SOAP services you have listed and they seemed to work. I am a little surprised because I can access the WSDL I want from my PC and I can also curl the uri from the azure portal. Do you have any suggestions?

          3. David Burg says:

            If you can share you WSDL URL I can take a look. In case the WSDL is not behind a public facing URL you can reach out to Azure support (should be included for free in your subscription) or contact me directly at david (dot) burg (at) microsoft (dot) com. Do include your subscription id so I may look for the telemetry log information matching your error.

          4. David Burg says:

            Deployment to all Azure regions is complete. Custom SOAP connectors created before this correction should be recreated to resolve the relative path duplication error.
            A pending change will further allow to see non-SOAP error responses from SOAP services (the change is currently in review internally).

  3. David Burg says:

    This is another public SOAP service which import should work with Logic Apps (full test not complete yet): http://energywatch.natgrid.co.uk/EDP-PublicUI/PublicPI/InstantaneousFlowWebService.asmx

  4. David Burg says:

    We are working on better documenting the current limitations of this preview feature. As the underlying technology is API Management, you can find some of the limitations at:

    https://docs.microsoft.com/en-us/azure/api-management/api-management-api-import-restrictions

    Furthermore from Michael’s issue below I learned that the soap action must not be an empty string, i.e. don’t do:

    We create a dictionary using the resource name as a key and the resource name is derived from the SoapAction, so we end up with conflicts.

    1. Thanks for the help David.

  5. David Burg says:

    Several customers have tried to import Salesforce WSDL documents which hit limitations of our generic SOAP support. For some, the existing Logic App Salesforce connector already address the needs – see https://docs.microsoft.com/en-us/azure/connectors/connectors-create-api-salesforce
    It does not cover all of Salesforce, case in point it does not cover at the moment Salesforce Marketing Cloud – see https://feedback.azure.com/forums/287593-logic-apps/suggestions/32287339-support-salesforce-marketing-cloud-as-a-connector
    and consider voting for other Salesforce connector ideas at https://feedback.azure.com/forums/287593-logic-apps?query=salesforce

  6. David Burg says:

    A number of SOAP services written with WCF return 500 Internal Service Error. This is because the service owner has not written handling for exceptions resulting from bad client request, such as out of range input values, or not found resource. The default WCF error handler for unhandled exception assumes there is a mistake in the server code and that the server was not expecting this, hence generates a 500 Internal Server Error response. While from RFC compliance the client expects a 400, 404 or other 4xx, the service will instead return a 500 with a SOAP error of internal server error.
    Logic App’s default handling of 500 responses by Connectors -which SOAP is one of them- is to retry a handful of time because an Internal Server Error may be intermittent thus the request may succeed with retry. However if you are familiar with the SOAP service you are connecting to and are aware that bad client requests result in 500 responses, this behavior is undesirable. For this, you should add a retry policy to the API connection action as documented here:
    https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-actions-triggers#apiconnection-action

Skip to main content