In this blog article, we will take a look at the featured content from the second episode of Middleware Friday. In this episode, Kent Weare talks about Azure Logic Apps and Service Bus Peek Lock.
Service Bus Receive Modes
There are two Service Bus Receive Modes that are available –
- Service Bus Peek Lock (default)
- Receive and Delete
Service Bus Peek Lock
When operating in the Service Bus Peek Lock mode, the client sends a request to receive a message from Azure Service Bus. Once the client receives the message, it will send a request to complete the message. There will be two individual steps in the peek lock mode.
In order to avoid a poison message (message that cannot be processed), dead-letter semantics are required to move the message away from being processed. You use the Service Bus Peek Lock mode if you want more downstream message durability.
Receive and Delete
This is the base behavior of the BizTalk Service Bus Messaging Adapter. With this method, both the steps are combined into a single request, and this will reduce the number of overall operations and improve the message throughput. However, the performance gain comes at the risk of losing messages.
What is Dead Letter Queue?
Dead letter queue is a type of a secondary sub-queue provided by Service Bus Queues and Topic subscriptions. This does not need to be explicitly created and cannot be deleted or managed independent of the main entity. The purpose of dead letter queue is to hold messages that cannot be delivered to any receiver/cannot be processed. Messages can be removed from the dead letter queue and inspected.
Let’s now see a quick demo
Let’s get started by creating a blank Logic App. Follow the on screen instructions to create a Logic App by providing a name, selecting the Azure subscription, Resource Group and the location. Once your Logic App is created and deployed, you will see the Logic Apps designer with the list of common triggers and templates to help you get started with. For the purpose of this blog, two templates are of interest to us –
- Peek-lock receive a Service Bus Message and complete it
- Peek-lock receive a Service Bus Message with exception handling
Peek-lock receive a Service Bus Message and complete it
Let’s get started with the “Peek-lock receive a Service Bus Message and complete it” template. Click the template and then click ‘Use this template“.
You will be prompted to connect your Service Bus account with the Logic App. Enter your Service Bus connection name and click Create.
Upon successful creation of the Service Bus template, click Continue.
For this demo, we will have a connector that will connect to a queue in Service Bus called mf-peeklock. We will check for messages in the queue every 3 minutes.
Next, we will add a delay to make sure the peek-lock scenario is actually working fine or not. When a message is received in a queue in the peek-lock mode, what we are actually doing here is applying a lock on that message. When we create a queue, the default lock duration setting is configured to 1 minute. If the message is not completed in the specified time, the lock will be removed and the message will be made available to be picked by any other consumer. Therefore, we will set a delay of 20 seconds in the Logic App and then we will complete the message in the queue. We will also pass the Lock Token from the request message.
Finally, we will trigger an email notification.
The entire Logic App sequence will be as follows –
Next, let’s Save our Logic App and open Service Bus Explorer. We will connect to our queue and submit/receive some messages using Service Bus Explorer.
As soon as we submit the message, depending on the time interval defined in the first step of the Logic App, the trigger will be executed and the message will be received into the queue in peek-lock mode. Then the delay trigger will execute for the time duration specified (20 seconds).
After 20 seconds, the message will be completed in the queue and you will receive an email notification with the corresponding information.
Now, let’s look at our second Logic App template “Peek-lock receive a Service Bus Message with Exception Handling”
Peek-lock receive a Service Bus Message with Exception Handling
In the second example, we will take a look at the second Logic App template “Peek-lock receive a Service Bus Message with Exception Handling”. Let’s create a Logic App “MF_ServiceBusPeekLock_Exception“. The steps to create a Logic App remain the same.
Let’s get started with the “Peek-lock receive a Service Bus Message with Exception Handling” template. Click the template and then click ‘Use this template“.
You will be prompted to connect your Service Bus account with the Logic App. Enter your Service Bus connection name and click Create.
For this demo, we will have a connector that will connect to a queue in Service Bus called mf-peeklock. We will check for messages in the queue every 3 minutes.
Here, we make the logic a slightly interesting one. We will have a scope and within that call a very simple HTTP endpoint. The trick lies in the condition that we apply beneath the scope. We will have two conditions – either complete the message in the queue or dead-letter the message in a queue. The conditions will purely depend on whether the HTTP call is successful or not. If yes, we will complete the message in the queue; otherwise, we will move the message to the dead-letter queue.
The entire Logic App sequence will be as follows
Let’s Save our Logic App and open Service Bus Explorer. We will connect to our queue and submit/receive some messages using Service Bus Explorer.
As soon as we submit the message, depending on the time interval defined in the first step of the Logic App, the trigger will be executed. If the HTTP endpoint is a valid one, the message will be completed in the queue.
Now, let’s just tweak the endpoint to an invalid one and Save the Logic App. When we send a message from Service Bus Explorer, since the HTTP endpoint URL is an invalid one, the condition will fail and take the ‘then’ loop, and the message will be moved into the dead-letter queue.
Logic Apps – Exceptions
Now in the above example, you would have seen that if the HTTP endpoint was a valid one, then the Logic App took the first condition (to complete the message in a queue path). If the HTTP endpoint was an invalid one, the Logic App took the second condition and moved the message to the dead-letter queue. This is mainly because of the “runAfter” property of the Logic App to catch the failures. By default, all the actions that are added through the designer are set to runAfter the previous step if the previous step returned the “Succeeded” status.
If you can see the code view for both the conditions, you will see that in the first scenario the status returned was Succeeded but in the second scenario, the status returned was Failed.
DYK about Turbo360?
Turbo360 is a One Platform Operations, Monitoring and Alerting software for Microsoft Azure Service Bus. With Turbo360, you can set up monitoring on your Service Bus resources such as Queues, Topics, Relays, and Event Hubs and get notified when there is a threshold violation.
If you haven’t yet got started with Turbo360, we recommend you to get started with a free account.
Feedback
You can give your feedback about Middleware Friday episodes, any special topic of interest, or any guest speaker whom you would like to see at Middleware Friday. Simply tweet at @MiddlewareFri.
You can watch the Middleware Friday sessions here.
