Configuring Hosts and Host Instances

Gautam

BizTalk solutions typically consist of a collection of executable artifacts – receive locations, pipelines, orchestrations, send ports, etc. BizTalk provides hosts as a way of logically grouping these artifacts and then allows you to instance each host on one or more BizTalk server.

A host instance represents a physical runtime process/windows service running on a BizTalk server. This mechanism provides a very flexible solution in which to host BizTalk application components and there are several factors which should be taken into account when distributing your application across multiple hosts.

Although a single BizTalk Host can contain items that receive, send, and process messages, it is considered a best practice to create different hosts for each function to create security boundaries and for easier management and scalability.

In particular, it is recommend that you use different hosts for processing and for receive/send operations, and that you separate trusted and non-trusted items.

For example, if you receive one message, run an orchestration, and send ten messages, you want to separate the receive and send functionality into two separate hosts because the send items will have ten times more traffic than the receive items. If you receive one message, run an orchestration, and send one message, you can think of these items as a unit of work and group them into one single host. Alternatively, you can separate them into three different hosts to increase performance and flexibility.

Separating Host Instances by Functionality

A general best practice, is to use a separate host for receiving, processing, sending and tracking.

This provides flexibility when configuring the workload in your BizTalk group and is the primary means of distributing processing across a BizTalk group. This also allows you to stop one host without affecting other hosts. For example, you may want to stop sending messages to let them queue up in the MessageBox database, while still allowing the inbound receiving of messages to occur.

Separating host instances by functionality also provides the following benefits:

Each host instance has its own set of resources such as memory, handles, and threads in the .NET thread pool.
Multiple BizTalk Hosts will also reduce contention on the MessageBox database host queue tables since each host is assigned its own work queue tables in the MessageBox database.
Additional host separation should also be considered when dealing with artifacts with scale-out limitations; those which suit clustered BizTalk hosts (MSMQ receive, POP3 receive, in-order processing, etc). In these cases, artefacts with scale-out limitations can be grouped into one host and clustered, while all others can remain in hosts which support multiple running host instances
Throttling is implemented in BizTalk Server at the host level. This allows you to set different throttling characteristics for each host.

Reliability

Separating application processing across hosts ultimately leads to multiple runtime processes hosting your application. As BizTalk can host custom written components (custom adapters, custom pipeline components, custom functiods, etc), host separation can be used to provide process isolation and protection.

If you’re experiencing instability in any custom components, you should consider isolating them into their own BizTalk host. This will help prevent these unstable components affecting the overall application processing.

Security

Host separation should also be a consideration when planning for security:

Each BizTalk host is assigned a Windows Group which is used to permission the host specific tables in the BizTalk databases. This means that a BizTalk host provides a security boundary within the database and should be considered when dealing with highly sensitive data.
Certificates can be utilized in BizTalk for message signing and encryption. Certificate thumbprints for these functions are assigned at the host level and therefore you may have a need to separate hosts in order to represent different identities.
All host instances are assigned a service account to run under. Access to external systems is often a requirement for this account in order to process outbound messages through the adapters. In circumstances where access to sensitive external systems is restricted, host separation can be used to move the artifact which access these systems into their own dedicated hosts where specific restricted user accounts can be assigned.

The recommended starting point for host configuration/separation for any BizTalk solution is to separate receiving, orchestration processing, sending, and tracking functionality into separate hosts. From this point, other aspects discussed above should be considered and tested to ensure the desired outcome of any changes is achieved.

Dedicated Tracking Host

A tracking host is very important for overall health of your BizTalk environment; it’s responsible for moving all the DTA and BAM tracking data from your message box database to BAM and DTA database. If you don’t have a tracking host, over a period your message box will get bloated and degrades you’re overall environment performance.

BizTalk Server is optimized for throughput, so the main orchestration and messaging engines do not actually move events or messages directly to the BizTalk Tracking (DTA) or Business Activity Monitoring (BAM) databases, since this would divert these engines from their primary job of executing business processes. Instead, BizTalk Server leaves the events and messages in the MessageBox database and marks them as requiring a move to the BizTalk Tracking or BAM databases. A background process (the tracking host) then moves the events to the BizTalk Tracking and BAM databases, while a SQL Server Agent job copies tracked messages to the BizTalk Tracking database.

Using a dedicated tracking host allows you to stop other BizTalk hosts without interfering with BizTalk Server tracking. The movement of tracking data out of the MessageBox database is critical for a healthy BizTalk Server system. If the BizTalk Host responsible for moving tracking data in the BizTalk group is stopped, the Tracking Data Decode service will not run. The impact of this is as follows:

HAT tracking data will not be moved from the MessageBox database to the BizTalk Tracking database.
BAM tracking data will not be moved from the MessageBox database to the BAM Primary Import database.
Because data is not moved, it cannot be deleted from the MessageBox database.
When the Tracking Data Decode service is stopped, tracking interceptors will still fire and write tracking data to the MessageBox database. If the data is not moved, this will cause the MessageBox database to become bloated, which will impact performance over time. Even if custom properties are not tracked or BAM profiles are not set up, by default some data is tracked (such as pipeline receive / send events and orchestration events)

High Availability for BizTalk Hosts

Following table summarizes the high-availability guidelines for the most common adapters in BizTalk Server.

About the Author

My name is Gyanendra Kumar Gautam. I am Solution Consultant, who basically works to hook the stuff together using Microsoft technologies like Azure PaaS, Azure Serverless Services, Microsoft BizTalk Server, and Azure DevOps Services.

Learn more

Configuring Hosts and Host Instances