Using Azure APIM and Stateless Logic Apps

Protecting Azure Logic App instances with Azure API Management (APIM) is a good practice for many reasons including security, developer consumption, caching, abstracting your end point and many other reasons. In a previous video, I discussed some of the performance benefits of Stateless Logic App instances. Since we can now extract more performance our of Azure Logic Apps by using stateless execution, do we still need to use Azure APIM?

In short, the answer is yes. While caching stateless requests may not yield as much performance gains as caching stateful implementations, there are still other benefits. For example, I am not a fan of exposing any logic app directly to an external consumer. Using Azure APIM to abstract your implementation is valuable, especially if you need to change some back-end implementation details, but you don’t want to project that on your consumer/trading partner. For example, perhaps you had an interface that ran in a stateful manner within the consumption plan and you wanted to move that interface over to a stateless implementation within the Standard SKU. You would need to communicate these changes down to your consumer. However, if you used APIM in front of your logic apps, you trading partner wouldn’t even know that a change has taken place.

The experience of protecting a stateless request is a little different than protecting a consumption-based logic app. As of this writing 12/2021, Logic Apps (Standard) do not show up when you choose to create from an existing Logic App. I am sure this experience is bound to change and at some point, we should see direct support inside of APIM for stateless logic apps.

For the purposes of this post, I have created a stateless logic app that will retrieve data from Microsoft Dataverse and return that data back to the caller. Once we have built our logic app and tested it, we need to copy the URL from our HTTP trigger.

With our logic app built, we will now transition to our Azure API Management instance. Next, we will clock on APIs and then will define an API using the HTTP experience. This is the result of stateless logic apps not showing up in Logic App experience available in Azure APIM.

We will now provide some meta data for our API. If you don’t have an existing API configured in APIM, you don’t need to provide an API URL suffix, but otherwise you will need to. For now, you don’t need to provide a Web service URL as we will take care of that later.

We can now go ahead and Add operation to our API.

Here we will provide a Display name and Name. For URL we can just provide a / since we will re-write our URL in our policy.

In my scenario, I do have a query parameter that I need to pass. If you don’t have one, you can skip this step.

Since we are providing a simple GET request, we don’t have a sample request message to provide, but can provide a sample 200 OK response.

We can now go ahead and define our Backend – HTTP endpoint by clicking on the pencil icon.

Since we are currently using a stateless logic app, we can’t select Azure Logic App and need to select HTTP(s) endpoint instead. For our Service URL, we can paste in the entire URL from our logic app trigger.

Note: When you add this URL that includes the related query parameters(api-version, key etc), it will embed those query parameters inside of the set-backend-service base-url attribute. If you subsequently pass in additional query parameters into your APIM instance, you will likely encounter errors calling the logic app. Should you need to pass in additional query parameters, you should modify your policy to include set-query-parameter values and then remove those values from the set-backend-service base-url.

At this point the base configuration of our API has been configured. You can now add additional policies as you see fit. But, for the purposes of this post, we can go ahead and test our API.

Testing

With our operation selected (Customers), we can now click on the Test tab, provide our state query parameter and then click the Send button.

If everything is configured properly, we should see a 200 OK status returned and should see some data returned from our logic app.

Conclusion

In this post, we discussed how we can protect an Azure Logic App (Standard) stateless workflow using Azure API Management. Using this approach abstracts our underlying implementation and provides additional opportunities to lever API management capabilities like caching, rate limiting, analytics etc.