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:
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:
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.
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.
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.
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.
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.
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.
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.
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,
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.
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.
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.
