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

Training Courses

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

Message Correlation

In messaging systems it is often a requirement to group together, or correlate, messages that are related to one another. Messages can be assigned a specific property, usually known as a correlation identifier, which is set to the same value in all related messages.

When sending and receiving emails we use the email subject as a loose form of correlation identifier. We send an email message with a subject of “Help!”, and hopefully receive responses with a subject of “Re: Help!”.

In BizTalk Server correlation sets are initialized and followed when correlating messages in orchestrations. Every BizTalk developer knows that you must specify at least one already-initialized correlation set for a non-activation receive that is on a non-selfcorrelating port.

The Enterprise Integration Patterns website provides a description of the Correlation Identifier pattern here.


There are two common scenarios where correlation is used in messaging systems. The first one is when implementing a request-reply messaging pattern using asynchronous queues. As queues only support one-way messaging there is a need for the sender of the request messages to correlate the response messages to the appropriate requests. The sender can send Request1, then Request2 and then Request3 and receive Response2, then Response3, and then Response1. There are also likely to be scenarios where a number of applications have sent request operations to a particular queue and are all waiting for response messages on another queue. A correlation identifier is needed to ensure that the correct messages are received by the correct applications.

The Enterprise Integration Patterns website provides a description of the Request-Reply pattern here.


A second scenario where message correlation is commonly used is when processing a sequence of messages using an aggregator pattern. Examples of this could be receiving a sequence of RFID messages for a particular shipment and aggregating them to generate an invoice, or reassembling a large document that was split into a sequence of smaller messages for transmission over a queue. Just as with the request-reply scenario the receiving application will need to correlate the messages in the shipment or document together based on some correlation identifier.

The Enterprise Integration Patterns website provides a description of the Aggregator pattern here.


Implementations of the request-reply and aggregator patterns will be discussed in the Request-Response Communication, Sessions and Handling Large Messages sections later in this section.

Speaking Engagements