Call Rules Workaround in BizTalk 2009
You may be aware that one of the shortcomings of previous versions of BizTalk is that the Call Rules shape had to be contained within an atomic scope. The update that fixes this problem was added in BTS 2006 but was not fully implemented in Visual Studio, even with BizTalk 2009.
The following article articulates the problem and a solution:
The way to manage the problem is to simply make sure that you draw the Call Rules shape directly from the toolbox into the Orchestration. That’s as far as the fix goes. If you’re working with a Call Rules shape that has already been placed in an orchestration and would like to move it elsewhere, you’re kind of stuck. The Visual Studio environment will only allow you to move the shape into an atomic transaction.
But what if you don’t want want to re-do all that configuring by dragging a new shape from the toolbox as the article suggests?
The only work-around I’m aware of is to set the transaction property of the entire orchestration to “Atomic”. Then you may move the Call Rules shape anywhere in the orchestration except into non-atomic scopes. If you need to use an existing scope that you can’t convert to an atomic one (perhaps because of exception handling or some other reason), you simply re-create it by drawing a new atomic scope and dragging or copying all the existing shapes into the new scope. Then you change the new scope’s transaction property to none or long-running, create your Exception Handlers, and complete copying the rest of the code.
When you’ve finished moving things around, be sure that all transaction properties are back to their previous non-atomic statuses. Visual Studio will not complain and the code should compile and deploy assuming everything else is all right.
Yep–it’s kind of a pain in the neck, but not too difficult. If I discover a better way, I’ll be sure to post it here. In the meantime, anyone who has a better solution, feel free to comment on this post and let’s hope this problem is fixed in BTS 2010.
Of course, another solution is to avoid use of the Call Rules shape altogether. Just call the rules from a .NET component as described in my previous post on Calling the BRE from .NET Applications from inside an expression shape in your orchestration..