Introduction

If you work for an established organisation going through Digital Transformation or in a modern company born in the digital era, the chances are that IT is required to implement integration solutions more than ever before. Whether an organisation is an incumbent or a new entrant, they need to leverage the power of technology to lead the change or embrace it. Monolithic systems will not be capable of meeting the needs of digital organisations, creating the need to interconnect existing systems with best-of-breed cloud and distributed apps and to expose all these systems to other systems, business partners or consumer apps through easy to consume APIs.

Microsoft provides different technologies on Azure which enable us to build robust application, data and process integration solutions. One of the core offerings for Azure integration is Logic Apps – however there are other Azure PaaS offerings which when used with Logic Apps form the robust building blocks of first-class integration solutions. These technologies together provide a very rich and fully-managed Integration Platform as a Service (iPaaS). In this post, I will try to describe these Azure technologies that we can leverage to make our life easier, and perhaps even more fun, when implementing enterprise integration solutions.

Azure Services to build integration solutions

Out of the very large and growing list of Azure services, there are some that we can utilise to build our integration solutions, including Logic Apps, Azure Functions, API Management, and Service Bus Messaging. I will briefly describe each of them below.

Logic Apps

Logic Apps is a very robust and powerful platform to orchestrate and automate integration workflows. The visual designer together with all the available connectors, and deployment and management tools make it a great tool for this kind of scenarios. Logic Apps also provides the concept of serverless computing, in which you just focus on what you want to achieve, without worrying at all about servers, patching, scaling, etc.

Workflow and Orchestration Capabilities

Logic Apps workflows, which can be easily designed and implemented graphically (via the Azure Portal or Visual Studio), are based on the Workflow Definition Language. These workflows provide rich ways to process and manipulate data than can be obtained or pushed via different connectors. Below there is a figure which shows a simple Logic App workflow with different actions, a condition and a loop.

In Logic Apps workflows we can implement different actions, like calling an HTTP endpoint, calling Azure API Apps, calling WebHooks, waiting, calling a Logic App nested workflow, implementing conditions and loops, query arrays, terminating a workflow, or returning an HTTP Response.

Triggers, Input and Outputs

Logic Apps provides a growing list of connectors that allow us to trigger workflows and get data from and push data to many different protocols, SaaS applications, other Azure and Power Apps Services, and on-premises systems. Below there is a snapshot of the 100+ connectors available at the time of writing (few of them are still in preview).

Protocol Connectors

Azure Services and Power Apps Connectors

SaaS Connectors

B2B, XML, EDI and AS2 Connectors

Hybrid Connectors

As we can see, with all these connectors, Logic Apps allows us to very easily and quickly connect to many different protocols, apps, and also to other Azure Services. Additionally, the Enterprise Integration Pack brings some of the BizTalk Server functionality to Logic Apps and makes really easy to implement B2B integrations based on AS2 and EDI.

Azure Functions

Another Azure service that is very useful when building integration solutions is Azure Functions. Azure Functions are the evolution of Azure WebJobs, which allow us to create microservices or small pieces of code that can run synchronously or asynchronously as part of composite and distributed cloud solutions. Azure Functions are built on top of the WebJobs SDK but with some additional benefits and capabilities, including the option of being deployed on a serverless-style Dynamic Service Plan, in which you pay per consumption only, and also the capability of being triggered via HTTP. Additionally, with Functions you can deploy from very simple to quite complex pieces of code developed on different languages, such as bash (.sh), batch (.bat / .cmd), C#, F#, Node.Js, PHP, PowerShell, and Python.

Triggers, Inputs and Outputs

Azure Functions support different triggers, input and output bindings, which I summarise in the table below. These bindings make Functions very easy to be called and allow them to get data from and push data to other microservices, Logic Apps or other systems or services.

Type / Service	Trigger	Input	Output
Schedule	*
HTTP Call	*	*	*
Azure Blob Storage	*	*	*
Azure Event Hubs	*	*	*
Azure Storage Queues	*	*	*
Azure Service Bus Messaging	*	*	*
Azure Storage Tables		*	*
Azure Mobile Apps Tables		*	*
Azure DocumentDB		*	*
Azure Notification Hubs			*
Twilio SMS Message			*
SendGrid Emails (Not fully documented yet)			*
Files in Cloud File Storage SaaS, such as Box, DropBox, OneDrive, FTP and SFTP (Not fully documented yet)	*	*	*

Processing

Integration Processes usually require custom data and message validation, enrichment, transformation or routing. These can simply be done via custom code on Azure Functions.

Service Bus Messaging

Azure Service Bus Messaging provides reliable message queuing and publish-subscribe messaging capabilities. Azure Service Bus Queues and Topics allow us to decouple in time upstream and downstream systems or different interrelated services. Service Bus Queues provide ordered message delivery to competing consumers, while Service Bus Topics enable publish-subscribe messaging scenarios where multiple consumers can process the same message.

The following Service Bus features make it a key component of most integration solutions on Azure:

temporal decoupling;
the ability to load balance message processing using competing consumers;
the capability of implementing Publish/Subscribe architecture via Service Bus Topics;
and the fact that Functions and Logic Apps can very easily read and write messages from and to Service Bus.

API Management

API Management is an Azure Service which functions as a API Gateway or Front-End for backend APIs in the cloud or on-prem. In addition, it provides a Developer portal which helps to speed up the adoption and use of the implemented APIs. Some of the benefits of API Management are:

Ability to secure APIs by implementing different authentication and authorisation methods, like Azure AD or use of client certificates
Managing consumer accounts
VNET connectivity to connect to other secured resources
Caching to improve API response times
Ability to throttle requests based on the caller or the product
API call routing or forwarding
Transforming requests, by changing the method or implementing richer transformation policies
Tracing calls, or logging requests via Event Hubs
Monitoring and analysing usage and health of APIs
Having a developer's portal which allows to publicise APIs and speed up adoption and the on-boarding process
Ability to monetise APIs

Thanks to all these features, API Management can be leveraged on many integration solutions which require to expose RESTful APIs and require any kind of mediation.

When to use each of these technologies and how they complement each other

Now that I have described the Azure iPaaS offerings, it’s worth analysing when we could use each of these technologies and how they complement each other. I summarise this in the table below.

Technology	When to use it	Use together with
Logic Apps	To implement and orchestrate visually designed integration workflows. To orchestrate distributed microservices. To leverage the 100+ connectors to interact with different protocols, SaaS systems and services, other Azure services, and on-premises systems. To implement cloud-based B2B integrations with AS2 and EDI.	Functions - so custom logic can be implemented in microservices to be orchestrated by LogicApps. Service Bus - to decouple in time different microservices and steps in the integration process. API Management - for those HTTP triggered apps when some of the capabilities of API Management are required.
Azure Functions	To implement code-based microservices or processing.	Logic Apps - so different microservices can be orchestrated. Azure Service Bus Messaging - to decouple in time different microservices. API Management - for those HTTP triggered functions when some of the capabilities of API Management are required.
Service Bus	To decouple in time upstream systems from downstream systems or different microservices. To implement multiple consumers on a Publish/Subscribe pattern. To allow load distribution with multi-instance competing consumers.	Functions and Logic Apps - to decouple in time different microservices and steps in the integration process.
API Management	When any of the API Management features is required, for example: securing backend APIs, API response caching, request throttling, request routing, request transformation, API calls tracing or logging, usage and health analytics, or providing a rich portal for developers.	Functions and Logics Apps - that are triggered by an HTTP call and require some kind of mediation.

Summary

Azure provides a very robust Integration Platform as a Service (iPaaS), which is based on Logic Apps and can be complemented with Azure Functions, Service Bus Messaging and API Management

The breadth and capabilities of many different Azure technologies and how they complement each other is what differentiates Azure against other iPaaS vendors. We can leverage many different services to build first-class integration solutions. Logic Apps is the core engine to implement these. Logic Apps can connect to many different protocols, SaaS apps and Services, to other Azure and Power App Services, to on-premises systems and to B2B trading partners via a growing list of connectors. Logic Apps integration workflows can easily be extended with custom code implemented as microservices on Azure Functions. In order to decouple in time these integration processes, we can leverage Service Bus Messaging services. And in case we need to expose our integration services as RESTful APIs, we might want to make use of all the features and capabilities of API Management. Additionally, these integration solutions can be enhanced by other Azure services, such as Cognitive Services to, for example get the sentiment from social media feeds or Azure Active Directory for authenticating and authorising calls to our APIs. All of this with all the PaaS magic and the powerful DevOps capabilities of Azure.

Thanks for reading, and please share your thoughts or queries on this topic below J

Happy clouding!

Cross-posted on Deloitte Engineering Blog Follow me on @pacodelacruz