Skip to main content

Service Bus Topic (Day 6 of 31)

List of all posts from this series:

Short Description 
Service Bus allow us to communicate between different endpoints using publish/subscribe messaging communication model. This allow us to have a communication one-to-many, a message will received by multiple endpoints.
This is possible using the concept of topics and subscriptions. A topic represent the entry point for our messages into Service Bus. Each topic can have one or more subscriptions attached to it. A message that will enter in the topic will be received by all subscriptions.
If we make an analogy with queues, we could say that each subscriptions, is a different queue and a message that is send to the topic will be duplicated to all subscriptions related to it. One or more topic can be part of a namespace.

Main Features 
Max subscription number
In this moment each topic can have maximum 2.000 subscriptions attached to it. This mean that a message that is received by a topic can be distributed to maximum 2.000 endpoints automatically.
Death Letter Queue
A queue where messages that were not consumed with success by subscribers or expired can be send automatically. Can be used with success when we need to make auditing and support actions. In this way we can detect messages that were not consumed.
Time To Live
We can specify what is the default TTL of each message. Once a message expire it will be removed from topic and added to Death Letter Queue. This can be specified at topic level and/or at subscription level.
Duplicate Detection History
Topics are smart enough to detect duplicate messages and reject them. We can specify the time interval for how a message will be tracked and can be considered duplicate. When this option is activated we should be aware that the history of messages will consume a part of our available space on our topic and can affect the available space.
Topic State
There are 3 states that a topic can have:

  • Enabled – Messages can be send to the topic and consumed by subscribers
  • Disable – Messages cannot be send or consumed from topic/subscribers
  • Send Disable – Messages cannot be send to topic, but subscribers can consume messages

Subscription State
There are 3 states that a subscription can have, similar with the one from topic:

  • Enabled – Messages can be send/received by subscription
  • Disable – Messages cannot be send/received by subscription
  • Receive Disable – Messages cannot be send to subscription, but clients can consume existing messages 

Access to Service Bus Topic can be made based on account key or using Shared Access Signature. When we use SAS we can specify for each token, what kind of actions can be made (Manage/Listen/Send).
Messages consumption
Messages can be consumed from subscription in two different way

  • PeekLock – Message is took from subscription but is not deleted. Client needs to send a confirmation that message was consumed with success. If this confirmation is not send and the lock duration expires, the message will be available once again in the subscription. Remarks: When using this mechanism take into account that you will do two different transactions (Peek and Confirm) – this can increase the costs at the end of the month.
  • ReceiveAndDelete – Message is received by client and automatically deleted. If an error occurs on the client side, the message cannot be retrieved any more. 

Lock Duration
For each subscription we can specify the lock duration when messages are consumed using peek mode pattern.
Max Delivery Count
We can specify how many times client can try to consume the same message from subscription. If this number of delivery count is exceeded the message is removed from subscription and will be send to death letter queue.
Messages that are send to topic can be part of the session. When consumer are starting to consume messages from a session they will receive all the messages from a specific session in the same order.
There is the ability to send or consume messages in batches. The maximum size of a batch is  100 messages. Can be used with success when we want to optimize the number or request that send over the wire.
Message Property
Each message that is added to Service Bus Topics needs to be of type (format) of MessageBroker. A message broker can have not only a body (the data that we want to send), but also a list of properties. This properties represent the meta-data of a message and can be specified by clients.
We can specify filter at each subscription level. This filters can analyze look inside message property and accept message on that specific subscription based on the message properties (simple SQL filters -SQLFilter)
At subscription level we can also specify simple action that can change message property. For example we can change the value of a property based on other properties, increment them or create new properties (SQL Actions).
Deferred message processing
This feature enables receivers to "shelve" a message and retrieve it later by using a message unique ID
Message Size
The maximum size of a message can be 256kb.
Topic Size
The size of the topic can range from 1GB to 5GB.
Message delivery
Each message that is received by a Topic is guaranteed that will not be lost by system and will reach the final destination.
Subscription-Topic interconnection
You can connect a subscription to another topic from the same namespace. The message will be automatically forward from the subscription to topic.

Topic Size
This is a limit that can hearth you when you need to work with a lot of messages. In this cases you should look at Event Hub, it may be a better solution for your use case.
Subscription numbers
2.000 is a big number, but there are use cases when you would like more than 2.000 subscriptions. In this cases you should split your load on multiple topics based on different data like region or ID.

Applicable Use Cases 
Below you can find 4 use cases when Service Bus Topic can be used with success:
Send Commands to Devices
Service Bus Topic can be used when we need a reliable channel to send commands to different devices from field. Using it we will be sure that commands will be received by devices and when we need to execute multiple steps we can use session features with success.
Communication between different components
It can be used with success to connect multiple components. All the communication can be made in a reliable and scalable way. If one of the components is down, messages will not be lost and will be stored until the components is up and running again.
Distribute message to multiple components
Service Bus Topic can be used when we need to distribute content to multiple components in a simple and reliable way. We don’t need to care anymore about how we store content, distribute and so on.
Home Automation
In home automation, Service Bus can be the connection bridge between our backend and devices. It is an out of the box solution that is scalable and safe. We can even create a new topic for each different client and each subscription can be represented by a device from client home.

Code Sample 
// Create namespace
TokenProvider credentials = TokenProvider.CreateSharedSecretTokenProvider(IssuerName, IssuerKey);
NamespaceManager namespaceClient = new namespaceManager(ServiceBusEnvironment.CreateServiceUri("radusb", ServiceNamespace, string.Empty), credentials);

// Create topic description
TopicDescription rvTopicDesc = namespaceClient.CreateTopic("raduvunvuleatopic");

// Create subscription description
SubscriptionDescription acSubscription = namespaceClient.CreateSubscription(rvTopicDesc.Path, "ac");
SubscriptionDescription doorSubscription = namespaceClient.CreateSubscription(rvTopicDesc.Path, "door");

// Create topic
MessagingFactory factory = MessagingFactory.Create([serviceUrl], credentials);
TopicClient rvTopicClient = factory.CreateTopicClient(rvTopicDesc.Path)

// Send message
BrokeredMessage message = BrokeredMessage();

// Consume messages from a subscription
SubscriptionClient acSubscription = factory.CreateSubscriptionClient("radusb", "ac", ReceiveMode.PeekLock);
BrokeredMessage message = null;
while ((message = acSubscription.Receive(TimeSpan.FromSeconds(30))) != null)

Pros and Cons 

  • Very scalable
  • Robust
  • Fast
  • A lot of management features


  • Size of the topic not very big

When you calculate the costs you need to take into account:
  • Number of operations (each action that is done on topic/subscription is an operation)
  • Outbound traffic

Service Bus Topic is a reliable messaging system that can be used with success in many scenarios. This a mature and robust service that has a lot of nice and useful features.


Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.