Enterprise Integration Patterns Part-3 – Resequencer


At times ordered delivery of multiple messages are required and these messages are received in a non-sequential order. This problem is solved by the resequencer enterprise integration pattern. The resequencer integration pattern implies the following.

  • All the incoming messages must have the BatchID, their sequence and the last message of the sequence must be determined.
  • All the incoming messages are stored in a correct order in a temporary cache and when all of the messages are received the messages are sent in order.
  • You can read more about resequencer pattern here.

    In the example shown the incoming messages have a BatchID which works as a correlation set. The property is promoted to the message context and the correlation type is configured. The correlation is initialized by the first receive shape and the orchestration is started when the first message arrives. The message is saved in the SortedList of type System.Xml.XmlDocument so that we can save the message as a key value pair.

    The sequence of the message is determined from the message payload and each message has the field for its sequence. To receive all the messages a listen shape with a receive which follows the correlation based on the batchID is placed and on the other branch a delay of 20 secs is configured. The loop terminates when all the messages in the message stream are received. Each message has a field of TotalMsgs which determines the total messages. A loop variable is incremented when each message arrives.

    resequencer_1

    In the next loop all of the messages are returned to the send port in the right sequence.

    resequencer_2

    Note
    :
    Resequencing pattern must have a cache where the messages should be stored temporarily and when all the messages are received they must be sorted and sent in a sequence. However in this simple example we have used memory for storing messages whereas this approach is not good if the message size are very large. Another approach to store messages would be in a Database or on the Disk as a file. Storing on disk would involve efforts to retreive the files again. However storing in a database would also require connection to database, involving SQLServer/Oracle Ports and handling failure exceptions. I haven’t still found the best approach to cache messages, though I think storing the messages in the database would be best considering the performance factor.

    You can download the sample here.

    About these ads

    2 Responses to Enterprise Integration Patterns Part-3 – Resequencer

    1. Steve Brown says:

      Hi Abdul,

      Thanks for posting this solution. I’ve got it working just fine – just as long as all of the messages are received. In my test scenario where i only get three out of 4 messages, the delay never kicks in and the orchestration eventually dehydrates indefinitely (or at least longer than I care to wait). Upon 15000 milliseconds it is supposed to enter the delay branch and throw an exception.

      Any ideas?

      • Steve Brown says:

        Please don’t waste time answering this. It was a foolish mistake on my part. Timespan(0,0,0,15000) thinking 15000 milliseconds. Needed one more argument – Timespan(0,0,0,0,15000).

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s

    Follow

    Get every new post delivered to your Inbox.

    Join 140 other followers

    %d bloggers like this: