Integration Monday Session-Blog-Interesting and new features in Azure Logic Apps-Part 1

Update [25-Feb-2016]: This blog post used Azure Logic Apps – Preview v1 for demos. The demo version using Logic Apps Preview Refresh which was released yesterday will be published for these demos.

This blog is about my Integration-Monday session on “Interesting and new features in Azure Logic Apps” (12-Oct-2015) ( where I showed demos on implementing the following in Azure Logic Apps:

  • Different way to chain/nested Logic Apps
  • Using Do-Until
  • Using C-Sharp API App

After Logic Apps has been previewed on 24-March-2015, I shared some of my first-hand experiences about Logic Apps in my first Integration-Monday session “Logic Apps – Sharing My Experiences” (18-May-2015) ( With the Azure Logic Apps team’s more community involved approach with their monthly Google Hangout sessions, the product team has been more transparent on the progress of the Logic Apps. So from the day of the preview and till date, community has been updated with the new features and product road map monthly. So in my second Integration-Monday session, I thought I would show some demos on some of the interesting and new features in Logic Apps.

I am writing this blog into two parts. In this first part of blog post, I am going to detail about the different way to chain/nested Logic Apps.

Different ways to chain/nested Azure Logic Apps – Preview v1:

Logic Apps allow us to automate the business process execution and workflow via an easy to use visual designer. This business process workflow can be simple or more complex in nature. In order to have better manageability, it’s recommended to have more modular, reusable Logic Apps. API Apps and Logic Apps are based on the principle of micro services architecture – discrete reusable component with HTTP/Rest endpoint which can be assembled together to form composite service. Following the same principle Logic Apps can be built with a modular approach and by chaining these modular Logic Apps we can achieve manageable composite business processes.

There are different ways to chain the Logic Apps together. In the session I showed demos to explain the same.

In the demos I used the terms like “Start”-Logic App and “Call”-Logic Apps, just to highlight the similarity in the concepts of chaining Logic Apps with its on-premise counterpart BizTalk server where modular orchestrations are chained. But technically the ways BizTalk’s Start/Call Orchestration shapes and the Logic Apps chaining shown, works differently.

Demo 1: Start a Logic App from another Logic App:

In this demo I showed a Logic App which validated the given XML file against the predefined schema. If the validation failed, it started another Exception handler Logic App – the child process, which emailed the error details to two different teams based on the Severity ID of the error message posted to this Logic App.

Start a Logic App from another Logic App

The high-level steps involved to achieve this:

  1. Create the Child Logic App. Enable this as manually triggered by ticking the “Run this logic manually” –because this logic app is triggered through an HTTP post from parent Logic App.
  2. Create the parent Logic App and use HTTP Post action to trigger the child Logic App.
  3. In the HTTP Post action, you have to give the URL for the child Logic App and HTTP header.
  4. The URL should be of format: https://{ChildLogicAppEndpointAddress}/run?api-version=2015-02-01-preview
  5. {“Content-Type”:”application/json”,”Authorization”:”Basic YourBase64EncodedAccessKeyWithUser”}
  6. The child Logic App’s end point address and access key can be retrieved from settings of the Child Logic App (Child Logic App à Settingsà Properties).

My session video shows how to do the above steps in detail.

Parent Messge Validator Logic App

Child Exception Handler Logic App

By this way chaining the Logic App, the child Exception handler Logic App is independent of the parent Logic App. The child Logic App can be any of your common process which you want to modularize. And parent Logic App could continue its process after post the message to the child Logic App, without waiting for the response from the Child Logic App. This is similar to using Start orchestration shape to chaining Orchestrations in BizTalk server where the flow of control in the parent orchestration could proceed beyond the invocation, without waiting for the invoked orchestration to finish its work.

Demo 2: Call a Logic App from another Logic App:

In second demo, I showed how a Logic App can send a request to a child Logic App and handle the response from the child Logic App in the parent Logic App.

I showed a Logic App which sent the message to another Logic App to verify the age of the received employee message. Child Logic app checked the age of the employee from the received message to minor or major and returned the status back the parent Logic App. Parent Logic App received the response from the child Logic App and dropped the response in an output folder. I could do further processing in the parent Logic app with the response received from the child Logic App.

In this demo I used HTTP Post API action to post a request message to the child process and in the child Logic App I used an HTTP Listener to receive the message posted to the child process.

Demo2 - Parent Logic App

Demo2 - Child Logic App

The difference between using the manual trigger in child/triggered Logic App in the first demo and using the HTTP Listener in child/triggered Logic App in the second demo is that

  • By using the HTTP Listener in the triggered Logic App, I am not calling the Logic App URL but actually I called the API App’s end point (HTTP Listener). But by using the manual trigger in the first demo, I called the end point of the child Logic App by passing the authorization headers.
  • Also with HTTP Listener, I have more control over returning the response (I returned my custom response) to the parent Logic App

Demo 3: Logic Apps chained together using Publish-subscribe pattern:

In my third demo, I showed loosely coupled way to chain Logic Apps. People from BizTalk background would have tried to implement things they could do in BizTalk with Logic Apps. As we know BizTalk at heart is based on publish-subscribe architecture. The publish-subscribe is facilitated in BizTalk using message-box database (BizTalkMsgBoxDb), where a published message can be processed/routed by Orchestrations/send port matching the subscription. Similar behavior can be implemented in Logic App with the help of a Service Bus Topics subscription. By this way you have multiple child/subscribing Logic Apps created with Azure Service Bus connector API App as its trigger.

The high-level steps involved to achieve this:

  1. Create Service Bus Topics with subscription in the old Azure portal –
  2. Create an instance of Azure Service Bus Connector and configure it with Service Bus Topics subscription
  3. Create a parent Logic App which uses Azure Service Bus Connector API App to publish the message
  4. Create a child Logic App which uses Azure Service Bus Connector API App as the trigger i.e this Logic App initiates its flow when a message is published to the Azure Service Bus which matches to the subscription.Demo3 - Parent Logic App Publisher

Demo3 - Child Logic App Subscriber

I’ll continue to detail the other demos I have shown in the second part of this blog series.

Comment (1)

Leave a Reply

Your email address will not be published. Required fields are marked *