What is BizTalk service instances (Suspended, Active, Schedule etc.) and how to monitor it?

What is a service instance?

It may be a confusing terms of people who are new to BizTalk server.  In BizTalk server there are two main type of processing components

1. Orchestration Service Instance
2. Messaging Service Instance

It’s very easy to understand the orchestration instances, you develop an orchestration and deploy it in your environment. At run-time for every activation message you receive for that orchestration will create a new instance of that orchestration.  Messaging service instance is the service instance that’s created for your receive and send port at run time. A receive port/send port is a combination of various things. Ex: A adapter (File, WCF, SQL etc),  A receive pipeline (and a send pipeline if two way), and Maps. The service instances gets instantiated like your objects for classes and during the life time they go through various stages (states).  Some of the common states include

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

You can see the detailed description here Service Instance and Message Instance States 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. But some of the states like suspended (resumable) and suspended (non-resumable) are failures that happen in your system and an administrative action may be required to rectify them. Ex: If you are trying to send a message to external web service and the web service is not available. In this case after all the retry the send port service instance will suspend itself with the state suspended (resumable). Once the web service is up and running again, the administrator can try to resume the suspended instance and the message will get processed. Also, the administrator can decide to terminate the service instance.

Why do you need to monitor service instances?

For a healthy BizTalk environment, it’s important to keep an eye on the number of service instances in the environment. Having a large number of BizTalk suspended service instances will bloat your message box database and adversely effect the overall performance of your environment. In some cases it could be an issue with the environment, ex: If the host instance is not started and you get messages that kick off the service instances, then those instances will be in “Read to Run” state until the host instance is started. If no one starts that host instance, the service instances are going to get accumulated bloating the message box. Typically support people keep an eye on the service instances count via the BizTalk Administrator group hub page . But it’s the not the ideal solution for a human being to always keep an eye on this count. The person who is monitoring need to be a BizTalk expert and understand the importance of each state. The group hub page only displays the instance count and it wont tell you whether they are expected count or not

Service instance monitoring using BizTalk360

To solve this challenge and help organisations maintain a healthy BizTalk environment, BizTalk360 provides a service instances monitoring at the application level. The administrator can setup warning level and error level count for the service instances various states as shown in the above picture. As soon as the threshold gets violated a monitoring alert (email/sms) will be sent to the relevant people/team. This avoid human errors, and it also frees resources to do some valuable tasks rather than looking at the BizTalk Administrator group hub page regularly. The support person can also visit the above screen in the UI to check the overall health at any time. Instead of just displaying the count (like BizTalk group hub page), the BizTalk360 UI will also give visual clues whether the instances are in healthy, warning or error state. The email received will look as shown below.