This blog is an extraction of the session “Developers and Logic Apps” presented by Derek Li at Integrate 2020 Remote.
A Logic App is a cloud service that is used to integrate apps, data, systems, and services across organizations or enterprises and helps to schedule and automates tasks, business processes etc. But what is there to a logic app beyond this. We will see in brief about it in this blog.
Additional capabilities of a Logic App
When looking at a Logic App from an organization’s perspective, we expect more from a logic app than just performing the set of triggers and actions configured to it. Let us see about the following three things that might be expected from a logic app:
The Governance perspective of a Logic App is considered through the context of Azure Policies. Let us consider some scenarios in which you may need to use governance:
- Audit the workflow when certain criteria are met
- Block the usage of certain connectors
- Allow only approved connector usage
- Block the creation of certain connections
- Data Loss Prevention
These actions can be performed by creating an Azure Policy for this scenario you want a certain action to be performed. Let us see how these scenarios can be created using Azure Policies. You can access the policy definition by searching for policy definitions in the search bar.
Audit Workflow using Connectors
You can audit the workflow by using connectors in a logic app. Let us consider a scenario in which the workflow is audited when the mentioned field contains the specified connection. You can perform this audit action by using the policy rule that is given in the image below.
Block Certain Connectors
The use of certain connectors can be blocked by creating an Azure Policy to restrict the user from using certain connectors. Let us consider that an organization doesn’t want its employees to use certain connectors. Let us see an example in which the use of all Instagram connectors is blocked. To do this you can use the code snippet in the below image.
Using Policy Rules in Azure Policies
From the above examples, we have a general idea that we can perform these audit and restriction operations using policy rules. Let us see where to use these policy rules. When you create a policy and get into it you will land in a window where there is a section called “Definitions” where the policy rules should be written in. The below image shows where the Policy Rules should be written in the Definitions section.
There may be a latency period of 15 minutes for the policies to take effect. Once the policies are in effect, the restrictions and audit actions specified by the user will be in effect. The below image shows an example of the policy to block Instagram connectors in effect.
Let us see about DevOps in the context of Workflows running on Function Runtime. Workflows running on Function Runtime have a lot of advantages such as improved performance, portability and better DevOps. Let us see about the DevOps aspect of Workflows running on Function Runtime.
Using Workflows running on Function Runtime we can achieve better DevOps because of the source control available in it, the use of modern CI/CD pipelines such as Azure DevOps or GitHub Action, and using the desired infrastructure as a code.
Let us see a sample process that a developer may go through in modifying an already up and running logic app using DevOps:
- Clone the GitHub repository
- Make edits and test it locally in VS code
- Push changes to GitHub remote
- GitHub Action automatically builds and deploy latest to azure
- GitHub Action automatically builds docker image and publish it to the hub
The below image shows the initial values of a sample Logic App:
Once the developer completes the modifications and commits the changes to the GitHub Repository, you can see that there are two GitHub Actions that are being executed as a result of the latest commit. The below image shows the New GitHub Actions that have been initialized because of the latest commit performed by the developer.
Once these commits have been executed, you can see the changes being reflected in the Logic App and the initial value of the body has been replaced by the new value. The below image shows the new value of the Logic App.
We can use logic apps for integration and automation. Let us see about the automation scenario of Logic Apps. There are some scenarios which we may want to automate:
- Auto Start/Stop VMs
- Auto purge old blobs
- Send Notification when resource state changes
- Send a monthly email on resource cost
The idea is to build automated tasks into each resource which are easy to use. These automated tasks will use certain built-in templates initially and these templates will be open-sourced so that you can learn about these templates and possibly contribute towards it.
Steps to create an Automated Task
- Go into any resource and under the settings section you will find the Automated Tasks Option
- Click it and click add to create a new automated task
- Once you click Add you will be prompted to select a template. Select one of the templates and click Next
- Provide the authentication details that will be necessary for the template and click Next
- Provide the necessary configuration details and click Create to create the automated task. Once the automated task is created you can edit it in a similar way to which you edit the triggers and actions of a logic app.
The below picture shows the email that has been generated by an automated event to the user regarding the resource cost:
The automated task is an area that is under development and the ability to provide a user with the access to create custom automated events templates will be bought in in the future updates.
In this blog post, we discussed the additional capabilities of a Logic App such as Governance, DevOps, and Automation. There are a lot of features for logic Apps that are in the initial stage of features. Stay tuned for further updates. Happy Learning!