Example 4 – Session Management with Logic Apps and Service Bus

When working with Logic Apps as a distributed integration platform, we sometimes need to maintain the order in which messages are received. In integration terms, we call this pattern a sequential convoy.

In this exercise, we will go through the process of creating integration solutions with Azure Logic Apps and Service Bus to get a sequential flow of messages. We will use the session ID property of Service Bus with the Logic Apps Service Bus connector to route the messages to the backend system in the same order as they are received from the client application:

 

To illustrate this example, we will again take an example of a social media platform in which we are required to build a sequential pattern on a specific posts and comments made by multiple users within a specified time interval:

  1. The first step here is to create a Service Bus topic and subscription in the Service Bus namespace resource when creating a subscription for the topic-enabled sessions property, as shown in the following screenshot:

  1. In the next step, we will create a Logic Apps instance that will poll the Service Bus topic at regular intervals of time.
  2. As depicted in the next workflow, Logic Apps will get the first message from the Service Bus topic through a subscription filter and insert it into CosmosDB.
  1. In the next set of actions, Logic Apps will use do-until actions to get all the messages from the Service Bus with the same session ID, as shown in the following process flow screenshot:

  1. In this example, we have used a variable of integer type and initialized it with a value of 0. In the do-until loop, we will get the Service Bus message through Logic Apps' built-in connector and write each message to CosmosDB.
  2. The loop process will run until all messages with the same session ID are retrieved and the variable count reaches 5.  
There are a few things to keep in mind while working with session management in Logic Apps. These include choosing the right topic name and subscription associated with the topic and changing the session ID from the default value, None, to Next Available, as shown in the following screenshot:

  1. To verify that all messages with the same session ID have been picked up by the Logic Apps instance, we can use the length function available in Logic Apps. This length function will perform a conditional check based on the topic depth. You can write following the conceptional statement in the Logic Apps workflow definition:

  1. Next, we create a publisher logic app that will post messages to a Service Bus topic with the session ID and the related content. Here, we have used a social media website and used the original post ID as the session ID. The associated comments will have the same session ID but different content. The workflow definition of the Logic Apps message sender is shown in the following Logic Apps workflow:

  1. In this case, we have to use Postman to invoke the sender logic app's endpoint with the initial post and the related comments with the same session ID and a different request body. The comments will have their own unique identifier for CosmosDB, along with the session information. The overall execution of Logic Apps run is as follows: 

In this exercise, we have worked through session management and an ordered delivery process for Logic Apps. This pattern is useful when you need to maintain order or you need to work through batch processing using a Service Bus and Logic Apps workflow. 

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.138.102.114