Microsoft BizTalk is one of the most robust and reliable integration engines which have been used by various businesses for almost 2 decades. A lot of organizations are relying on Microsoft BizTalk Server to handle their highly complicated environment. It is obvious that it is essential to monitor the BizTalk server applications and the infrastructure on a regular basis to make sure the issues are resolved timely and to keep the environment healthy and always accessible.
BizTalk is at the heart of most integrations – sitting in the middle of the enterprise architecture for all internal and external transactions. As a result of its central role, BizTalk can often end up as a single point of failure, where a minor and unforeseeable issue can result in extended downtime with myriad impacts for your business.
According to the BizTalk Server documentation,“BizTalk Server is a publish and subscribe architecture that uses adapters to receive and send messages, implements business processes through orchestration, and includes management tracking of these different parts. BizTalk Server also includes trading partner management for business-to-business messaging, high availability to maximize uptime, a development platform to create your own components, an administration console to manage your artifacts, and business activity monitoring to manage aggregations, alerts, and profiles.”
The heart of the product is the BizTalk Server Engine and it consists of two main parts:
Several other BizTalk components can also be used in concert with the engine, including:
Simply put, BizTalk allows applications to talk to each other. It’s used to share information or events between internal or external applications linked together to perform business processes. All the systems used by your enterprise can connect to BizTalk, as well as systems used by any other companies you need to communicate with.
Companies (like yours) are still investing heavily in BizTalk and will continue to do so for years. BizTalk is often used for companies’ most business-critical applications, and as companies move to a hybrid integration scenario (more on that below) those systems are often the last ones to be migrated and some never will.
One of the primary concerns in Biztalk Monitoring is knowing that applications are online and healthy. In this context, healthy means that artifacts like Receive Locations, Send Ports, and Orchestrations are configured and enabled.
However, component monitoring is not the only thing that we should take care of while monitoring Biztalk. This can be multifold as there are different components and criteria that you need to consider in order to monitor the Biztalk as a whole. Some of them are:
Furthermore, when a source or destination system is no longer available, it is crucial that a BizTalk team receives a notification. So, in nutshell, monitoring Biztalk can be grouped into different categories:
This helps us in notifying on the availability of the various components of BizTalk or even the whole application is down. This also includes the services running on the server, which are Enterprise Single Sign-on, Rule engine, and DTC (depending on the configuration).
One of the important points is related to Single Sign-On Service availability. It doesn’t immediately result in a BizTalk outage, however, with the Single-Sign-On Master Secret Server offline, a simple activity like Windows Patching will render your BizTalk environment inoperable. Dealing with Single Sign-On Master Secret Server issues proactively is a good practice and will prevent unnecessary downtime.
Monitoring the health of BizTalk server environments helps us in identifying whether our applications and their components are in good or bad condition. For example, are any applications or their constituent artifacts experiencing exception conditions? Or are messages suspended because of invalid data?
This helps us in identifying whether our application and its components are running efficiently. It means that it will tell you what the performance of your database is, what is the performance of your CPU while processing the data, or how much your host instance is utilizing while processing the messages.
Monitoring your BizTalk databases is one of the most important aspects of Performance Monitoring. Execution of the BizTalk Server SQL Agent jobs is crucial for managing the BizTalk Server databases and for maintaining optimal performance. Even with the jobs running successfully, there can be more causes of the uncontrolled growth of the databases like:
This type of monitoring is based on the threshold rules you have created in your environment. The rules can be typically based on the requirement of the Biztalk application and its performance over time.
For example, BizTalk Throttling configuration is a protection mechanism that will significantly slow down the rate at which BizTalk is processing messages. BizTalk will do this to prevent an all-out outage. Throttling conditions can severely back up a BizTalk farm and will probably have a negative impact on real-time processing.
Throttling issues usually need time to work themselves out, but proper tuning can often be prevented. You can set a limit on the threshold value on the different critical database connections, maximum throttling delay as per the analysis on the load of any component of Biztalk, and based on it the threshold monitoring configured.
Since Microsoft’s introduction of Microsoft Azure as the future of integration in the cloud, the firm has actively encouraged customers to begin (or at least begin planning) a migration of on-premise BizTalk integrations to the Azure cloud or look at extending BizTalk with cloud capabilities.
Microsoft has had mixed success here, and while some new integrations may be purely cloud-based for existing BizTalk customers, many companies still depend on BizTalk to integrate their most critical, high-security applications safely behind their own firewalls.
And while we still see companies starting new projects using BizTalk, most teams planning to migrate existing ones will do it bit-by-bit, creating a hybrid scenario, where BizTalk will continue to act as a service bus or gateway and connect the on-premise systems as well as the cloud apps.
Using the BizTalk Adapter Service in BizTalk 2016 makes it easy to keep connecting to new solutions no matter where and how they are built, and many BizTalk users will undoubtedly take advantage of these features to futureproof their existing BizTalk integrations.
The goal of monitoring BizTalk server environment is to minimize the amount of time that an anomaly goes undetected, and ideally to help proactively detect situations that might cause an exception before they occur.
All Stored Procedures, Databases, Memory usage stats, CPU usage, I/O activities, Server wait stats, Historical blocking information, Missing indexes, Logical disk volumes, Database parameters, Database sizes, Error captures, Maintenance plan jobs, Schedules jobs, OS build settings, SQL server settings and configuration, Memory settings, CPU processor/ parallelism settings, Virtual page size, Accounts, Remote servers, Database and user rights
If you recognize the challenges and needs we have outlined in this article, AIMS could be a solution for you.
But, don’t take our word for it. Sign-up for the AIMS Community Edition and experience the AIMS Capabilities for BizTalk monitoring for free. Monitoring your Biztalk Server has never been easier. We should be embarrassed if you spend more than 1 hour on the set-up :)
Verify for yourself how AIMS satisfies automated and future-proof monitoring:
Achieve effortless IT monitoring with truly automated AIOps platform.