Skip to main content

Patterns in Windows Azure Service Bus - Message Aggregator Pattern

In the last post I talked about Message Filter Pattern that can be used on Windows Azure Service Bus. Today I will describe how we can use Message Aggregator Pattern. From some points of view, this pattern is the opposite pattern in comparison with Message Splitter Pattern.
Do you remember when Message Splitter Pattern can be used?… when we want to split messages based on some rules. Message Splitter Pattern does the opposite thing. This pattern can be used when we want to aggregate different messages.
This pattern can be used with success in cases when we send some information in more messages. For example if send GPS position of cars based on the type. Until the car will reach the destination it will send a lot of messages. We will need to mark with a custom property the last message that is send by the cars of a given type – or to define a timeout period. When the last message will be received we will be able to process the data – for example to calculate the total distance and the speed of the car.
Using Windows Azure Service Bus we have two possibilities to implement this pattern. The first one is to use sessions. I already described a solution based on session in the following post:
This is not the only way to implement this pattern. If we are using Windows Azure Service Bus Topic we can use with success CorrelationFilterExpression.
Why to use CorrelationFilterExpression and not session? Because usually this pattern is used when we work with a lot of messages that need to be aggregate. The correlation id is stored in a hash table and the matching is faster. In comparison, the session id comparison is not hashed and is not optimized for 1 to 1 match – we only compare two strings using a SQL expression filter. From this perspective, using CorrelationFilterExpression is better.
Let’s see how we can use CorrelationFilterExpression to make our life easier. For this solution we will need to use Service Bus Topics. On the client side we will need to set the correlation id. Every BrokeredMessage has a property named “CorrelationId” that can be set to our specific value.
BrokeredMessage message = new BrokeredMessage();
Remember one thing and this is very important when we want to use the CorrelationFilterExpression. We specify the correlation id in the moment when we create the subscription, through the rule that we are creating. Because of this a subscription will be only for one correlation id. This is the cause why the session id is preferred when we don’t have many messages from the same “group” (session). If you remember the example with the cars and GPS location we will have a lot of messages from different cars type that will be grouped based on the car type. In our case this will represent the correlation id. This id can be any string, we are not limited to a int or some values.
     new CorrelationFilterExpression(“sedan”));
This is the only thing that we need to do from the configuration perspective. Usually there is not a problem with the subscription that is “glued” to a specific correlation id because from this perspective, the ids should not change in time. Also there will be a constant flow of messages.
As a conclusion let’s see when we can use Messaging Aggregation Pattern. We can use it when we need to aggregate messages based on a specific flag. From the performance perspective it is recommended to use the CorrelationFilterExpression that hash the id that is specified.
Last edit: A list of all patterns that can be used with Windows Azure Service Bus, that were described by me LINK.  


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.