Having a stable, robust, (highly) available BizTalk environment is important. Many times BizTalk is installed, solutions are architected, and then the environment is not up to its task. System boundaries are reached fast and solutions do not perform well and make BizTalk throttle, as a result of excessive memory use or flooding of the system with messages. There are many ways to prevent this by using tools that are available, together with some best practices provided by Microsoft. They deliver a quite extensive BizTalk optimization guide (http://www.microsoft.com/download/en/details.aspx?id=10855) and operation guide (http://www.microsoft.com/download/en/details.aspx?id=6282).
Knowing your environment and its boundaries will provide insight on how to prevent your BizTalk environment from becoming a hotspot. For doing this, you have to go through the following steps:
Process of setup
Configure and test
Adjust and test
It starts with setting up your environment, but prior to that you will need to assess the requirements. You will only be able to do so by asking the right questions and analyzing them well. When you deploy BizTalk on the determined hardware and software, you will be able to validate, test, and tune it using the following:
During assessing and analyzing the requirements, it is possible that you will end up with a design of a scaled out BizTalk configuration. This will affect some of the essential components in a BizTalk runtime, the Microsoft Distributed Transaction Coordinator (MSDTC) and the Master Secret Server. In a multi-server BizTalk environment, MSDTC is vital and needs to get set up and configured properly before one starts configuring BizTalk features, such as group, Business Rule Engine (BRE), or Business Activity Monitoring (BAM).
During configuration of these BizTalk features, databases such as the BizTalk MessageBox (BizTalkMsgBoxDb), BizTalk Management (BizTalkMgmtDb), BizTalk Tracking (BizTalkDTADb), BizTalk Rule Engine (BizTalkRuleEngineDb), BAM Primary Import (BAMPrimaryImport), and others (BAMStarSchema) are created on the database server.
The Master Secret Server plays an essential role in aiding the BizTalk runtime in securing information for the receive locations and send ports. Some cases in which high availability is required, SQL Server and the host instances, need to be clustered for certain adapters such as FTP, POP3, and MSMQ. The reason for clustering the adapters is to prevent message duplication. The FTP protocol, for instance, does not support file locking (http://kentweare.blogspot.com/2009/04/clustering-biztalk-hosts.html).
In this chapter, requirements gathering and assessment will be described in a manner that could aid you when undergoing this process at the client side. Once you have prepared the deployment of BizTalk, you can go through the Analyzing requirements and creating a design, Configuring MSDTC for multi-server BizTalk platforms, and Managing the SSO system recipe later in this chapter. To validate, test and tune your BizTalk environment; you can read the recipes mentioned earlier.