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:

<policies>
  <inbound>
    <base/>
    <!-- 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;))"/>
  </inbound>
  <backend>
    <base/>
  </backend>
  <outbound>
    <base/>
    <!-- Change Content-Type to match the original request -->
    <choose>
      <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>
        </set-header>
      </when>
      <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>
        </set-header>
      </when>
    </choose>
  </outbound>
  <on-error>
    <base/>
  </on-error>
</policies>

Comments

Popular posts from this blog

Assign an existing certificate to your IIS website with WiX

Recently I had to change the bindings of existing IIS hosted websites and APIs from HTTP to HTTPS. They are installed with a MSI file created with the WiX Toolset . Because I have to use an already on the server installed certificate I cannot use the Certificate element from the IIS Extension because this element only supports installing and uninstalling certificates based on PFX files. After doing some research I found the blog article Assign Certificate (Set HTTPS Binding certificate) to IIS website from Wix Installer which described the usage of Custom Actions for this purpose. I adopted this approach and rewrote the code for my scenario. With WiX I still create the website. <iis:WebSite Id="WebSite" ConfigureIfExists="yes" AutoStart="yes" Description="MyWebsite" Directory="IISROOT" StartOnInstall="yes"> <iis:WebAddress Id="WebSite...

Permantly delete an AD object

At the moment I am busy with PowerShell DSC scripts that also create objects within the Active Directory. Because it's work in progress you have to delete those objects regularly. Witin this sandbox environment the recycle bin feature is enabled so the objects are kept 30 days.  To permantly delete such objects (so you have a clean testing situation) you can use the following PowerShell command. Get-ADObject -filter {sAMAccountName -eq "<name of object>$"} -includeDeletedObjects -property * | Remove-ADObject

Make steps conditional in multi-stage YAML pipelines

To make the switch from the graphical release pipelines in Azure DevOps I am missing two features. The first one is to be able to defer a deploy and the second one is to exclude certain deployment steps without the need for editing the YAML file.  The defer option is something Microsoft has to solve in their Azure DevOps proposition. It's a feature which you have in the graphical release pipeline but what they have not implemented yet in their YAML pipeline replacement. Approvals and certain gate conditions are implemented on the environment but the defer option is still missing .  Pipeline The conditional deployment option can be implemented with the help of runtime parameters and expressions . In the parameter section you define boolean parameters which will control the deploy behavior. With the expressions you can control which stage/job/task should be executed when the pipeline runs. In the below YAML sample I experimented with conditions in the azure-pipelines.yml ...