Azure API Management: Integration with Standard Logic Apps

In January 2022 there was a blog published on the Microsoft Tech Community that demonstrates how to integrate Azure API Management with Logic Apps (Standard). As mentioned in that blog, the functionality to import workflows in Logic Apps (Standard) is not yet available in API Management, only Logic Apps running on consumption plans. It describes on how to use the front-to-backend routing of API management to create a custom integration.

While this method is functional, it isn’t the most elegant solution, as the caller still has to pass a rather hefty query in the URL. This method also burdens the caller with updating the “sig” query in case there is a change in the workflow request URL for whatever reason.

To simplify this for the caller, we can make use of the rewrite policy in API Management. This way we can obfuscate the backend and present a simple and clear API for developers to use.

Solution

The first couple of steps will be similar to the Microsoft blog:

1. We need to divide the request URL in 2 segments. We’ll use the same URL as in the blog
   Example: https://stdla1.azurewebsites.net:443/api/test2/triggers/manual/invoke?api-version=2020-05-01-preview&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<123abc>
   • Part 1: https://stdla1.azurewebsites.net:443/api/
   • Part 2: /test2/triggers/manual/invoke?api-version=2020-05-01-preview&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<123abc>
2. Place part 1 of the URL in the Webservice URL or the Backend HTTP(s) endpoint:
   • Webservice URL when creating a new HTTP API:
     
     
   • Webservice URL when editing an existing API:
     
   • Backend HTTP(s) endpoint:
     
     
     
     

3. From here on out we’ll differ from the blog. We can give the frontend URL a meaningful simple name:
   
   Without any other changes, when this API is called, it will get routed to https://stdla1.azurewebsites.net:443/api/GetDocument
4. But we want to route it to https://stdla1.azurewebsites.net:443/api/test2/triggers/manual/invoke?api-version=2020-05-01-preview&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<123abc>, so we’ll add a rewrite uri policy. FIrst, navigate to the Policy code editor:
   
   Then we’ll add the rewrite to the inbound policy:

    <inbound>
        <rewrite-uri id="<ANY-ID>" template="/test2/triggers/manual/invoke?api-version=2020-05-01-preview&amp;sp=%2Ftriggers%2Fmanual%2Frun&amp;sv=1.0&amp;sig=<123abc>" />
        <base />
    </inbound>

This will replace the frontend URL, /GetDocument, with part 2 of our request URL.

Note: Don’t forget to escape “&” with “&”.

This way you’ll present https://<APIM-URL>.azure-api.net/GetDocument as an API, that will route it to https://stdla1.azurewebsites.net:443/api/test2/triggers/manual/invoke?api-version=2020-05-01-preview&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<123abc>.

Test

By running a test in API Management, we’ll see it returns a HTTP 200 OK Response:

Named values

To make part 2 of the URL more manageable, you can use a Named value reference in your policy instead and have it declared in the Named Values.

1. Navigate to Named values and click Add:
   
   
2. Define your named value and save:
   
   
3. Edit the policy:

    <inbound>
        <rewrite-uri id="<ANY-ID>" template="{{GetDocumentURL}}" />
        <base />
    </inbound>

If Key Vault is used to store configurable values, it is possible to select “Key vault” as a type instead of Plain and use a Key vault reference.