Since early 2020, the BizTalk360 team started organizing frequent webinars. The goal of these webinars is to show the versatility of the product. Often, we are using real-world use cases to highlight how BizTalk360 can help organizations to manage their BizTalk environment in a safe and efficient way.
One of the webinars we did, was around showcasing how BizTalk360 helps when planned or unplanned platform maintenance is taking place or when preparing and performing BizTalk application deployments.
As there was good interaction during the webinar on this topic, we have been thinking that it would be good to write a blog around the topics that have been discussed during that webinar.
In this blog, we will discuss the below-mentioned scenarios:
If you want to view the recording of this actual webinar or join us in an upcoming webinar, you can check the website.
During Planned maintenance, engineers might stop/start/restart different components, reboot servers, etc. If in such cases, components of your BizTalk environment are affected, you want to prevent that your monitoring solution starts sending false notifications.
For example, if an engineer (or a script) stops Host Instances, and BizTalk360 monitors these Host Instances, there is no point in receiving notifications, because you are aware that this is due to the planned maintenance. The same is true for all the other components and BizTalk artifacts which can be monitored by BizTalk360.
To prevent receiving these false notifications, you want BizTalk360 to temporarily not perform monitoring. That is why with BizTalk360 you can schedule maintenance windows which exactly does that. The capabilities around scheduling maintenance windows in the product are quite flexible. For example, you can:
Setting up Maintenance Windows can be configured under Settings > Monitoring and Notification > Schedule maintenance.
More information about setting up Maintenance schedules can be found in the documentation portal.
In this case, BizTalk is down due to unannounced maintenance, the maintenance you were not aware of, or due to something unexpected happening. In such situations, the following might happen and the countermeasures are mentioned:
With the countermeasures in place, you will clearly be in more control of the well-being of your BizTalk environment.
In case you are already using BizTalk360, we have a set of tips to further help you out.
Create a separate alarm for BizTalk platform related components – this allows you to separately monitor components like Host instances, SQL jobs, BizTalk Server availability, Host Throttling, BizTalk database sizes, server resources. An additional advantage of a separate alarm for such components is that you can configure the threshold settings, high priority flag, etc., so you will be notified early when something unexpected is happening.
Set the Startup type of specific Windows NT services – For this Best practice, no BizTalk360 is needed. The BizTalk Host instances rely on the Enterprise Single Sign-On service. However, Windows NT service needs a lot of resources to be able to start. Because of that, it might happen that, after a reboot, the ESSO service and the BizTalk Host Instances are not started, causing BizTalk not to process messages. To prevent that from happening, you should configure the Startup type of the ESSO service and the Host instances to Automatic (Delayed Start).
Monitor server reboots via the Event Log – The reboot of a server can be an indication that maintenance has happened or something unexpected has happened. To be aware of reboots, you can consider setting up monitoring the Event Log for server reboots. This can be achieved by monitoring for the below parameters:
Configure this via Event Log Data Monitoring to monitor all the BizTalk servers in one go.
Install BizTalk360 on a separate server – To prevent being ‘blind’ when the BizTalk server goes down which also contains BizTalk360, we recommend installing BizTalk360 on a separate (non-BizTalk) server.
BizTalk360 can also be helpful when you are preparing and performing BizTalk application deployments. Let us have a look at a couple of examples.
After the deployment of a new BizTalk application, or after upgrading an existing one, ideally, all the deployed BizTalk ports and orchestrations will be in a stopped state. Having them in the stopped state after a deployment, allows you as a BizTalk administrator, to perform all kind of checks before putting these artifacts back to work.
So, as part of your preparations of the BizTalk application deployments, you want to preserve the state of existing BizTalk ports and orchestrations. Of course, you could take screenshots of the BizTalk Admin console. However, with BizTalk360 at hand, there is an easier way to achieve the same: You can use the Export to Excel feature.
The above screenshot shows the Search Artifacts feature. This feature enables you to search for BizTalk application artifacts, check their configuration, and change their state. The feature can be found under Operations > Application Support > Search Artifacts.
As you can see, a couple of Receive Locations are showing up in the screen, of which a couple of them are deliberately set to Disabled. For these Receive Locations it is important that also after deployments have been done, they remain in the Disabled state.
To save the state of all these Receive Locations, you simply click Export to Excel (see the green arrow). When needed, you can first filter for the relevant Receive Locations. After that, BizTalk360 will generate an Excel file and automatically downloads it to your browser. See the green frame in the lower-left corner of the screenshot.
The Excel file looks like below.
Similarly, you can also download the status of your Send Ports and Orchestrations.
Now, when the deployments are done, you can take the Excel files for reference to decide which ports and orchestrations need to be started.
Another useful feature can be the Auto Correct feature. The purpose of this feature is to try to automatically recover a component after it has reached an unexpected state. For example, let us assume that you are monitoring a Receive Location that needs to be in the Enabled state. Without having configured Auto Correct, you would only receive notifications that this Receive Location got disabled. However, when the Auto Correct feature has been configured, BizTalk360 will automatically try to bring that Receive Location back to its expected state. The Auto Correct feature supports the following components:
The Auto Correct feature has capabilities for the number of retries and resetting the maximum number of retries to make it even more powerful.
This feature can come in handy when, during maintenance, alarms have been disabled. Once maintenance is over and the alarms are enabled again. BizTalk360 automatically brings the components, which have the Auto Correct feature enabled, back to its expected state. This prevents you from forgetting to bring the artifacts back to their expected state.
You can read more about the Auto Correct feature in this article in the documentation portal.
When you are using Azure DevOps as your source code repository and to trigger CI/CD pipelines, you can also use BizTalk360. More specifically, you can use its APIs to bring BizTalk360 and the BizTalk Server application you are deploying in the right state for deployment. However, as in most scenarios the deployment framework takes care of handling the BizTalk application artifacts state, we mainly see that people are using the BizTalk360 API to enforce a BizTalk360 maintenance schedule.
A partner of ours has written an Azure extension which enables a maintenance window in BizTalk360. This extension has been described in this blog.
The BizTalk Deployment Framework, or BTDF, is a popular and free framework for BizTalk application deployments. It addresses limitations which come with the out-of-the-box capabilities of BizTalk Server and has features like:
Once new or upgraded BizTalk Server applications are deployed, you will probably want to create BizTalk360 alarms for monitoring or update existing alarms. Of course, you could do that manually after the deployments are done. However, you could also use a command-line tool which we developed a couple of years ago. This tool enables you to have BizTalk360 alarms created during deployment with BTDF.
If you want to read more about this tool, you can check this Wiki article on GitHub.
We have given a summary of the topics that have been discussed during our August 2020 webinar. Hopefully, we made it clear how powerful and versatile BizTalk360 is. If you want to make the life of your BizTalk administrators easier, so they can spend their time more efficiently, why don’t you give the product a go! You can request a demo, or take a free trial. We are always happy to discuss any challenges you might face, so feel free to reach out to us and have an obligation-free conversation.