Concurrent Convoys with Time Outs
In my last project, I came across a situation when order of convoy messages could not be guaranteed. This simply implied that we should be using Concurrent convoys; problem solved, only until we stepped onto our next requirement to have timeouts implemented in case of all three (in our case) messages didn’t arrive in time. Now this turned out to be a show stopper for the reasons given below:
1. Concurrent convoy implementation in BizTalk does not give any opportunity to use listen shape (like in sequential convoy) and hence usage of delay shape to implement timeout. The reason being very obvious.
2. Even though the receiving part of concurrent convoy can be brought into the scope shape on which a timeout value could be set, however it won’t give an opportunity to access the messages already received (once exception routine is fired because of a timeout).
Solution:
Because of the very nature of the problem, I could not help but getting tempted towards going down a route of using sequential convoy that gives me a direct way to use listen shape and hence time out. Only problem is how to receive messages of different types in an unordered manner as non-uniform sequential convoy by its nature forces a sequence. Also, uniform sequential convoy is limited to receiving messages of a same type.
I overcame the problem by employing a uniform sequential convoy and making sure that the different types of messages (to be received by this convoy) gets converted into same type before it hits the convoy. This can be accomplished by using a custom pipeline component, which wraps the original message into a wrapper message, and by setting some key values in this wrapper message (for downstream processes to get hold of the original message). Lastly, what is left to be done in an orchestration (that implements uniform sequential convoy) is to extract the original messages and continue processing.
I list below the key components that I have used to achieve this solution.
1. Wrapper message schema: To wrap various incoming message to the same type. As you can see below there are some key values that I have defined in the schema (like OriginalMessageType) to help me recognising the original message and related attributes. OriginalContent element in the schema holds the original xml message. To avoid xml parser to avoid parsing this, I made sure to warp the original message in a CDATA block (example below)
Note: Some of the attributes are purely related to the implementation of my solution and may not be required in your case.
.GIF)
2. Custom pipeline component: To create a message of a common type from original message. This can be done by following steps below:
· Grab IBase Message by hiding GetNext method of a custom-disassembler.
3. Get hold of original message type: This is done to enrich wrapper message with the type of original message for downstream processes to process accordingly.
.GIF)
4. Wrap original message in a new wrapper message: While doing this I have made sure that I stick in original message type in one of the distinguished fields of the wrapper message. There are few more but these are specific to my implementation only. Note the use of CDATA block.
.GIF)
5. Create new message and copy original context across: I have made sure that I do not lose context supplied with the original message by copying it across. One thing to note here is that for me to be able to copy context across, I made sure that I get hold of one when pipeline Disassemble method was called earlier. Code snippets for both are below.
Grab Original Message Context
.GIF)
Copy context across
.GIF)
Final Piece:
Now that we have created a pipeline component that wraps the incoming messages into a common type, it is simply a matter of creating an orchestration that implements uniform sequential convoy (I will not go into details of this as this is pretty much standard). Only additional step we had to implement was to interrogate for the MessageType property on the wrapper message and pull out the original message from the wrapper message (we wrote a simple .net code which could be called from orchestration).