Azure Logic Apps is a main enterprise-level integration service and lets us automate processes as workflows across the organization. It allows for the simple connection of different services and applications with multiple connectors. Furthermore, by leveraging a serverless model, it reduces costs and shortens the time needed for developing a working solution.
The following topics will be covered in this chapter:
To perform exercises from this chapter, you will need the following:
Sometimes, you need to integrate multiple services and automate tasks such as sending an email, creating a file, or generating a report based on some input data (maybe a database table or a social media feed). If you work with a specific cloud vendor (in this case, Microsoft Azure), it can be crucial to be able to rapidly develop workflows that can be versioned and are natively integrated with multiple cloud services, using a tool that does not require learning many different concepts to get started. Such a service is Azure Logic Apps, which you will learn about in this chapter.
In Chapter 7, Serverless and Azure Functions and Chapter 8, Durable Functions, you learned about Azure Functions, which required a trigger to be executed. The situation is similar with Azure Logic Apps – you need to define specific criteria that tell the runtime when a logic app instance should be executed. During the execution, even more actions are performed:
The following shows an example of a flow that is executed daily and sets a variable that is used to remove outdated blobs:
Figure 9.1 – The Azure Logic Apps flow for setting a variable and then listing available files
As you can see, it contains three different blocks, which are the initial part of the flow (in fact, the whole workflow is much bigger, as it contains a loop and different conditions and actions – we will cover all of these later):
You probably noticed one more thing – the workflow is built using graphical blocks, which can be connected by defining multiple relations. While such a solution is a real handful when creating and modifying logic apps, it can be problematic when versioning and developing within a team. Fortunately, each flow is also defined in JSON:
Figure 9.2 – JSON representation of the Azure Logic Apps flow
Thanks to such a representation, you can add your logic apps to any version control system (for example, Git or Subversion (SVN)) and modify them when you wish. Additionally, you can automate the creation of different logic apps by generating code files on the fly.
You may wonder what the real use case for Azure Logic Apps is when you have other possibilities available (Azure Functions and custom workflows). If you take a closer look at its features, you will notice the following:
The following shows the current pricing for Azure Logic Apps:
Important Note
In Azure Logic Apps, the first 4,000 executions are free if you are using the Consumption plan.
The preceding prices refer to the Consumption plan, which works in a similar way as the Consumption plan for Azure Function – you are paying for your usage. However, there is also a way to use the Standard plan, which is structured almost identically to the Premium plan of Azure Functions:
However, to fully understand the Consumption plan, we have to describe these two terms:
Note that Azure Logic Apps can be quite expensive when performing complicated workflows very often. In such scenarios, consider using other services (such as Azure Functions), which, of course, require much more time spent on developing but, on the other hand, offer better pricing.
The main concept of Azure Logic Apps is connectors. Connectors are both actions and triggers that you can use in your workflows to fetch data, transform it, and extend the current capabilities of your applications. Currently, Azure logic apps have 200 different connectors available, which allow you to integrate with multiple Azure services (such as Azure API Management or Azure Functions), other systems (OneDrive and Salesforce), and even on-premises systems.
In Azure Logic Apps, connectors are divided into two categories:
Managed connectors are divided into even more detailed groups:
In this section, we will go through multiple examples of different types of connectors so that you will be able to understand their use cases and functionality.
The following shows examples of built-in connectors that you can use in your Azure logic apps:
As you can see, we have here more generic connectors (schedule, HTTP, and request) and those specific to a service (such as Azure Functions and Azure App Service). In general, these connectors are the foundation of most Azure logic apps – when it comes to creating workflows, we very often are required to call an API or perform various other HTTP requests.
Note that each connector has detailed documentation available, describing its use cases and how you can develop workflows with it. You can find a link to it in the Further reading section in this chapter.
When using managed API connectors, you will be able to integrate with services and systems that require configuring a connection; these can be used when executing an instance of a logic app. The following shows an example of a logic app in a resource group with an additional resource defined as the API connection:
In the documentation, plenty of different API connectors are described – including the following:
As you can see, with these connectors, we have access to a variety of different Azure services and other systems (here, Office 365 and SharePoint), which can be leveraged in your workflows to extend your application's logic.
As I described previously, with Azure Logic Apps, you can also integrate with on-premises services such as different database systems (Oracle, MySQL, and SQL Server), business analytics systems (Teradata), or filesystems.
To access on-premises data, you will have to create a resource called an on-premises data gateway. Instructions about how to do so can be found here: https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-connection.
Azure Logic Apps also lets you build so-called B2B solutions using integration accounts and leveraging a variety of advanced connectors, such as XML Transforms and X12 encoding/decoding, or even accessing enterprise systems, such as the Systems Applications and Products in Data Processing (SAP). While, for most users, these capabilities are not that useful (as these are rather advanced topics that most people are not familiar with), being able to build logic apps that allow for seamless communication between partners is an interesting functionality. We will cover more about B2B integration within Azure Logic Apps at the end of this chapter.
As Azure Logic Apps is also targeted at non-developers, the process of creating instances and working with them is quite straightforward. In this section of this chapter, we will learn how to work with them in the Azure portal and Visual Studio, and how to integrate multiple services and use actions to control a workflow.
To create an instance of a logic app, follow these steps:
Figure 9.3 – The creation of an Azure logic app in the portal
Figure 9.4 – The created Azure logic app
Figure 9.5 – Templates for Azure Logic Apps
Figure 9.6 – Connecting to Azure Storage
Figure 9.7 – The configuration of the scheduler flow
Note that this connector does not create a queue if it does not exist. Make sure that you have one before starting a logic app instance. If you do not know how to do so, refer to Chapter 11, Reactive Architecture with Event Grid, where we will discuss Azure Storage features and queues.
With the workflow configured, click on the Save button and then select Run Trigger. You will be able to see how the full flow was executed:
Figure 9.8 – The executed flow
This flow was executed correctly, but what if there is an error? Well, fortunately, Azure Logic Apps offers an option to debug each step and display all the errors that were the cause of a failed flow. When you go to the Overview blade in your logic app, you can click on the flow that was not successful:
Figure 9.9 – The Overview blade with a failed flow
When you click on it, you will see a new screen containing all the steps executed with their status and errors (if any):
Figure 9.10 – The failed flow with an error stating that there was no blob found
Congratulations! You have created your first Azure logic app! In the next section, we will see how we can work with it in Visual Studio.
While it is perfectly fine to work with your logic apps using the Azure portal, you do not always want to log in and use its User Interface (UI). As it is possible to install an extension to Visual Studio Code, which enables you to work with Azure logic apps, we will try this to see how it works:
Figure 9.11 – The Azure Logic Apps extension
This will add a new section for your Azure tab, showing all the logic apps available for the account that you are currently signed in with.
Figure 9.12 – The logic apps available in Visual Studio Code
Remember that the availability of the logic apps depends on the account you used to sign in to Azure in Visual Studio Code. If you are missing some resources, make sure that they are available for your account.
Figure 9.13 – Azure logic apps designed in Visual Studio Code
You can work with your logic app in Visual Studio Code in the same manner as you would work in the Azure portal. Additionally, you can look at its history and disable and delete it. To do so, extend the item in the view presenting your resource:
Figure 9.14 – Accessing logic app history
When you double-click on an item in the run history, you will see a JSON representation of your run, where you can debug a particular invocation. This is very helpful, as you can quickly develop and test your logic apps and work on other parts of your application without leaving your IDE.
I strongly encourage you to play a little bit with Azure Logic Apps by yourself in Visual Studio Code, as this is a great addition to the whole service and has the same feeling as the portal.
To a slight extent, we have already covered B2B integration of Azure Logic Apps in this chapter, but I wanted to give you some more information regarding this topic, as this service is not always recognized as an enterprise integration tool. Surprisingly, Azure Logic Apps has many interesting features to offer when it comes to exchanging messages and data between partners, and you'll find the relevant details in this section.
To get started with B2B integration, you will need an integration account – this is a special container for integration artifacts that you will work with. In general, it allows you to store a variety of different items (such as certificates, schemas, and agreements) in one place so that you can work with them in Azure Logic Apps.
To create such an account, click on + Create a resource and search for Integration Account:
Figure 9.15 – Creating an integration account
As you can see, it offers a simple form where, in fact, the only thing you need to do is select the proper pricing tier. There is also an option to associate it with an Integration Service Environment (ISE). We will cover ISE in the next section of this chapter.
The selected tier changes the maximum number of stored artifacts. You can, of course, change it later.
Once you have an integration account instance, you will need to link it with your logic app. To do so, go to the Workflow settings blade in your instance of Azure Logic Apps and search for the Integration account section. Once the integration account is selected, click Save to complete the setup:
Figure 9.16 – Configuring an integration account
Now, you should be able to use connectors, which require an integration account to work.
Normally, if your logic app has no integration account linked, when you add a step requiring such functionality, you will have to provide a custom name. Once such a connection is available, you will not be asked for additional information again.
In the Further reading section of this chapter, you will find additional links that can help you gather more information regarding B2B integration in Azure Logic Apps.
As Azure logic apps often work in enterprise environments, establishing secure connectivity is a must. Whether you want to connect to other Azure resources inside virtual networks or use hybrid connectivity to connect to your on-premises services, you need a way to integrate individual components of your system and allow them to talk to each other. The overall setup will depend on the plan used to host your logic apps:
When choosing a model that works for you, you need to consider several details. Use of ISE is not free of charge – there are two pricing tiers, which are charged as follows:
Important Note
Take into consideration that the Developer tier does not offer an SLA for the service.
As you can see, those charges are high, and when ISE is deployed, it will cost you a considerable amount of money. There are, however, many benefits of that setup:
You must consider all the pros and cons and decide whether the high price of an ISE is worth it. The alternative of using the Standard plan may be tempting, but remember that it does not come without downsides:
For more information, refer to the Further reading section. It contains additional details about networking in Azure Logic Apps and private endpoints.
In this chapter, you have learned about Azure Logic Apps, a simple yet useful service whose use isn't restricted to Azure ninjas. You read about different connectors and multiple ways of working with your logic apps, using both the Azure portal (both with templates and the code editor) and Visual Studio Code. Additionally, you now know a little about B2B integration in that service and how to start it.
In Chapter 10, Swiss Army Knife – Azure Cosmos DB, we cover Azure CosmosDB – a serverless database that enables you to use different data models in the same service.
As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:
For more information, you can refer to the following links:
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-overview
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-as2
https://docs.microsoft.com/en-us/connectors/
https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-overview