Introducing Auto Healing For BizTalk Environment

|  Posted: June 17, 2015  |  Categories: BizTalk360

Have you ever received a call in the middle of the night, your monitoring system alerting for an issue in your BizTalk environment that was simply resolved by enabling your “BizTalk Receive Location(s)”? Wouldn’t it be nice if your monitoring system can detect threshold violation conditions and auto recover automatically? That’s exactly the functionality we … Continue reading Introducing Auto Healing For BizTalk Environment

Have you ever received a call in the middle of the night, your monitoring system alerting for an issue in your BizTalk environment that was simply resolved by enabling your “BizTalk Receive Location(s)”? Wouldn’t it be nice if your monitoring system can detect threshold violation conditions and auto recover automatically? That’s exactly the functionality we are bringing in our upcoming BizTalk360 7.10 release next week. BizTalk360 Auto-healing For a healthy BizTalk environment there are bunch of things that should all work in harmony in order to have a healthy environment. Things failing here and there could have a profound impact in your business. With our new “auto-healing” feature any state based artifact that’s been monitored by BizTalk360 can be automatically brought to the desired state (ex: enabled, started, even stopped). The following artifacts can be monitored and auto-corrected
  • Receive Locations
  • Send Ports
  • Orchestrations
  • Host Instances
  • NT Services
  • SQL Jobs
Let’s take some real world examples where this feature is so critical for your BizTalk Environment.

Receive Locations Getting Disabled

Your BizTalk receive locations getting disabled is a very common scenario. Here is a Microsoft support article explaining a FILE receive location pointing to a UNC path can shut down automatically. Here is an another example where a FTP receive location shuts down automatically after reaching certain amount of error threshold. If you do not have proper monitoring solution in place to notify someone the receive location is down, it could have a serious business impact, for example you may be polling your customer invoices from that FTP location periodically.  Often times these problems can be resolved by simply re-enabling the disabled receive location. In the FTP case the site might had intermittent network issue for some 10 mins or so and now it is perfectly fine to bring the receive location back. Right now it’s the job of the BizTalk administrator to take care of this situation and manually bring the receive location back. This task can be easily automated with BizTalk360 (both monitoring and auto-correction).

Human Error’s After Deployment

There are other sets of scenarios where certain artifacts might not be in desired state. Example: Your IT team has deployed a new version of the BizTalk MSI’s and binding files. As part of the deployment process, the last step is for someone to go and start all the applications. If the person doing deployment failed to do this step, it can only be noticed when business transactions start to fail and someone yelling at the BizTalk support team. BizTalk360 monitoring configuration is independent of BizTalk applications, so when people uninstall/un-deploy BizTalk applications the monitoring configuration will remain as it is (if artifacts are missing, we will show clearly that there are orphaned artifacts in the UI), once the new version of application is deployed the monitoring will come back to life automatically. With this new auto-correction capability of BizTalk360, even if the deployment team failed to bring artifacts (like BizTalk receive locations, send ports, orchestrations, host instances etc) to the required state, BizTalk360 can bring them to expected state based on the original monitoring configuration.

NT Services Down After Server Patch

This is another scenario, where your Windows team applied global patching using group policies and as part of that your BizTalk servers are restarted. After restart couple of important NT services (ex: Single sign on, Rules engine, EDI, IIS etc) even your BizTalk Host Instances didn’t start automatically. As you can notice there are some very important supporting services that must be up and running correctly, the BizTalk360 auto-healing (aka auto-correction) feature can solve this issue.

How Does It Work?

We have put together a detailed video explaining the detailed functionality of how auto healing works in BizTalk360. One of the important factors for us at BizTalk360 is making things simple.  We brought the same simplicity to configuring auto correction. As you look into the below screen shot, configuring auto correction is couple of click away. You select the BizTalk Application\Receive Locations, set the expected state for them, and then simply select and choose auto-correction. It’s as simple as that. The idea is exactly same for other artifacts like Send ports, orchestrations, host instances, NT Services and SQL Jobs. BizTalk Receive Location Auto-correction Once the auto correction happens in the background the system will also promptly send an email notification with a clear subject line saying “AUTO CORRECTION” to relevant people. This is very important for transparency,  otherwise there may be endless loop and long standing issue that might have gone unnoticed. As you can see in the below picture, there are clear warnings saying the monitoring service changed the state of certain BizTalk Receive Locations. BizTalk Artifacts auto-correction alert

Governance And Auditing

We also integrated auto-correction into our auditing capability, all the actions that’s been performed in the BizTalk environment by your support people is audited in BizTalk360. Example : some one restarting the host instances, someone disabling the receive location etc. In the same way when a system is trying to auto-correct certain artifacts it’s important to log them for future reference. As you can see in the below picture, the auditing traces clearly shows some receive locations are enabled by SYSTEM at what time. biztalk360 governance/audit I hope this feature will solve problems for many BizTalk Server customer out there suffering with artifacts going down unnoticed. If you are interested to learn more about BizTalk360 please get in touch with us,  you can also try the free trial on your own environment.

7 thoughts on “Introducing Auto Healing For BizTalk Environment”

  1. This sounds like a really useful feature to have, and will help with an issue we have where the ftp server connectivity sometimes disappears at 02:30 in the morning.

    Have you also considered the next stage of this where we can specify how many times an artifact should be auto recovered before it is deemed terminal and a Major alert email sent?

    For example, a receive location shuts down due to a bad address, BizTalk 360 auto starts it, it shuts down and so on. The autocorrect email would raise concern but would also result in a potentially endless stream of emails. If we could specify to auto start only 5 times, you could then send a Major issue email on the 5th failed auto start. If enough time (5 minutes +?) has passed since the last auto start then the count would be reset and start again.

    1. Hi Stuart, I forgot to mention that point in the article, the maximum number of notification settings you do at the alarm level in BizTalk360 will determine how many time the system will try to restart it. After that the alarm will get disabled. We do not send escalation emails at this stage, but that’s something in our todo lis.

    2. Stuart, we made some huge improvements to auto-correct retry mechanism, since we written this article. We are introducing auto-correct retry-limit at each artifact level. This gives more control and UI is also improved to make it easy to visualize. Will cover up in another separate blog.

  2. Hi Saravana,

    Just a questions regarding this great new function.
    Did you thought about an option for stopping the auto healing option, during f.i. an deployment and all should be down/off?
    At some point we do need to stop hosts and ports to deploy updates or new features and in that case you don’t want to manually change all the settings, before and after the deployment.

    1. Hi Gilbert, you need to use the “Stop Monitoring for maintenance” operation via Settings>Monitoring & Notification before you do any deployment.

  3. Hello Saravana,

    This idea was always been floating in my mind and I am glad BizTalk 360 got this alive and so well designed.

    One question:

    Is there any considerations on the order and/or other conditions/rules to evaluate before the auto healing starts to react ?

    For Example: If an application artifact has dependency over other artifacts or NT services then a quick check over the dependency before the Auto healing reacts would be much better controls for various heterogeneous application designs.

Leave a Reply

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

Back to Top