AZ-204: Develop message-based solutions

Are you looking for a way to develop message based solutions using Azure services? Do you want to learn how to use Azure Service Bus, Azure Event Grid, and Azure Event Hubs to create reliable and scalable applications? If so, you are in the right place!

In this blog post, I will introduce you to the AZ-204 exam objectives related to message-based solutions and give you some tips and resources to prepare for this section of the exam. Let's get started!

Service Bus queues vs Storage queues

Azure offers two kinds of queue mechanisms for different scenarios: Service Bus queues and Storage queues.

You should use Service Bus queues when you want to:

• Receive messages without polling the queue (using long-polling receive operation with TCP-based protocols)
• Ensure first-in-first-out (FIFO) order of delivery (with Message Session)
• Detect duplicate messages automatically
• Handle parallel long-running streams
• Send messages that are larger than 64 KB but smaller than 256 KB

You should use Storage queues when you want to:

• Store more than 80 GB of messages in a queue
• Monitor the progress of processing a message in the queue
• Create server-side logs of all the transactions

Advanced features

Service Bus queues and Storage queues have some common features, such as the ability to store messages in a durable and scalable way, but they also have some differences in terms of advanced features.

Here is a cheat sheet that compares some of the key features of Service Bus queues and Storage queues:

Implement solutions that use Azure Service Bus

One of the topics covered in the AZ-204 exam is how to implement solutions that use Azure Service Bus.
Azure Service Bus is a fully managed enterprise integration message broker that enables you to connect, decouple, and coordinate communication between different applications and services.

In this section, I will show you how to create a Service Bus namespace, a queue, and a topic, and how to send and receive messages using the Azure portal and the .NET SDK.

Service Bus tiers

One of the key aspects of Azure Service Bus is the choice of service tiers. Each tier offers different features, performance, scalability, and pricing options.

In this section, we will compare the main differences between these tiers and help you choose the best one for your scenarios.

Key Concepts of Azure Service Bus

Azure Service Bus is a fully managed enterprise integration message broker that allows you to decouple applications and services. It supports a range of communication patterns such as queues, topics, subscriptions, and event hubs.

In this blog post, we will explore some of the key concepts of Azure Service Bus and how they can help you develop message-based solutions.

Queues

A queue is a data structure that allows one-to-one communication between a sender and a receiver. It follows the FIFO (first-in, first-out) principle, which means that the messages sent to the queue are retrieved in the same order by the receiver.

Each message can have up to 256 KB of data, and each queue can have up to 80 GB of data.

Queues are useful for scenarios where you need to ensure reliable and ordered delivery of messages, such as processing orders or invoices. You can also use queues to implement load balancing and temporal decoupling between the sender and the receiver.

Receive modes

A receive mode determines how a message is consumed from a queue or a subscription. Azure Service Bus supports two receive modes: PeekLock and ReceiveAndDelete.

• PeekLock: To retrieve a message from the queue or subscription without removing it, you can use this mode. The message stays locked for a certain time, so other receivers cannot access it.
  => This mode helps you ensure at-least-once delivery semantics, which means the message will reach the receiver at least once, but it might reach more than once if the receiver does not complete or abandon the message.
• ReceiveAndDelete: In this mode, the receiver retrieves a message from the queue or subscription and deletes it immediately.
  => This mode allows the implementtion of at-most-once delivery semantics, where a message is delivered at most once, but may be lost if the receiver fails to process it.

Topics and subscriptions

A topic is a publish/subscribe mechanism that enables one-to-many communication between a publisher and multiple subscribers. A publisher can send messages to a topic, and subscribers can receive messages from the topic based on their interest.

A topic can store up to 256 KB of data per message, and up to 80 GB of data per topic.

A subscription is a named entity that represents the interest of a subscriber. It receives a copy of every message sent to the topic, unless a filter is applied.

• A subscription can have its own receive mode, dead-letter queue, and expiration time.
• A topic can have up to 2000 subscriptions.

Topics and subscriptions are useful for scenarios where you need to broadcast messages to multiple receivers, such as sending notifications or alerts. You can also use topics and subscriptions to implement content-based routing and temporal decoupling between the publisher and the subscribers.

Topic filters and actions

A topic filter is an expression that evaluates the properties of a message and determines whether it should be delivered to a subscription or not. Azure Service Bus supports three types of filters: boolean filters, SQL filters, and correlation filters.

• Boolean filters: These are simple filters that evaluate to either true or false. A true filter allows all messages to pass through, while a false filter blocks all messages.
• SQL filters: These are filters that use a subset of SQL language to evaluate the properties and content of a message. A SQL filter can access the system properties (such as MessageId or Label) and the user-defined properties (such as Color or Priority) of a message. A SQL filter can also use logical operators (such as AND or ORISNULL or CONTAINS) to construct complex expressions.
• Correlation filters: These are filters that perform an exact match on one or more properties of a message. A correlation filter can access the system properties (such as MessageId or Label) and the user-defined properties (such as Color or Priority) of a message.
  A correlation filter can also access the CorrelationId property, which is used to correlate messages that belong to the same group or conversation.

A topic action is an expression that modifies the properties of a message before it is delivered to a subscription.

Topic filters and actions are useful for scenarios where you need to customize the delivery of messages based on their content or context, such as routing messages to different subscriptions based on their priority or adding a timestamp to each message.

Technical details

The following table summarizes some of the technical details of the key concepts of Azure Service Bus.

Conclusion

In this blog post, we have explored the differences and similarities between Service Bus queues and Storage queues, two types of message-based solutions that you can use to develop scalable and reliable applications on Azure.

We have also learned how to implement solutions that use Azure Service Bus, a fully managed enterprise integration message broker that offers advanced features such as sessions, dead-lettering, duplicate detection, and more.

We hope you have enjoyed this post and learned something new. If you want to learn more about AZ-204: Develop message-based solutions, you can check out the official Microsoft documentation and certification page.

If you are willing to pass the AZ-204 exam you can visit this article to start the learning path and get a 50% voucher : How to Get a 50% Discount on Microsoft Certification Exams

Thank you for reading!