.png){kind=logo}
The ultimate guide to Biztalk Monitoring
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.
Get the page into your mailbox so you can easily access it at any time.
First thing first, what is Biztalk Server?
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.”
Why is BizTalk (still) important?
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.
Where do most BizTalk performance problems originate?
- Any critical load (and message growth) on hardware
- Poor system design
- Poor infrastructure setup Throttling on hosts
- Human errors
- Patching and configuration changes
- Overloading the system by (manually) enabling BizTalk tracking
- Issues with SQL Server performance
- Assuming your necessary monitoring scope is covered
- Manual configuration of static thresholds
- Reliance on limited data
- Outsourcing the problem
- Relying on technical staff to know the business
Monitoring Biztalk
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:
- There can be issues in the system or infra layer of Biztalk. For eg. DTC issues, issues in the operating system, connectivity issues, etc.
- There could be a possibility wherein some of the components in Biztalk like Receive Location, Send Port, Host instances, or Orchestration are not running. This will create a problem in the message flow, so you need to take care of that part also.
- Biztalk is not processing the message with its full capacity, some slowness in some systems.
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:
- Availability Monitoring
- Health Monitoring
- Performance Monitoring
- Threshold Monitoring
4. Threshold Monitoring
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.
The role of BizTalk in Hybrid
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.
