Skip to main content

Return the correct Content-Type for a Logic App API in API Management

Given our company cloud strategy, BizTalk is finite for us and we have started the transition to an iPaaS landscape based on Microsoft Azure. The BizTalk environment is replaced by an environment consisting of API Management, Logic Apps, Functions, Event Grid and Service Bus parts.

One of the BizTalk HTTP APIs is exposed by API Management to internal and external consumers and is partly migrated to a Logic App already. This transformation to iPaaS should have no impact on the consumers of the API Management endpoints. 

Sadly we found out this week that this was not true for one of the methods within that specific API. One of the consumers was transitioning from the BizTalk API to the version hosted in API Management. When testing the API they complained that the received an error that the HTTP Header Content-Type was not supported in their client. The value they received was application/xml instead of the BasicHttpBinding value text/xml; charset=utf-8 they needed.

The developer which developed the Logic App used a HTTP trigger which returns a XML object. By default the Content-Type value will be application/xml for this scenario. To be fully compliant to the original BizTalk HTTP API the value should be SOAP 1.1 based and thus text/xml; charset=utf-8. You can change the Content-Type in the Logic App self by specifying a Key-Value pair in the Headers section for the Content-Type with the needed value for the HTTP connector. A sample for this can you find in the documentation where the Content-Type is changed into the application/x-www-form-urlencoded type.

Because realizing that change would take some time because another DevOps team is involved I tried to solve this issue myself within API Management with a quick API Management policy fix. When the client makes a call to the API Management endpoint I try to determine which kind of binding they use by checking the Content-Type they use. We store that information in a variable with a Set variable step which we use within the response phase to set the correct Content-Type with a Set request method. With the Control flow option we check if we have a caller which uses a BasicHttpBinding or a WsHttpBinding and correct the Content-Type value to the corresponding SOAP 1.1 or SOAP 1.2 value. All other scenarios will use the value supplied by the Logic App.

The policy of the API looks like this:

    <!-- Preserve incoming Content-Type information -->
    <set-variable name="isBasicHttp" value="@(context.Request.Headers[&quot;Content-Type&quot;].Contains(&quot;text/xml; charset=utf-8&quot;))"/>
    <set-variable name="isWsHttp" value="@(context.Request.Headers[&quot;Content-Type&quot;].Contains(&quot;application/soap+xml; charset=utf-8&quot;))"/>
    <!-- Change Content-Type to match the original request -->
      <when condition="@(context.Variables.GetValueOrDefault&lt;bool&gt;(&quot;isBasicHttp&quot;))">
        <set-header name="Content-Type" exists-action="override">
          <value>text/xml; charset=utf-8</value>
      <when condition="@(context.Variables.GetValueOrDefault&lt;bool&gt;(&quot;isWsHttp&quot;))">
        <set-header name="Content-Type" exists-action="override">
         <value>application/soap+xml; charset=utf-8</value>


Popular posts from this blog

CS8357: The specified version string contains wildcards, which are not compatible with determinism.

Today I was busy with creating a WCF service solution in Visual Studio Enterprise 2017 (15.9.2). In this solution I use a few C# class libraries based on .NET 4.7.2. When I compiled the solution I got this error message: Error CS8357: The specified version string contains wildcards, which are not compatible with determinism. Either remove wildcards from the version string, or disable determinism for this compilation The error message is linking to my AssemblyInfo.cs file of the Class library projects. In all the projects of this solution I use the wildcard notation for generating build and revision numbers. // Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: // [assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("1.0.

Fixing HTTP Error 401.2 unauthorized on local IIS

Sometimes the Windows Authentication got broken on IIS servers so you cannot log in locally on the server. In that case you get the dreadfully error message HTTP Error 401.2 - Unauthorized You are not authorized to view this page due to invalid authentication headers. To fix this issue you can repair the Windows Authentication feature with the following PowerShell commands: Remove-WindowsFeature Web-Windows-Auth Add-WindowsFeature Web-Windows-Auth

Deploy with ARM templates an Azure DevTest Lab environment

Within the company I work for we use Azure DevTest Labs already for a year to host our personal development computer and the BizTalk CI machines we need. We are planning to host also our development and test environments in Lab environments. At the moment we configure the lab environments manually. I invested some time to write ARM templates to deploy Azure DevTest Labs within 5 minutes based on Azure DevOps CI/CD pipelines. In the process of writing these scripts I learned a lot. For example that the Azure documentation is not always up to date and that includes also tooling like Azure Resource Explorer . Based on querying the REST API with Postman I found the missing pieces for deploying a DevTest Lab environment based on nested ARM templates. In this post I will document the nested ARM template I created the last few days. Lab With the first template you can create the lab environment itself and configure the following parts of the environment Lab settings; like the st