Book Image

Enterprise Integration with Azure Logic Apps

By : Matthew Bennett
Book Image

Enterprise Integration with Azure Logic Apps

By: Matthew Bennett

Overview of this book

Logic Apps are a visual flowchart-like representation of common programming actions, and are a flexible way to create logic without writing a single line of code. Enterprise Integration with Azure Logic Apps is a comprehensive introduction for anyone new to Logic Apps which will boost your learning skills and allow you to create rich, complex, structured, and reusable logic with instant results. You'll begin by discovering how to navigate the Azure portal and understand how your objects can be zoned to a specific environment by using resource groups. Complete with hands-on tutorials, projects, and self-assessment questions, this easy-to-follow guide will teach you the benefits and foundations of Logic App logic design. As you advance, you'll find out how to manage your Azure environment in relation to Logic Apps and how to create elegant and reliable Logic Apps. With useful and practical explanations of how to get the most out of Logic App actions and triggers, you'll be able to ensure that your Logic Apps work efficiently and provide seamless integration for real-world scenarios without having to write code. By the end of this Logic Apps book, you'll be able to create complex and powerful Logic Apps within minutes, integrating large amounts of data on demand, enhancing your systems, and linking applications to improve user experience.
Table of Contents (17 chapters)
1
Section 1: Logic App Fundamentals
7
Section 2: Logic App Design
13
Section 3: Logic App Maintenance and Management

Summary

This has been a short but concise chapter that has explained how to communicate between logic apps. We looked at the idea of an orchestrator – a central gateway in which you can receive messages and then reroute them for further processing. We considered how the parent and child logic apps communicate and looked at the traditional logic app action step as opposed to an HTTP action step. We then considered using a SQL table to index the audit actions in our message from our legacy system. We can then use this table to determine which logic app the message needs to be passed to.

After, we refined the HTTP POST action from the initial HTTP action step, which was very much like the one-way fire and forget principle and compared this to the request/response actions. These work as a pair that receives an HTTP message and processes it within the logic app. At the end of the logic app, we send a message containing the output back to the parent logic app for further processing...