This post was originally published here

As service instances (receive ports, orchestrations, send ports) process messages moving through BizTalk Server, these service instances can be in one of several states.

  • In Breakpoint: An active orchestration hits a breakpoint, typically one set by a BizTalk Server solutions developer. This state is valid only for orchestrations.
  • Ready to run: A service instance that has been activated but has not yet started running, typically due to temporary unavailability of resources, such as a heavy processing load on the server.
    Active Running service instance.
  • Dehydrated: The instance state persists in the MessageBox database, and no Windows service is running that instance.
  • Completed with discarded messages: The service instance was completed, but some messages were not consumed by the instance.
  • Suspended (resumable): Instance is suspended, you can resume it.
    • Important: Resuming a messaging instance will do the following:
      • Resume the messaging instance.
      • Send the message to the send port. The send port delivers the message to the destination, even if the send port is not in a Started state.
    • Note that when you suspend a scheduled instance and then resume it, the instance goes into a dehydrated state.
  • Suspended (not-resumable): The instance is suspended, but you cannot resume it. You can save the Messages referenced by the instance, and then you can terminate the instance.
    • Note that when you suspend a scheduled instance and then resume it, the instance goes into a dehydrated state.
  • Pending suspend/Pending terminate: A status, not an independent state. You can combine it with other states.
    • A control message to suspend or terminate was sent to a service instance but has not yet been picked up by the instance. Only one pending operation is allowed at a time. When an instance with a pending operation becomes dehydrated, you can terminate the instance.

We can see all of these service instances in all different stages inside the BizTalk Server Administration Console:

The problem with the admin console is that it needs manual intervention to check all of this information, so we need to keep clicking F5 each time we want to check them. That is not an effective monitoring operation and quite a waste of human resource time. Of course, there are several other ways to archive this goal:

  • You can use third-party monitoring tools;
  • You can use PowerShell to extract this information;
  • or you can use a simple SQL query.

Well, here is how you do a simple SQL query to extract Dehydrated service instances:

USE BizTalkMsgBoxDb;
SELECT COUNT(nstate) Dehydrated 
WHERE nstate = 8

You need to run this script against BizTalkMsgBoxDB, and it will return the count of instances Dehydrated. Equal to what you see in the BizTalk Server Administration Console.

Where can I download it?

You can download the SQL script here: