BizTalk Server 2004 : B2B, EAI and .NET

I'm now blogging at Geeks-with-Blogs . C'ya there.

This week was Load Testing week for our latest set of Interfaces. Incidentally, this was our first set of Interfaces which implemented Uniform Sequential Convoys in their Orchestrations. The implementation was more or less like my previous post . Meaning the convoys had a timeout mechanism, which lead the Orchestration to completion, if no new messages would arrive for a period of time. So far - so good. But under a realistic amount of load, we observed that almost 1 out of every 5-6 messages would fail to go through to the destination. The HAT would show the following: Completed with discarded messages Of course the 1/5 is a very subjective number, depending upon the actual convoy implementation in question. After some snooping around (mostly at Lee Graber’s blog ), I figured out that the source of the problem. But no amount of the aforementioned snooping yielded any easy and/or elegant solution to this little pickle. What happens is that the control might pass to the delay branch of

A long, long break between posts. Actually was working on some custom adapters, which kinda left me with little to post. Anyways, today morning a colleague of mine was facing a problem with Sequential Convoys . He didn’t know how many messages he was going to receive in a particular convoy. Consequently, he didn’t know how many times to loop the Receives that follow the co-relation set (Hence, the "Non-Deterministic" in the title). A simple solution exists to solve this problem. Use a Listen shape! A Listen shape with the Following Receive(s) in one branch and a Delay shape in the other, provides us with a graceful 'Timeout' kind of mechanism. Here’s a screen shot of how to plug in the Listen logic in your sequential convoys. Most information in my previous post about Uniform Sequential Convoys holds true in this case too. Post a comment if you need any clarifications.