Different Approaches in Service Instances Automation

Published on : Nov 12, 2019

Category : BizTalk360 Update



In this blog, we are going to look at the BizTalk360 functionality, how it went one step further and helped to automate the process to handle service instances. Before that, we will have a look at the service instances and their importance.

In BizTalk Server there are two main types of processing components:

  • Orchestration Service Instances: If you are developing an orchestration and deploying it in your environment. At run-time, for every activation message you receive for that orchestration, a new instance of that orchestration will get created.
  • Messaging Service Instances: The service instances that have been created by your receive and send ports at run time. A receive port/send port is a combination of various things like an adapter, receive/send pipeline and maps.


Instance States and Stages

Service instance states and message instance states are displayed on the Group Hub page. They convey information about successfully processed messages and instances, failures, and suspensions during a specified time interval. The service instances get instantiated, like your objects for classes, and during the lifetime, they go through various states.  Some of the common states include:

  • Ready to Run
  • Scheduled
  • Dehydrated
  • Suspended, Resumable
  • Suspended, Non-resumable
  • Active

When messages flow into the BizTalk server, the messages get persisted in BizTalk Server’s MessageBox database.

Each of the service instance state signifies certain value. Some of them are system-specific states (ex: Active, Dehydrated, Ready to Run, etc), which will change automatically as the message gets processed.


When any message is suspended in processing, then it is logged into the suspended instance. In BizTalk, when a message is suspended, then it falls into one of these two categories.

  • Resumable: if the external resource (example web service, folder location in case of file adapter) is not available then the message will go for suspend resumable mode. Resumable means the service can be recovered.
  • Non-Resumable: Typically hold metadata and cannot be resumed. They will either disappear when the corresponding resumable instance is resumed or in other cases, they might need manual termination. You can save the Messages referenced by the instance, and then you can terminate the instance.

Sometimes we can directly resume messages from the admin console, after which they are processed successfully and sometimes they are not processed successfully. Once the service instance moves into a state that demands user intervention, the BizTalk server administrator needs to manually log in to the BizTalk Server Administration Console and fix the problem with respect to the service instance.

Why should you Monitor Service Instances

For a healthy BizTalk environment, it’s always important to keep an eye on the number of service instances in the environment. Having many BizTalk suspended service instances will occupy most of your message box database and it will affect the overall performance of your BizTalk environment.


In BizTalk360 we are offering two ways to act against the instances.

  1. Action against suspended instances manually
  2. Action against suspended instances automatically

You can act against suspended instances manually through the MessageBox (Queries), offering administrators the ability to query the MessageBbox database for such messages and take action.

MessageBox Data Monitoring

In MessageBox Data Monitoring, the user can configure the queries to monitor service instances and messages. The monitoring service will send the notification to the users whenever the service instances/Message count violates the configured threshold condition.

MessageBox Data Schedule can be configured in BizTalk360 -> Monitoring -> Data Monitoring -> MessageBox Data.

It can be scheduled at the different frequencies (Daily, Weekly, and Monthly) based on the volume and priority to take the action on service instances/messages.

The operational user (either it will be a super user or a custom user has the permission to take action within BizTalk360) must closely watch the suspended service instances to act on. It is a tedious process to look after all the time. The MessageBox data monitoring feature can take automatic action on service instances when the set actions are configured in our schedule.

The monitoring service will Resume, Suspend or Terminate the service instances based on either error or warning condition without any manual intervention.

Service Instances Action Based on Retry Count

Most important to be noticed is that BizTalk360 will resume the suspended instance irrespective of the “Number of Retries” count set in the port. Retry count is nothing but the number of times for the send port to resend/resume a message on message failure.


If the Instance is suspended in a port, then BizTalk360 will check how many times the instance is retried by BizTalk Server. If the number of retries done by BizTalk is less than or equal to the count set in BizTalk360, then it will resume the instance until it exceeds the count set.

If the number of retries done by BizTalk is greater than to the count set in BizTalk360 then it will stop resuming the instance on further monitoring schedule.


Check the Retry Count between the BizTalk Artifact and in the BizTalk360 Count in the UI

If the BizTalk360 configured value is 3 and the BizTalk server’s current Retry Count is 4, in that case, the BizTalk retry count is greater than BizTalk360, so it will not take any action against the instances. So, compare the instance count and set the retry count value high in BizTalk360.

Action on Long Running Service Instance which is older than X Days

You can also achieve the same scenario (task action like MessageBox Data monitoring) with the help of a prebuild custom notification channel: PowerShell. Let’s take a customer scenario here for how they utilized the PowerShell notification channel.

In the MessageBox data monitoring, you can act against the service instances based on,

  • Only Query result count (no date/time filter)
  • Query result with date/time range

Only Query result count (no date/time filter)

Selecting this option will execute the query without applying any date time filter. i.e. all the data will be considered for SQL query execution.

Based on Query result with date/time range

Selecting this option will apply the Creation Time filter for SQL query execution. (The values configured for setting trigger time, Set Monitoring Times ->At What Time, will be used for Creation Time filter).

For example: When Monitoring set frequency is set for 1 hour, then for every SQL query execution the query will consider only 1-hour of data.


In the customer scenario, they wanted to terminate the dehydrated and active service instances which are older than 15 days from the creation of the message. In data monitoring, this option is not available. To solve that, the customer terminated the dehydrated and active service with a PowerShell notification channel (custom script); the steps are below.

  • Create a PowerShell script to call the BizTalk360 APIs to check for the dehydrated service instance and terminate them
  • Attach this PowerShell script to a notification channel in BizTalk360
  • Map this channel to an alarm so that the PowerShell script will get executed to take action when the alarm is triggered.

Here is the PowerShell script to terminate the dehydrated and active service instances which are older than 15days in GitHub.

Note: The environment id details can be obtained from b360_admin_BizTalkEnvironment table in the BizTalk360 database. Modify the details according to your environment configuration.


An automatic action feature of BizTalk360 can take corrective actions in the event of any threshold violations. With just a one-time setting we have our BizTalk360 to make sure all your routine tasks are addressed without manual intervention.