Azure Logic Apps offer a great set of tools to rapidly build APIs and leverage your existing assets through a variety of connectors. Whether in a more ad-hoc scenario or in a well-designed micro service architecture, it’s always a good way to introduce some form of decoupling through the mediator pattern. If you don’t have the budget for a full blown API Management rollout and your requirements don’t extend further than a basic proxy as a mediator, keep on reading.
One of the intricacies of working with the Logic Apps HTTP input trigger is the dynamic input URLs. When recreating your Logic Apps via ARM templates you’ll notice that these input URLs change once you removed your existing Logic App. This, amongst other reasons make the Logic Apps unsuitable for direct exposure to API consumers. Azure API management offer a great way of building an API gateway between your consumers and Logic Apps but comes with a serious price tag until the consumption tier is finally available later this year. Another way of introducing a mediator for your Logic Apps is Azure Function App Proxies. Although very lightweight, we can consider the Function App Proxy as an API layer with the following characteristics:
- Decouple API consumer from API implementation
By virtue of decoupling we can move our API implementation around in the future, or introduce versioning without impacting the API consumer - Centralised monitoring with Application Insights
Rich out of the box monitoring capabilities through one-click deployment
In this post we’ll look at fully automating resource creation of a microservice, including the following components:
- Application Insights instance
Each App Insights instance has its unique subscription key. The ARM template will resolve the key during deployment for Application Insights integration with the Function App Proxy. - Logic App
As mentioned before the input URL will be dynamic, so we’ll need to resolve this during deployment. - Function App
The function app and its hosting plan can be easily created with an ARM template, together with some application settings including the reference to the Logic App backend URL which is determined during deployment time. - Function App Proxy
Last but not least, proxies are defined as part of the application content. The proxies.json file in the wwwroot contains the actual proxy service definition, establishing the connection with the Logic App.
ARM deployment
Below is the single ARM template that contains the resource definition for the AppInsights instance, Logic App and Function App. The Logic App contains a simple workflow with HTTP trigger and response, outputting a supplied URL parameter in a JSON message body.
The important bit to point out here are setting the LogicAppBackendUri setting in the Function App:
[skip(listCallbackURL(concat(resourceId('Microsoft.Logic/workflows/', variables('logicAppName')), '/triggers/manual'), '2016-06-01').value,8)]
This command strips the ‘https://’ from the dynamically retrieved LogicApp so we can refer to it from our proxy definition below. In addition it will copy a URL query string parameter to the backend service.
Deployment
PowerShell
The following PowerShell script (with a little help of Azure CLI) deploys the ARM template, and function app proxy by uploading the hosts.json and proxies.json files to the Function App using Azure CLI. The DeployAzureResourceGroup.ps1 is the out of the box script that Visual Studio scaffolds in ARM template projects.
The above PowerShell and Azure CLI scripts are an excellent way of creating your assets from scratch. In addition we’ll show how to use an Azure DevOps pipeline to perform true CI/CD.
Azure DevOps pipeline
With Azure DevOps pipelines we can easily setup a CI/CD pipeline with just three simple steps.
The first step performs an Azure resource group deployment to deploy the Logic App, Function App and AppInsights instance.
Next we’ll package the Function App proxy definition into a zip file.
The last step will deploy the packaged proxy definition to our Function App:
After a successful deployment with either PowerShell or Azure DevOps we can finally test our function app:
Happy days. The above demonstrates how we can utilise Azure to create a very cost effective and neat solution to provide an API and proxy whilst leveraging Application Insights to monitor incoming traffic.