Introduction to Logic Apps

The technology is based on a pay-per-execution model, where you only pay for the logic apps steps that are executed every time a new logic app instance is invoked. Logic Apps has a useful management dashboard showing key information at a glance, like status of latest execution, details on a given execution instance, and configuration properties, among others.

Anatomy of a logic app

A logic app is comprised of a set of building blocks that work together to construct a process that orchestrates integrations between various parts. Those building blocks are

• Workflows
• Triggers
• Actions
• Flow Controls

Workflows

A workflow is a sequence of API calls and flow control elements that defines a business process automation - each logic app defines a workflow.

When defining a workflow, you need to define at least one trigger - the event that will make the workflow be executed – as well as one or more actions and optionally flow controls that will modify the behaviour of the business process based on data being processed by that workflow.

Triggers

A trigger is the event that kicks off the workflow. A trigger can simply start the workflow, without passing any parameters, or have an initial message associated to it. There are many types of triggers available for logic apps:

Manual triggers

This type of trigger presents an endpoint (url) that users can call directly to start the execution of the workflow. Manual requests and webhooks are examples of this type of trigger.

Scheduled triggers

This type of trigger executes at regular intervals. The schedule can be defined as a regular execution interval (e.g. Every 3 minutes), or be defined to be executed on a specific point in time (every day at 10:00 pm). The recurrence and FTP triggers are examples of Scheduled triggers.

Push triggers

This type of trigger subscribes to events of external systems and are executed when that event happens. The service bus and Dynamics 365 triggers are examples of this type of trigger.

Actions

An action executes one step in the workflow logic. Actions are essentially HTTP calls, executing an operation against a System API. Various types of actions can be selected when creating a new action.

Managed APIs

The default option when choosing a new action, Managed APIs are APIs created and managed by Microsoft to interact with an existing resource. This resource can be a Software as a Service, a database, an FTP location, SMTP server, among others. When using a Managed API, you need to decide which action of that API you will invoke, and configure how the logic app will connect to the resource. For example, you can save a file on an FTP Server, or get a list of elements from Dynamics 365. Since Logic Apps was released the product team has been creating new and improving existing Managed APIs. A list of the current Managed API Connectors can be found here.

Custom APIs

Logic Apps can identify custom APIs deployed in the same Azure Resource Group (the containers that define a logical group of Azure items that work together). Thanks to a common API definition language called Swagger, Logic Apps can identify the operations and parameters required to fulfill the operation, making sure that experience provided to you on your own APIs is quite similar to the experience provided by the Managed APIs.

Azure Functions

Azure Functions allow discrete pieces of code to be grouped inside a reusable repository (a Function App). Logic Apps allow specific types of functions (webhook functions) to be invoked as an Action. It also allows new Functions to be created in flight.

Nested Workflows

Nested workflows allow a logic app to be invoked as part of another logic app. This allows discrete pieces of workflow logic to be created and reused to compose larger orchestrations.

API Management

API Management allows you to provide a layer of abstraction between your services, exposing a single set of APIs to developers, even if the backend services are more fragmented. Logic Apps can consume those APIs just like a Custom API. This is a good way to abstract or manage complex service or API calls. API Management also allows you to have a tighter control on the usage of those services, implementing throttling, caching and redirection policies, for example.

Flow Controls

Flow controls allow you to control the flow of execution of your workflow, analyzing the messages from a trigger or previous actions. There are currently 4 types of flow control available in the designer:

‍

Conditions

A condition allows you to create a decision tree inside a logic app. It defines two branches of execution, based on the evaluation of an expression. Those expressions use Boolean operators - like equals, or, and, contains. Those operators compare two values -  which can come from previous action output, the trigger that initiated the workflow or static values like literal values or parameters. If the expression is evaluated to true, one branch of the condition is executed. Otherwise the other branch is executed. Each branch can also have nested conditions. Operators and other functions are part of a scripting language used by Logic Apps - the Workflow Definition Language. A list of available commands, functions and operations of the Workflow Definition Language can be found here.

For Each Loops

For Each loop allow one or more actions and other flow controls to be executed for each item in an array. Like the conditions, this array belongs to a previous action output or the workflow trigger. You use the special operator item() to identify an instance of the element in the array.

Do Until Loops

Do until loops allow a single action to be executed repeatedly until an expression associated to the action being executed is evaluated to true. Optionally you can also define a "circuit breaker" condition, in the form of several executions or a timeout period. This allows you to avoid an infinite loop. Notice that in contrast to For Each Loops, at this stage Do Until Loops can only accept a single action.

Scopes

Scopes groups actions and flow controls together, defining a "mini workflow" inside the main workflow. The advantage is that the result of this scope can be evaluated as a single action - if any action fails to execute within the scope, the scope is marked as failed, otherwise it is marked as successful. This can be used to create specific gate checks within the workflow, avoiding execution of actions that are dependent on previous actions, or creating notification and compensation processes.

‍

Is Logic Apps right for my integration?

There are various integrations scenarios, and usually multiple ways to design and implement that scenario. Until the launch of Logic Apps, cloud and hybrid integration scenarios were harder to implement using Microsoft technologies, because there was no easy to adopt workflow or orchestration capability. Logic Apps now fills that gap, allowing you to implement those scenarios and tap into a wide range of supporting technologies. Here are some scenarios that would work well with Logic Apps.

Integration with Software as a Service (SaaS) applications

This is one of the scenarios where Logic Apps excels. The ever-growing number of Managed API connectors allow you to quickly integrate with SaaS applications in a fast and guided way. The number of connectors have been growing at a fast pace. The advantage of the Managed API connectors is that you don't have to guess the parameters you need to pass when executing a specific action.

But what happens if you don't have a Managed API available? As long as your SaaS application exposes an API that can be accessed via HTTP (Rest, SOAP), you can still integrate with that application, manually creating your API call, using the generic HTTP action.

Integration with bespoke APIs

Like the Software as a Service scenarios, you can integrate with custom built APIs, as long as they can be accessed via HTTP.

If you created your Web API using Microsoft .NET, there is a good chance that you have an API definition file, called Swagger, available. If that is the case, you can have a similar experience to Managed APIs, with an action that will guide you through the parameters definition. Otherwise, you can still integrate manually constructing your API call, using the generic HTTP action.

Cloud to on-premises integration

You can integrate with Cloud resources using Logic Apps in a couple of ways. If the resource you are trying to access has a connector that supports the on-premises data gateway you can access the resource directly. Today that list includes:

• DB2
• Folders and network shares on-premises
• Informix
• MQ
• SharePoint
• SQL Server

If the resource you need to connect is not available via the on-premises data gateway, you can still take advantage of Logic Apps. You can expose a Web API to connect to that resource, thanks to the hybrid connection capability on Web APIs - a generic way to connect to on-premises resources. You will need to implement some bespoke code.

‍

Last but not least, if your company already has, or is planning to deploy, BizTalk Server, BizTalk Server 2016 has native integration to and from Logic Apps. The combination of both technologies is a compelling case for migrating to the latest version of BizTalk, as it opens a much wider range of integration scenarios.

‍

Summary

Logic Apps is the latest technology in the Microsoft Integration toolkit. It allows you to concentrate on composing your integration processes, instead of having to worry about hardware and software configuration and maintenance. Its ever-growing connectors library allows you to easily connect to leading SaaS applications, but if your SaaS application of choice is not listed, you can still connect to it using common HTTP calls.

It can be used to integrate a wide variety of cloud and hybrid scenarios which were difficult or costly to implement before, speeding time to market and improving your integration team’s productivity, while still making use of previous investment in APIs and Web Services where necessary.

Based on a pay-per-execution model, it is also cost-effective, allowing you to avoid large up-front costs for installation and setup, and only paying for what is being used, down to each step of a workflow.