Slow down BizTalk using an orchestration
Last week I wrote a blog post about slowing down BizTalk using throttling. This method can be good, but it’s also dependant of other factors, like how busy is your machine? Are there any other processes throttling? How severe is the impact? Different circumstances can influence throttling behavior. So it needs some testing, also on your production machine. It turns out the method is not as easy as it seemed.
If we want to make sure BizTalk will be sending a message a second, a more reliable approach would be the usage of an orchestration. That means creating an orchestration with a sequential convoy. It’s not the hardest thing to do, you just have to think over all scenarios and what will you do if something goes wrong, like the external system being offline or not returning a (positive) acknowledgement. And what will you do with all the messages that have been queued in BizTalk if the process fails? Testing all these scenarios can take some time testing, but it will create a reliable approach to the problem.
The Orchestration
So we need to build an orchestration that basically receives all our messages and waits a second, before sending the next one. This can be achieved easily using a sequential convoy. Yep, it’s that easy.
The orchestration below is generic and uses an XmlDocument for its message definitions. The messages received queue up on the (ordered delivery) receive port in your orchestration and will receive all the messages one by one, going through the loop. After receiving the each message, the orchestration will delay the process one second, before sending the next message. After the acknowledgement has been received (working with HL7 here), it will proceed to receive the next message, wait a second, and send it, etc. etc.
I don’t know how much more I should explain here 🙂 It’s pretty basic sequential convoy stuff. The correlation on the receive shapes is set to BTS.ReceivePortName in this example.
The delay shape, delays the process for one second:
new System.TimeSpan(0, 0, 0, 0, 1000);
And then there’s the time out for the process to end, that’s set to 5 minutes in this example:
new System.TimeSpan(0, 0, 5, 0);
The most important thing here is to make sure you have covered all your error handling, so make sure all messages will end up somewhere if there’s an error. It will save you a lot of work if something goes wrong.
