Azure Service Bus Explorer Path
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 ModesThere are two Service Bus Receive Modes that are available –. Service Bus Peek Lock (default). Receive and DeleteService Bus Peek LockWhen 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 DeleteThis 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.
Anyway, first issue is what Connection and Path are. I created a Service Bus and I have my credential from Azure Portal. I copied Primary Connection String and Path is the name of my queue. If I run the project, I receive a lot of errors. I found this link on Azure Documentation for a simple trigger. The premium tier of Service Bus messaging provides all the messaging features of Azure Service Bus queues and topics with predictable, repeatable performance, higher throughput, and improved availability. The premium tier uses a dedicated resource allocation model to provide workload isolation and consistent performance. Azure Service Bus queues and topic subscriptions provide a secondary sub-queue, called a dead-letter queue (DLQ). The dead-letter queue does not need to be explicitly created and cannot be deleted or otherwise 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 demoLet’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.
Azure Service Bus Explorer Path Map
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 handlingPeek-lock receive a Service Bus Message and complete itLet’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.
Number sequence puzzles. 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 HandlingIn 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 “ MFServiceBusPeekLockException“. 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 followsLet’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 – ExceptionsNow 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 Serverless360?Serverless360 is a One Platform Operations, Monitoring and Alerting software for Microsoft Azure Service Bus. With Serverless360, you can set up 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 Serverless360, we recommend you to. FeedbackYou 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.You can watch the Middleware Friday sessions.
If you spot things that are incorrect, or if you don't understand what I mean, please drop a comment on the offending article and I will help you ASAP. You can e-mail me at joostvanschaik at outlook dot com or contact me via.If you find the information on this blog useful (and apparently some 600+ people per day do on average) please let me know as well, that encourages me to keep doing this. Or do tell others - that made me an MVP; who knows what more it might bring;-P And of course, if you really really like what you read,:-P.