Service Bus Topic Filters Basics

Introduction

Azure Service Bus Topic supports multiple Subscribers for a single Publisher. Messages sent to a Service Bus Topic can be received from its Subscription created under the Topic. Subscribers can define which messages they want to receive from a topic. These messages are specified in the form of one or more named subscription rules. Each rule consists of a condition that selects particular messages and an action that annotates the selected message. For each matching rule condition, the subscription produces a copy of the message.

Default Service Bus Topic Subscription Behavior

Each newly created topic subscription has an initial default subscription rule. If you don’t explicitly specify a filter condition for the rule, the applied filter is the true filter that enables all messages to be selected into the subscription.

Types of Topic Subscription Filters

Three different types of conditions can be provided in the Filter.

Boolean Filter

The True Filter selects all the arriving messages to the subscription where the False Filter selects none of the arriving messages

SQL Filter

A SQL Filter has a SQL – Like conditional expression that is evaluated in the broker on the arriving messages’ system and user-defined properties. It tests for the existence of certain properties using EXISTS, null-values by IS NULL and plain text matching with LIKE.

Correlation Filter

The correlation filter is usually matched against the Correlation Id property of the arriving messages. It has a set of conditions that can be matched with more than one arriving messages with user or system properties. A match is said to exist when the value of the arriving messages’ property is equal to the value specified in the correlation filter.

Why to Use Service Bus Topic Subscription Rules

For real-time, multi-tenant application, the messaging scenarios with multiple subscribers would require filtering.

Though Service Bus Topics support multiple subscribers, the main reason for the users to switch to Topics instead of Queues would be the filters.

Setting up rules for the Subscriptions reduce considerable manual effort in handling the messages in real-time.

In terms of expense, using Topic Subscriptions with appropriate filters will reduce the cost when compared to Subscriptions without any rules and filtering handled in run time.

Consider an A single Sender and Multiple Receivers who want to receive only the Specific Messages based on certain Rules and Filters. Each Subscription represents a receiver like an Akeneo Cloudinary, ESL, etc.  If the rules are not configured for each subscription, it accepts all the messages (messages related to other Receivers will be received in some other Subscription). The downstream application should receive the messages and check if it belongs to the current Receiver (Subscriber). This will result in performance issues as well as an increase in the expense, as the pricing is based on the message flow. Another important problem in manual filtering is, if the message contains sensitive information, it results in security issues.

Having appropriate filters for each Subscription will result in better performing, more secure and cost-effective solution.

Topic Subscriptions without filters is like multiple Queues which would attract manual intervention to handle the messages.

Summary

Service Bus offers multiple Messaging options. When used wisely they save lot of manual efforts and expense spent towards using these services. There are people still using the Topics without Rules, things may work for them, but using the Rules will make it efficient.