Request/Response Integration Architecture with Azure Logic Apps

Summary

Creating a request/response integration is relatively simple with Azure Logic Apps. In this post I’ll demonstrate how to do exactly that.

Architecture

Azure Logic Apps will contain a single HTTP Request trigger that will function as the HTTP endpoint. On trigger of an HTTP POST request event, internal business logic will be carried out following with a Response to the original request.

Components

• Managed Trigger: HTTP Request
• Managed Action: HTTP Response

General Design

Security

Connections are managed through Managed Connectors. Connector details are stored in Azure Secure Storage.

Design Critique

Using Azure Logic Apps has many benefits; it’s a choreography tool designed to help rapidly deliver integrations. Connectors, Triggers and Actions are managed by Microsoft so there is no need to build these out independently. The benefits of using Azure Logic Apps is documented here:

Logic Apps can become large and complex. The editor experience isn’t as intuitive or user-friendly as code-editor. The option does exist to edit JSON data (Code behind) though this is merely swapping values or updating expressions.

Performance

Logic Apps is often compared to Azure Functions when performance is a concern. Azure Functions has been documented to be 300-400 milliseconds faster that Logic Apps, although implementation details do need to be considered. For the most part, performance may not be an issue when you are creating an event-driven architecture where the application does not need to be reactive e.g. an online form to capture a customers restaurant booking. A reactive application might be one where a service broker such as Azure Service Bus is used, e.g. an integrated systems where messages are sent bi-directional between applications.