BizTalk Server monitoring: View Count of Dehydrated BizTalk Instances

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 
FROM Instances WITH (NOLOCK)
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:

THIS SQL SCRIPT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.

Leave a Reply

Your email address will not be published. Required fields are marked *

turbo360

Back to Top