A demo I sometimes show during various BizTalk presentations is one that shows how to compensate for problems with using long running transactions in BizTalk Server. This sample was originally developed by Erik Leasburgh and  Raman Mahal. I created the walkthrough so we can show how to create the sample and hopefully provide details to show how it works so others can use it as a template for their designs. The problem we are trying to solve is that the atomic transaction shape in orchestration doesn’t really provide true atomic transactional semantics when used with a transactional adapter like SQL, FTP etc.

Let’s say I have an orchestration which has a send port which is bound to SQL Adapter Send port for sending the message to the SQL Database. For transactional purposes the developer has enclosed this send shape in an atomic transaction. Also in the same transaction there’s another send shape which is sending messages to another system. Both these sends should commit totally or should rollback.

Now during runtime say Send1 to SQL Server succeeds, but Send2 to the other system fails and because of that Send1 has to be rolled back. A user would think that since the 2 sends are in atomic scope in the orchestration, the orchestration will take care of the rollback process. This is not the case, you will need to compensate for this in your Orchestration. The sample and walkthrough shows you how to do this.  This is a version 1.0 of my docs, so let me know if this works or if you see any problems.