Azure Service Bus is a raw messaging platform, there is no user interface to explore and visualize the features in action (apart from the basic interface provided by Azure Portal). Often times a simple property setting will have a huge functionality enabled, which otherwise would have required substantial engineering investment from end users. There are a lot of those hidden gems in Azure Service Bus, let’s take a look at some of the important ones and try to understand the format
- “What” – What is this feature about?
- “When” – When will you need this feature?
- “How” – How do you enable this feature in Azure Service Bus?
- “Example use case” – We will cover a practical example use case for the feature.
Free download this blog as a PDF document for offline read.
What: Ignore messages that are sent more than once in a specified time window
When: Upstream applications are unpredictable and noisy. They may send duplicate messages
How: At the Queue/Topic level you set the “Duplicate Detection History Time Window” property (example: 10 minutes) and when you are sending the message you set the MessageId property to desired value that can identify the message, example OrderNumber
Example use case: A simple example will be barcode scanning in supermarkets, with all the new self-service check-in kiosks it’s very easy for end user to scan the same items more than once.
What: place a message in a queue or topic that doesn’t “appear” until a specified future time
When: Sender wants to send something now, but doesn’t want an action to take place on it until later. Take actions to complete or rollback work at a specified point
How: When sending the messages you simply set the ScheduledEnqueueTimeUtc (on BrokeredMessage) to desired UTC time. The messages will not be available until the time is elapsed
Example use case: You process a monthly employee payroll, throughout the month various underlying system send the messages to the queue that should only be processed on the last working day of the month.
What: Mark a message to be skipped so it doesn’t keep getting read off a queue or topic
When: Whenever you can’t process something immediately, but must process it later
How: Call BrokeredMessage.Defer method
Example use case: This is kind of an advanced feature, we take advantage of this feature within Serverless360 for dead letter message resubmission. We wanted to build a reliable way for message resubmission in Serverless360. The standard way of retrieving messages using “Receive and Delete” operation then resubmit the message might result in message loss if we cannot resubmit the message successfully. Hence, we “Defer” the messages first, store the sequence number, resubmit them and after successful resubmission, we Delete the messages using the SequenceNumber.
Note: You need to be super careful while using this functionality, if you lose the SequenceNumber of the message then there is no way to get that message.
What: Forward all messages to another entity
When: If current senders have an address you don’t want to use anymore – or if you want more fine-grained security
How: Set the ForwardTo property on the Queue or the Subscription (for a topic)
Example use case: There are a lot of underlying external systems send messages to a particular queue, where you do not have the control or option to ask them to change the queue name. In this case, you can leave the existing queue as it is and simply forward the messages to new queue or topic.
Auto Forward (Dead Lettered Messages)
Dead lettering with Auto forward
What: Send dead letter messages to another entity (queue/topic)
When: You want more control over where non-deliverable messages go
How: Use the ForwardDeadLetteredMessagesTo property on Queue or Topic
Example use case: You can forward the dead letter messages to a topic and have a rich exception handling. There is another hidden property called DeadLetterSource which will provide you the source queue name, especially useful if you are planning to have a central exception handling “Azure Service Bus Topic” and create some subscription rules based on the source queue name.
Auto Delete on Idle
What: Delete entities that do not have a Send operation called for a certain amount of time
When: You need to create entities for specific flows or scenarios that are transient in nature and don’t want to clean them up
How: At the Queue/Topic level specify a timespan for AutoDeleteOnIdle property
Example use case: You are working with large volume of temporary external contractors who send messages, due to the nature of the business after 1 week they will wear out and the queues/topics are no longer required.
Note: All the above screenshots are taken from Serverless360, we wanted to create a world-class operations and monitoring solution for Azure Service Bus and make the platform super powerful for the end users. If you have invested in Azure Service Bus, sign up for Serverless360 free account and get started.