What is Hosts and Host Instances?

A host is a logical representation of a Microsoft Windows process that executes BizTalk Server artifacts such as send ports and orchestrations. A host instance is the physical representation of a host on a specific server. A host can be either an in-process host, which means it is owned and managed by BizTalk Server, or an isolated host, which means that the BizTalk Server code is running in a process that is not controlled by BizTalk Server. A good example of an isolated host is Internet Information Services (IIS), which hosts the receive functionality of the HTTP and SOAP adapters. Hosts are defined for an entire BizTalk Server group; a collection of BizTalk Servers that share configuration, MessageBoxes, ports, and so on.

 What is Send Ports and Send Port Groups?

A send port is the combination of a send pipeline and a send adapter. A send port group is a collection of send ports and works much like an e-mail distribution list. A message sent to a send port group will be sent to all send ports in that group. The send pipeline is used to prepare a message coming from BizTalk Server for transmission to another service. The send adapter is responsible for actually sending the message using a specific protocol such as SOAP, or FTP.

 What is BizTalk MessageBox Database?

The heart of the publish/subscribe engine in BizTalk Server is the MessageBox database. The MessageBox is made up of two components: one or more Microsoft SQL Server databases and the Message Agent. The SQL Server database provides the persistence store for many things including messages, message properties, subscriptions, orchestration states, tracking data, and host queues for routing.

What is Difference between an Isolated host and an In-Process host?

The difference between an Isolated host and an In-Process is that an Isolated host must run under another process, in most cases IIS, and an In-Process host is a complete BizTalk service alone. Additionally, since In-Process hosts exist outside of the BizTalk environment, the BizTalk Administration Tools are not able to determine the status of these hosts (stopped, started or starting).

Security is also fundamentally different in an Isolated host versus an In-Process host. In-Process hosts must run under an account that is within the In-Process host’s Windows group, and do not maintain security context within the Messagebox. Isolated hosts are useful when a service already exists that will be receiving messages either by some proprietary means or by some other transport protocol such as HTTP. In this case, the Isolated host only runs one instance of the End Point Manager and is responsible for receiving messages from its transport protocol and sending them to the Messagebox through the EPM.

What is Single Sign-On (SSO)?

Enterprise Single Sign-On (SSO) provides services to store and transmit encrypted user credentials across local and network boundaries, including domain boundaries. SSO stores the credentials in the SSO database. Because SSO provides a generic single sign-on solution, middleware applications and custom adapters can leverage SSO to securely store and transmit user credentials across the environment. End users do not have to remember different credentials for different applications.

What is zombie message in BizTalk?

Error: 0xC0C01B4C The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended.

A zombie message is a message that was routed to a running orchestration from the messagebox and was “in flight” when the orchestration ended. An “in flight” message is a message that has been routed to a service instance and so is in a messagebox queue destined for the service instance. Since the message can no longer be consumed by the subscribing orchestration instance, the message is suspended and marked with a ServiceInstance/State value of “Suspended (Non-resumable)”.

A zombie service instance is an instance of an orchestration which has completed while a message that was routed to the orchestration instance from the messagebox was still “in flight”. Since the orchestration instance has ended, it cannot consume the “in flight” messages and so is suspended and marked with a ServiceInstance/State value of “Suspended (Non-resumable)”.

Terminate control messages – The orchestration engine allows the use of control messages to cancel all currently running work in a specific orchestration instance. Since the control message immediately halts the running orchestration, zombie instances are not unexpected. A number of Human Workflow related designs tend to use this mechanism as well as some other designs.

Parallel listen receives – In this scenario the service instance waits for 1 of n messages and when it receives certain messages it does some work and terminates. If messages are received on a parallel branch just as the service instance is terminating, zombies are created.

Sequential convoys with non-deterministic endpoints – In this scenario, a master orchestration schedule is designed to handle all messages of a certain type in order to meet some type of system design requirement. These design requirements may include ordered delivery, resource dispenser, and batching. For this scenario, the tendency is to define a while loop surrounding a listen with one branch having a receive and the other having a delay shape followed by some construct which sets some variable to indicate that the while loop should stop. This is non-deterministic since the delay could be triggered, but a message could still be delivered. Non-deterministic endpoints like this are prone to generating zombies.

What is an orphan message?

An orphaned messages is a message that has completed and finished its processing in the BizTalk message box however the information of this is not updated in the tracking database and will hold space in the tracking database until manually deleted or updated.

How do you track success message transaction in BizTalk?

You can use the BizTalk Server Administration Console to enable message body and message property tracking. There you can also view the tracked message body, including schema information, strong name, and all the promoted properties for the generated message. For more details of Message tracking click here.

In how many ways can we do the BizTalk Application deployment?

BizTalk Application deployment can be done using the following:

  • Deploying from Visual Studio
  • Building a Microsoft Installer (MSI) package that can be exported or imported between environments.
  • Using command line-based tools such as MSBuild and BtsTask.
  • Using community frameworks, such as BizTalk Deployment Framework and NANT.

Below links are available for other segment of Interview questions and Answers:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s