Running Azure Logic App Runtime outside Azure

Azure Logic Apps is a managed service in Azure which lets developers run workflows in azure. A workflow in Logic Apps is a combination of Triggers and actions, which can fetch data from a source, do some transformations on that data and submit/push the data to the target system.

Few scenarios in which Logic Apps can be used are:

• Schedule and send email notifications using Office 365 when a specific event happens, for example, a new file is uploaded.
• Route and process customer orders across on-premises systems and cloud services.
• Move uploaded files from an SFTP or FTP server to Azure Storage.
• Monitor tweets, analyse the sentiment, and create alerts or tasks for items that need review.

Apart from creating and using Azure Logic Apps in Azure, one can also develop and deploy Logic Apps Runtime outside azure.

Scenarios where running Logic Apps Runtime outside Azure would make sense are:

1. Running Workflows on-premise. Fetching data from an on-premise system, doing some transformations on the data and pushing the data to on-premise or azure.
2. Using Logic App Runtime as an integration framework for small workloads between on-premise and azure.
3. Creating B2B workflows on-premise by integrating various 3rd party applications like Email Server, some ERP system or some data storage.

Before we move into how a Logic App Runtime gets developed and deployed, let’s understand Logic App Runtime on a high level.

A Logic App Runtime contains following components:

1. Function App Runtime: It is the runtime on which Logic app works. Whenever we start logic app runtime workflows, it spins up function app runtime on which the workflows are executed.
2. Workflows: These are json files which can be opened in designer using an extension like https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurelogicapps.
3. Built-In Connectors- Built In Connectors make direct connections from the Logic App Runtime to the target component like SFTP, HTTP endpoint etc.

Apart from Built in Connectors, Logic App Runtime uses Azure connectors, which are summoned by Logic App Runtime to make connections to the target systems.

Read more about connectors in Logic App here: https://docs.microsoft.com/en-us/azure/connectors/apis-list

Logic App Runtime also needs an active connection with Azure. The connection strings of Azure Connectors are stored in a resource group (this can be configured locally in connections.json).

Apart from connection with Azure, Logic app runtime also needs a storage account in Azure to save the state of the workflows.

For a non-production scenario, Azurite (which is an emulator of storage account) can be used to test the workflows locally. Azurite extension in vs code- https://marketplace.visualstudio.com/items?itemName=Azurite.azurite

To setup Logic App runtime locally we would need the following components:

1. VS Code with Logic App runtime (Standard) and Azurite extensions installed.
2. Azure Subscription, a Resource Group and a service principal having contributor access to the resource group.
3. Azure Storage account provisioned inside the resource group.
4. Connection string for storage account or key vault reference.

Once we have all the above components setup, we can click on the Azure icon in VS Code and create a Standard Logic App.

Once a standard logic app is created, we will notice that there are few files, which have been created by this extension. One of the important files is workflow.json, which will contain our designed workflow.

We can open workflow from workflow.json in a designer and create our workflows by adding triggers and actions.

Once the workflows have been created, we can run the Logic App Runtime by starting the function app runtime“func host start — verbose”. This should start the workflows in our local Logic App Runtime.

To deploy the Logic App runtime, we have 2 options:

1. Deploy the logic app runtime along with the workflows to a machine which can authenticate with Azure.
2. Containerise the workflows and authenticate to azure using service principal. For doing this, we can create a Dockerfile like the following:

FROM mcr.microsoft.com/azure-functions/node:3.0
RUN curl -sL https://aka.ms/InstallAzureCLIDeb | bash
RUN az login --service-principal --username USERNAME --tenant TENANT --password PASSWORD
ENV AzureWebJobsStorage DefaultEndpointsProtocol=STORAGEACCOUNTENDPOINT
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
AzureFunctionsJobHost__Logging__Console__IsEnabled=true \
FUNCTIONS_V2_COMPATIBILITY_MODE=true \
COPY . /home/site/wwwroot
RUN cd /home/site/wwwroot

We would also need to provide connection strings of the source and target components being used by our workflows in the dockerfile as environment variables.

Once we have created the Dockerfile, we can create the image of Logic App Runtime workflows and deploy containers from the image on any machine having docker engine and connectivity to the source and target systems along with azure.

One of the use cases that can be achieved using Logic App Runtime is Edge data transfer/Integration for data/events. Data from an edge environment(REST API, SFTP endpoint) can be collected by the Logic App Runtime and can be pushed to Azure (Storage account/Event Hub/ REST API).

For Designing the workflow, we can open the workflow.json and add a schedule trigger which will get data from a REST API every 15 seconds and send the data to Event Hub.

After designing the workflow, we can start the function app runtime to see our workflow in action, once we start the function app runtime we can see the logs have started coming and statusCode is Accepted which indicates the workflow is running fine, during transition of workflow Status field on the logs changes from Skipped to Triggered to Succeeded.

We can subscribe to the new message of Event Hub and see that the message which were fetched by hitting the REST API have started coming in Event hubs:

We can also run the workflows inside the docker container by running:

logicappdemo is the name of the docker image which we created by building the Docker-file mentioned in top section of this post.

After starting the container similar logs come which tell us that logic app workflows are running successfully:

Continue: Observability of Logic App Runtime- https://lakshaykaushik2506.medium.com/observability-of-logic-app-runtime-36171ef5e01c