BizTalk Health Email Alerting Part 2: Dehydrated Instances

BizTalk Health Email Alerting Part 2: Dehydrated Instances

In this multipart serie of blogposts, I will try to give some examples to keep an eye on the monitoring of BizTalk, without having the need to log on to the environment. Emails will be sent to specific users about certain information.

The second part of this serie will be tackling dehydrated messages. With some simple scripting, specific user can be notified when a service instance is in a dehydrated state for too long. Dehydrated instances can occur when a long running process for example has been developed, but every instance has a certain “maximum runtime”. When that runtime is surpassed, we want to have a notification about it that something might be wrong with the process. What also will be done in this script is, next to sending just an email, is also including an attachment containing the message which was processed last by the service instance.

Next to notifying a user, there is also the option to terminate dehydrated instances after a certain amount of time to clean out the BizTalk environment. This way, having instances dehydrated for months can be avoided. The messages are also stored and the location of this storage is communicated together with the email notification of a terminate.

First, some variables are defined and initialized. An argument is needed in this script, being ‘daily’ or ‘minutely’. This indicates which part of the script needs to be executed:  

  • Daily: Check for dehydrated instances (eg. Older than 2 days) and terminate them
  • Minutely: Check for dehydrated instances (eg. Older than 10 minutes)

A temporary file location is used to temporarily store saved messages. The strEmailAdressesCC indicates an email address which needs to be in CC of ALL the mails that are being sent. The terminate instances option indicates whether instances need to be terminated or not.

The first of two large parts in the script will be handling all the ‘minutely’ processing. This involves checking if there are any instances dehydrated for a certain time, and informing certain users about this issue. Also the messages will be saved and sent. The saving and emailing is handled later. Multiple instance types can be used within one call to ‘ProcessDehydratedMessages’. In this case, two calls are being done to this function, with both a different timestamp. The first call will only be checking the provided instance types after 10 minutes of dehydration, the second call will be notifying users after 20 minutes of dehydration.

The second part is doing initially the same thing as the part above, but is used to indicate which instances are dehydrated for too long and will be terminated. At the end of this part, the script will also delete all currently existing folders which contain no data.

Now, we’re going to dive deeper into the function ‘ProcessDehydratedInstances’. The function starts again with defining the WMI elements to connect with the BizTalk server and to create a current datetime object. The provided date value is deducted from the current date/time.

All the provided instance type names, stored in the string array ‘strOrchnames’ are being looped and searched for dehydrated instances on the BizTalk environment. If an email address (or multiple) is provided, the function SaveAndEmailFiles is called. Read on to see the details of this function. Also the Boolean bTerminateInstancesAndDeleteDir is checked. If true, then the instance will be terminated.

The SaveAndEmailFiles function will take care of saving all messages and sending emails. It starts typically with defining the base for doing WMI calls.

A string is being constructed to save the messages to. This consists of the instance type name.

The query is being executed and the messages are being saved by calling the ‘SaveToFile’ function. Read on to see the details of this function as well. The ‘SendMail’ function is also called, as well at a save of messages as a terminate.

This ‘SendEmail’ function will construct an email message based on all previously queried values. It takes the name of the orchestration, the files itself, the serviceinstanceID, the activationtime and the email adressees into account. I’ll just let the code speak for itself here:

The script ends with a little cleanup function. This will remove all the ’empty’ generated folders on disk, so that no overhead of folders is created on the server running the script. If no instances for the servicename can be found, it will remove the folder which exists for this specific servicename.

There, we’re through. There is one last post following, handling suspended instances. This last one will maybe be most of use, since it will alert users when an instance is suspended in the BizTalk environment.

Thanks for reading, if you have any remarks or questions, please leave them in the comments section!

Andrew De Bruyne

Working at i8c

i8c is a system integrator that strives for an informal atmosphere between its employees, who have an average age of approx 30 years old. We invest a lot of effort in the professional development of each individual, through a direct connection between the consultants and the management (no multiple layers of middle management). We are based in Kontich, near Antwerp, but our customers are mainly located in the triangle Ghent-Antwerp-Brussels and belong to the top 500 companies in Belgium (Securex, Electrabel, UCB, etc…).

Quality Assurance

i8c is committed to delivering quality services and providing customer satisfaction. That’s why we invested in the introduction of a Quality Management System, which resulted in our ISO9001:2000 certification. This guarantees that we will meet your expectations, as a reliable, efficient and mature partner for your SOA & integration projects.

i8c - ISO9001-2015