BizTalk Server 2004 : B2B, EAI and .NET

Friday, September 16, 2005

I'm now blogging at..

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

View complete post...

Friday, May 27, 2005

About Zombies and Convoys...

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 the Listen shape where we implement some logic to escape the loop. During this time interval, if a message arrives at the MessageBox, Biztalk sees our Orchestration as “Running” and since our Orchestration is a match for the Message’s subscription, Biztalk assigns this orchestration to take care of this message. Now our orchestration is blissfully unaware that it has a message or messages to take care of, and runs to completion. Hence, these message(s) are left in the message box with no one to process them or in other words in a Zombie state.

In my opinion, the first thing to do in this situation is (and I am not being facetious here) to verify that your correlation set is actually exact enough for your business scenario. For e.g. if we are transmitting patient medical records, we need to correlate only the same patients and not ALL patients. In other words don’t correlate JUST on MessageType if you can correlate on MessageType AND PatientID.

Secondly set your delay interval to an appropriate value. Setting it too low creates more such race timespans, per unit time. This will reduce your Zombie chances, but won’t give you a 100% success guarantee.

Thirdly have a proper plan to deal with these Zombies according to your business scenario. Retransmit? Discard? What?

Finally ponder about the “Receive Draining” pattern mentioned in Lee Graber’s blog, and if you have a nice elegant way of doing it, tell me about it FIRST!

View complete post...

Monday, April 04, 2005

'Non-Deterministic' Sequential Convoys

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.

View complete post...

Wednesday, December 29, 2004

The South-East Asia Earthquake and Tsunami

Totally off topic but very important nevertheless. For those of you who wish to find the right places to contribute towards the Relief Operations for Tsunami victims in South-Asia, please visit the following link.

The South-East Asia Earthquake and Tsunami

View complete post...

Thursday, November 18, 2004

Getting the BizTalk SQL Server DB Name

A quick one. How to get the name of the SQL Server that BizTalk is running? A relatively easy way is to get it from the registry. Heres a code sippet that does just that.

string strBtsSvrSubKey =
"Software\\Microsoft\\BizTalk Server\\3.0\\Administration";
string strBtsSqlSvrKey = "MgmtDBServer";
Microsoft.Win32.RegistryKey key = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(strBtsSvrSubKey);
string strBtsSqlSvrName = key.GetValue(strBtsSqlSvrKey).ToString();

Any queries, post a comment.

View complete post...