Skip Navigation LinksAzure Developers Guide > Azure Service Bus > Brokered Messaging > Brokered Messaging Features & Patterns > Message Correlation > Correlation in Service Bus Brokered Messaging

Training Courses

All course material is in English, and courses are delivered in English. Feel free to contact me for further information. cloudcasts.net@gmail.com

Correlation in Service Bus Brokered Messaging

There are a number of different ways of implementing correlation in Service Bus brokered messaging. The BrokeredMessage class provides properties that can be used as correlation identifiers, Queues and Subscriptions can require that messages are sent as sessions using a session identifier, and the MessageSession class can be used to receive a group of related messages from a queue or subscription.

SessionId Message Property

SessionId is the most common message property to use as a correlation identifier. When sending a sequence of messages to aggregate the sending application will set the SessionId of the messages to the same value. The application receiving the messages will then use an instance of the MessageSession class to receive all messages with the same SessionId from the queue or subscription.

When implementing the request-reply pattern the sending application can set a correlation identifier in the ReplyToSessionId property of the request message. The application that receives this request message can then create a response message and set the SessionId property of the response message to the value of the correlation identifier. The application that sent the request message can then use an instance of the MessageSession class to receive the response message with the appropriate correlation identifier.

In the first scenario the use of the SessionId property as a correlation identifier for aggregating messages is intuitive, as a sequence of related messages are being sent in a message session. In the request-reply scenario the response message “session” will typically only contain one response message making the use of the SessionId property seem like a strange choice. The reason for using the SessionId property is that the MessageSession class provides the required functionality to dequeue the response messages based on a specific SessionId value rather than a CorrelationId value.

CorrelationId Message Property

The CorrelationId message property can be used when creating filter expressions in subscription rules when subscribing to messages in topics. When using simple filter expressions like “priority = 'High'” it can be more efficient to set the CorrelationId property of a message to High and use a CorrelationFilter in the subscription rule. This is discussed earlier in the Using Topics and Subscriptions section.

The use of SessionId and CorrelationId when correlating messages may not seem initiative, especially to BizTalk developers. Try to remember that the SessionId property is used for correlation and the CorrelationId property is used for routing!

ReplyTo Message Property

The ReplyTo message property can be used to specify the name of a queue to send a message to as the response of a request-response operation. The application that sends the request message can set this property so that the receiving application knows the queue to send the response message to.

As this property is not used internally by the Service Bus it could be used in other ways, such as specifying an email address to send confirmation of the receipt of an order message.

ReplyToSessionId Message Property

The ReplyToSessionId message property is used when correlating messages when using the request-reply messaging pattern. The application sending the request message sets the ReplyToSessionId property of the message with a value for correlation identification. The application sending the response message will use this value to set the SessionId property of the response message.

MessageSession Class

The MessageSession class is very similar to the MessageReceiver and is used to receive sessions of messages from queues or subscriptions. Instances of MessagesSessions are created internally by the queue client class using the AcceptMessageSession method. This method can be called with or without specifying a value for SessionId.

// Accept the first available MessageSession on the queue.

MessageSession session = responseQueueClient.AcceptMessageSession ();

 

// Accept a MessageSession with a specific correlation identifier.

MessageSession session = responseQueueClient.AcceptMessageSession(sessionId);

 

 

The use of the MessageSession class will be discussed in detail in the next few sections.

RequiresSession Queue and Subscription Properties

Queues and subscriptions can be configured to require that all messages have a valid value set for the SessionId property. If RequiresSession is set to true, sessions must be used, if set to false sessions cannot be used.

Attempting to send a message with a value set for the SessionId property to a queue with RequiresSession set to false will result in the following exception being thrown.

InvalidOperationException

 

A sessionful message receiver cannot be created on an entity that does not require sessions. Ensure RequiresSession is set to true when creating a Queue or Subscription to enable sessionful behavior.

 

Attempting to send a message without a value for SessionId to a queue that requires sessions will result in the following.

InvalidOperationException

 

The SessionId was not set on a message, and it cannot be sent to the entity. Entities that have session support enabled can only receive messages that have the SessionId set to a valid value.

 

If sessions are required on a queue it is not possible to use the QueueClient Receive method to dequeue messages. Attempting to do so will result in.

InvalidOperationException

 

It is not possible for an entity that requires sessions to create a non-sessionful message receiver.

 

 

 

Speaking Engagements