Azure service bus best practises

Introduction to Azure service bus

Azure Service Bus is a cloud-based messaging service that enables reliable, asynchronous communication between applications and services. It is a scalable, flexible, and robust messaging infrastructure that provides a wide range of messaging capabilities, including publish/subscribe, message queuing, and request/response messaging. It also offers advanced features like dead-lettering, message batching, and message deferral.

Azure Service Bus Best practices

In this article, we will discuss some best practices for using Azure Service Bus, including naming conventions, choosing between queues and topics, resource grouping, selecting the right service tier, using the claim check pattern, lock handling, and session usage.

Naming Conventions for Azure service bus

Using a consistent naming convention for Azure Service Bus entities is essential for efficient management and maintenance of the messaging infrastructure. A recommended naming convention is to use a descriptive name that reflects the purpose and nature of the entity. Consider including information such as the environment (e.g. dev, test, prod), the type of resource (e.g. queue, topic), and the application or service name. For example, a queue named “sbq-orders-processing-dev” indicates that it’s a queue for processing orders in the development environment.

Azure service bus queue vs topic

Azure Service Bus provides two types of messaging entities: queues and topics. Queues are used for point-to-point messaging, where messages are sent to a single receiver. Topics are used for publish/subscribe messaging, where messages are sent to multiple subscribers. The choice of using a queue or a topic depends on the messaging pattern required by the application. If the application needs to send messages to a single receiver, use a queue. If the application needs to send messages to multiple subscribers, use a topic.

Number of Service Bus Instances

Azure Service Bus can be created per resource group or per common resource group. The decision to use either approach depends on the requirements of the application. If the application requires a single messaging infrastructure that is used by multiple applications and services, it is recommended to use a common resource group. If the messaging infrastructure is used by a single application or service, it is recommended to create a resource group for that application or service.

Azure service bus plan

Azure Service Bus Premium vs. Standard: Azure Service Bus provides two service tiers: Standard and Premium. The choice of service tier depends on the messaging requirements of the application. Standard provides a cost-effective messaging infrastructure for basic messaging scenarios. Premium provides advanced messaging capabilities such as high-throughput messaging, message ordering, and message sessions.

Handling large messages in azure service bus

Azure Service Bus has a default maximum message size of 256 KB. When the message size is bigger, then use Claim Check Pattern. The claim check pattern is a messaging pattern used to reduce the size of messages sent over Azure Service Bus. This pattern is used when the size of the message exceeds the maximum size allowed by the messaging infrastructure. The claim check pattern involves sending a small message containing a reference to the larger message stored in another location. This pattern reduces the size of messages sent over Azure Service Bus and improves the performance of the messaging infrastructure.

Handling service bus message locks

Azure Service Bus provides two lock handling modes: Peek Lock and Auto Complete. The Peek Lock mode locks the message for processing and allows the application to peek at the message content without completing the processing. The message is not deleted until the application completes processing or releases the lock. The Auto Complete mode automatically completes the processing of the message and deletes it from the queue or topic. Below is the peek lock message handling.

Using sessions in azure service bus

When to use sessions: Azure Service Bus provides support for message sessions, which enable a group of related messages to be processed together in a specific order. Message sessions are useful when processing related messages in a specific order that is critical to the application. For instance, processing orders and payments related to a specific customer can be grouped into a message session.

Use dead-lettering for handling errors

Azure Service Bus provides a dead-letter queue that can be used to handle messages that cannot be delivered to their destination. When a message fails to be delivered after a certain number of retries, it is moved to the dead-letter queue. You can then investigate the cause of the error and take appropriate action. This can be useful in scenarios where you need to handle errors and exceptions in a graceful manner.

Secure Azure service bus

Azure Service Bus provides various security measures, such as Shared Access Signatures (SAS) and Azure Active Directory (AAD) authentication. It is recommended to use appropriate security measures to protect your messages and ensure the privacy and integrity of your data. If it is possible, use managed identity.

Duplicate detection using Azure service bus

Duplicate detection in Azure Service Bus helps prevent duplicate messages from being processed by the receiver, which can lead to data inconsistencies, errors, and unnecessary resource consumption. Implementing duplicate detection in Azure Service Bus is a simple but effective way to ensure data consistency and prevent resource waste. To prevent duplicates from being processed, Azure Service Bus provides a feature called “Duplicate Detection.” This feature can be enabled by setting the RequiresDuplicateDetection property to true when creating the Queue or Topic. Once enabled, Service Bus will keep track of the MessageId of all messages received in the past X-time frame (e.g. 24 hours) and prevent duplicates from being processed.

Monitoring and Logging Azure service bus

Monitoring and logging are essential for identifying and resolving issues in your Service Bus.
Monitor your Service Bus: Use Azure Monitor to track your Service Bus metrics and set up alerts for important events.
Use diagnostics logging: Enable diagnostics logging to collect detailed information about your Service Bus operations

Conclusion

Azure Service Bus is a powerful messaging service that provides a variety of messaging patterns and advanced features. By following the best practices discussed in this blog, you can build scalable, reliable, and secure cloud applications using Azure Service Bus.

• D365 FO introduces New user-based service protection API limits
• D365 FO: Priority based throttling for integrations
• Monitoring and alerting for Azure Key Vault
• D365 FO: Set financial dimension value using oData
• Azure Integration using Managed Identity
• D365 Finance and Operations integration using BYOD
• Azure Service Bus and Logic App integration Pattern using PeekLock
• Generate a Flat file with ANSI encoding using Logic App
• D365 FO DMF Data Export using Logic Apps