Skip to main content

Service Bus Topics - How to use it (part 1)

In the last post we saw find out what is a Service Bus Topics. Next step that we should to do is to see how we can use it. From a lot of perspective, it is similar to Service Bus Queues.
The first thing that we need here is a Service Namespace. This is a unique named used to identify or service. The same namespace can be used for Service Bus Topics and Service Bus Queue without any kind of problems. To create a new namespace from the Azure portal, we should go Service Bus section. From there we have the possibility to create a new namespace. After the namespace is created we should be able to access it and see in the properties list the “Default Issuer” and “Default Key”. This information is needed to be able to consume and access a Service Bus Topics.
After we have the namespace created we need to configure the application to be able to access these services. In an application, this information can be stored in different locations, depending on our needs and preferences. The simplest one is to hardcode this value in our application, but is not the best one. If we create a website we can use configuration file of our web application to store this information.
<configuration>
    <appSettings>
        <add
                key="ServiceBusConnectionString"
value="Endpoint=sb://myFooNamespace.servicebus.windows.net/;SharedSecretIssuer=myFooIssuerName;SharedSecretValue=myFooDefaultKey" />
    </appSettings>
</configuration>
In the case you are working with a web-role or with a worker role, a good idea is to save this information in the service definition file (*.csdef and *.cscfg).
<WebRole name="FooWebRole" vmsize="Medium">
        <ConfigurationSettings>
            <Setting name="ServiceBusConnectionString" />
        </ConfigurationSettings>
</WebRole>

<Role name="FooWebRole"
        <ConfigurationSettings>
            <Setting name="ServiceBusConnectionString"
                     value=="Endpoint=sb://myFooNamespace.servicebus.windows.net/;SharedSecretIssuer=myFooIssuerName;SharedSecretValue=myFooDefaultKey"  />
        </ConfigurationSettings>
</Role>
Another possible solution is to store this information in a separately file, that can be consume by our application. In this case when we will create the instance of Service Bus Topics we will need to be able to specify this data. Basically, this information can be stored in any location from our application. We can even hardcoded this in our code – but please, don’t do this.
Remarks: If you read the posts about Service Bus Queues, you will notify that this configuration is the same. This happens because the entry point for Topics and Queues in Windows Azure are represented by the same “service”.
For creating a topic we have two options. We can create one from portal. We need to go to the portal, select our namespace from Service Bus and we will see that we have a new button there that permits us to create a new topic (or queue). It is not very insetting in this way. The other option is to create it from code.
From code, first of all we need to create a new instance of NamespaceManager. Yes, the same NamespaceManager that we used for Service Bus Queues. After this, we can create the Topic directly or check if it exists.
var namespaceManager =
    NamespaceManager
        .CreateFromConnectionString(CloudConfigurationManager.GetSetting("ServiceBusConnectionString"));

if (!namespaceManager.TopicExists("myFooTopic"))
{
    namespaceManager.CreateTopic("myFooTopic");
}
We should check if the topic already exists. Otherwise, a MessagingEntityAlreadyExistsException exception will be throwed by the service. Also, the name of the topic should respect the following rules:
  • Character that are accepted are: ‘a’-‘z’, ’A’-‘Z’, ‘-‘, ‘.’, ‘0’-‘9’
  • It should start with a character
If we want to specify some custom property to the topic, for example the TTL of the messages or the size of the topic, this can be done in the moment when we create the topic using TopicDescription.
TopicDescription topicDescription = new TopicDescription("myFooTopic")
{
    DefaultMessageTimeToLive = new TimeSpan(0, 1, 0)
};
...
namespaceManager.CreateTopic(topicDescription);
Creating a topic is quite simple. Creating a message for a topic is simple as well. We need to create a BrokeredMessage and send to the topic (yes, the same BrokeredMessage class that is used in Service Bus Queues – pretty cool). To handle a topic, we need to create a new instance of TopicClient.
TopicClient topicClient = TopicClient.CreateFromConnectionString(
    CloudConfigurationManager.GetSetting("ServiceBusConnectionString"),
    "myFooTopic");
BrokeredMessage message = new BrokeredMessage();
message.Properties["myCustomProperty"] = 1234;
topicClient.Send(message);
Receiving messages from Topics, is also simple, but before this we should talk about subscriptions and filters. This will be done tomorrow in more details.
In conclusion we saw how we can create namespace, Service Bus Topics and how we can send messages to these topics. Keep in mind that a message that is added to a topic is simple a BrokeredMessage.
Part 2

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP