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

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

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 …

[Post-Event] Codecamp Conference Cluj-Napoca - Nov 19, 2016

Last day I was invited to another Codecamp Conference, that took place in Cluj-Napoca. Like other Codecamp Conferences, the event was very big, with more than 1.000 participants and 70 sessions. There were 10 tracks in parallel, so it was pretty hard to decide at  what session you want to join.
It was great to join this conference and I hope that you discovered something new during the conference.
At this event I talked about Azure IoT Hub and how we can use it to connect devices from the field. I had a lot of demos using Raspberry PI 3 and Simplelink SensorTag. Most of the samples were written in C++ and Node.JS and people were impressed that even if we are using Microsoft technologies, we are not limited to C# and .NET. World and Microsoft are changing so fast. Just looking and Azure IoT Hub and new features that were launched and I'm pressed (Jobs, Methods, Device Twin).
On backend my demos covered Stream Analytics, Event Hub, Azure Object Storage and DocumentDB.

What abo…