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 have brought in the BizTalk360 7.10 release
In this article, we are going to have a look at the following topics:
- BizTalk360 latest version
- Azure Services
- Receive locations getting disabled
- Human errors after deployment
- NT Services down after server patch
- Governance and Auditing
BizTalk360 Latest version
Every release of BizTalk360 has been based on the feedback we receive from our existing customers. All the version release activities are captured in release notes. Click here to know more!
One of the major releases we did was during 2021, v10.0 of BizTalk360 where we revamped our UI (User Interface) from Knockout.js to Angular and a few other new features developed.
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
- Send Port Groups
- Service Instances
- Host Instances
- Host Throttling
- NT Services
- SQL Jobs
- Azure Logic Apps
Let’s take some real world examples where this feature is so critical for your BizTalk Environment.
To align with the latest migration of the BizTalk application in the cloud, we brought the same in BizTalk360, preventing you from context switching between BizTalk360 and the Azure portal. BizTalk360 also allows you to work on multiple subscriptions simultaneously.
The following services can be monitored, and auto correct functionality enabled for the same.
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.
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.
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.
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.