Here is an example. Configure a receive location with a file adapter. Now, sender puts a lot of files into the receive folder, and BizTalk is picking them up. Notice, that because of this file receive location BizTalk machine is not stateless anymore. So if the machine with the folder is down, messages cannot be retrieved until the machine gets back online. To make it scalable and reliable you have to put additional effort into putting this folder on a network share, on RAID or SAN storage, etc. Of course, most people don’t do that because they use file adapter in cases when application level protocol can handle transport level faults.
First, MSMQT does not have local queues, it uses BizTalk MessageBox as a persistent storage. Hence, the actual state (queue) is stored on the SQL Server machine.
So, everything is fine? Not yet. What if several BizTalk machines are behind NLB (Network Load Balancing)? MSMQT uses exactly once in order delivery. Hence, only one machine at a time can process messages for a particular receive location – otherwise the order cannot be guaranteed. However, if this machine is down, another machine in the group should be able to pick up the work. How is it done?
When MSMQ TCP connection is established, MSMQT locks an object in the database which is associated 1:1 with the receive location. This ensures that no other machine will pick up the connection for the receive location. If the machine owning the connection goes down or the connection times out, the object is released. So the next time connection is reestablished by the external machine, it may go to a different machine in a group and continue where the first machine dropped off.
Again, user does not see this, it all happens behind the scenes. What the user sees is a reliable delivery of messages from outside to the BizTalk MessageBox and back.
What it means for the stateless status, is that you’ve got a local persistence store – MSMQ Queue. If machine with this particular store goes down, the messages that are already there and not consumed by BizTalk are unavailable.
You still can make it scalable and fault-tolerant, MSMQ has an elaborate story for that and you will have to follow it and configure MSQM service to work under NLB and on a cluster. In particular, it may involve making MSMQ queues a cluster resource, binding MSMQ to the NLB IP address, etc. This additional administrative cost is the result of breaking stateless status of an individual BizTalk server machine.
Notice, that the second store also gives you some headaches when it comes to backup and restore story, but let touch backup and restore in a separate article.
Another example of such intermediate storage is SQL Adapter, which uses a SQL Server table to submit the data. In this case, scalability and fault-tolerance is very easy to achieve, however, it still requires extra administration. So in most cases, it is useful to stick to the stateless server concept.