Creating a BizTalk Server Hosting Environment
Before you create your BizTalk Server hosting environment, consider the following recommendations:
- Use different hosts for orchestrations and receive handlers
Any items running in a host (for example, orchestrations, pipelines, receive and send handlers) run under the same identity, and have access to the work and suspended queues for that host.
If a message cannot be delivered to an orchestration due to permission errors, the message is placed in the suspended queue of the host where the sending process (a receive pipeline or another orchestration) is running. However, if the orchestration and the sending process (for example, a receive pipeline) are running in the same host, the orchestration can still access the message in the suspended queue. This could potentially compromise your system if a non-trusted orchestration is running in a trusted host.
It is recommended that you run non-trusted orchestrations in a separate host, with a different service account than the trusted hosts in your BizTalk group. For information about designating a host as trusted, see Modifying Host Properties in the BizTalk Administration Console.
Note If the ASP.NET worker process identity in which the BizTalk published Web service is running is different from the isolated host instance identity for the SOAP receive handler, then the host instance will actually be not trusted, even if you designated, in the Configuration wizard, that both the in-process and the isolated hosts are authentication trusted.
- Limit the database and log size in the BizTalk Server databases
The BizTalk MessageBox databases and the BizTalk Tracking database grow a lot faster than the other BizTalk databases. As part of your backup and maintenance program, you should include cleaning up these databases frequently.
By default, the tables in the BizTalk Server databases do not have a log size limit. As part of your backup and maintenance program, it is recommended that you limit the log size to prevent the logs from becoming too large and potentially using all the disk space.
- Use SQL Server clustering
To provide high availability of the BizTalk Server databases, it is recommended that you cluster the SQL Servers where the BizTalk databases are stored. This will help minimize downtime if one of the databases or SQL Server fails. For more information about SQL Server clustering, see "Failover Clustering Architecture" in SQL Server 2000 Books Online.
The instructions in the following procedure assume that you have installed BizTalk Server with the complete installation option. If you did not install BizTalk Server with the complete installation option, some of the administration objects listed in step 1 may not be on your system.
To create a typical BizTalk Server hosting environment
- Use the Configuration Wizard to create a new BizTalk group. For information about creating a new BizTalk group, see Using the Configuration Wizard.
The Configuration Wizard creates the following Administration objects:
Administration object Description BizTalk Configuration database, named BizTalkMgmtDb This database is the central meta-information store for all BizTalk Servers. BizTalk MessageBox database, named BizTalkMsgBoxDb This database stores subscriptions predicates. It is a host platform, and keeps the queues and state tables for each BizTalk Server host. The MessageBox database also stores the messages and message properties. For information about MessageBox databases, including adding additional MessageBox databases, see Managing MessageBox Databases. Server This is the computer on which BizTalk Server is installed and configured, and where host instances are running. You create host instances from a host created on a server. For more information about creating a host, see Creating a New Host in the BizTalk Administration Console. For information about creating host instances, see Adding Host Instances in the BizTalk Administration Console. BAM Primary Import database, named BAMPrimaryImport This is the database where the Business Activity Monitoring tool collects tracking data. Rule Engine database, named BizTalkRuleEngineDb This database is a repository for policies, rules, and vocabularies for data references in business rules. BizTalk Tracking database, named BizTalkDTADb This database stores business and health-monitoring data tracked by the BizTalk Server tracking engine. SSO database, named SSODB This database stores credential information. Tracking Analysis Server Administration database, named BizTalkAnalysisDb This database stores both business and health-monitoring OLAP cubes. In-process host with corresponding host instances The in-process host operates within the BizTalk Server process space. Isolated host with corresponding host instances The isolated host operates outside of the BizTalk Server installation. HTTP/S, BizTalk Message Queuing, File, SMTP, SOAP, and SQL The Configuration Wizard creates these out-of-the-box adapters.
- Use the BizTalk Administration console or WMI to add components to your BizTalk Server environment as needed. To scale out your solution, add MessageBox databases, hosts, and servers.
- Use the BizTalk Administration Console or WMI to create host instances on the mapped servers. This step determines on which servers BizTalk Server will run. As the needs in your enterprise change, you can add servers, subtract servers, and change server-to-host mapping.
See Alsohttp://go.microsoft.com/fwlink/?linkid=20616.Copyright © 2004 Microsoft Corporation.
All rights reserved.