Making a thread-unsafe DLL call in BizTalk Orchestration (or only running one Orchestration at a time)

Question

I have an issue with a 3rd party DLL, which is NOT thread-safe, but which I need to call within an orchestration.

I'm making the DLL call within an Expression shape. The same DLL is called in a number of different orchestrations.

The problem I have is that for a series of incoming messages, BizTalk will run multiple orchestrations (or multiple instances of an orchestration) in parallel - which leads to exceptions within the DLL.

Is there any way around this, given that refactoring the DLL isn't an option. Or, is there a way to throttle BizTalk to only run one orchestration at any one time. (I've seen some hacks restricting the working pool to the number of processors, but this doesn't seem to help. We can't downgrade to a single-core machine!)

I would rather find a way of keeping the DLL happy (though I can't think how) than throttle BizTalk - but if there is a way to throttle that would be an acceptable short-term solution whilst we discuss with the 3rd party. (who are a large organisation and really should know better!)

Answer 1

Even on a single core machine, BizTalk will run concurrent orchestrations.

You could throttle the orchestration by implementing the singleton pattern in the orchestration.

You do this by creating a loop in the orchestration and having two receive shapes, one before the start of the loop and one inside the loop.

Both these receive are bound to the same inbound logical port.

You create a correlation set which specifies something like BTS.MessageType and set the first receive shape to initiate the correlation and the second receive to follow the correlation.

As long as the loop does not end you can guarantee that any message of a certain type will always be processed by the same instance of the orchestration.

However, using singletons is a design decision which comes with drawbacks. For example, throughput suffers, and you have to ensure that your singleton cannot suspend, else it will create a block for all subsequent messages.

Hope this helps.