Why use ESB Pack metrics?

Learn about how ESB Pack improves BizTalk DevOps.

BizTalk Server is probably most conservative product that Microsoft ever shipped. It has powerful features used by many enterprises. However, customers who use BizTalk and ESB Toolkit sometimes face few challenges.

For example, a large enterprise uses BizTalk cluster as shared infrastructure for multiple internal business units. Each business unit is responsible for integrating their own applications for different lines of business. The customer assigns dedicated IT team to support BizTalk infrastructure while integration solutions are developed over time. The IT team decides not to use BAM, disables global tracking in BizTalk and expects each business unit to maintain their integrations. At the same time, business units only have access to exception management portal for repairing and resubmitting failed messages in response to alerts. Both business and IT have no ability to measure performance of itineraries, on-ramps, of-ramps  after new deployments to BizTalk cluster, even though there is always risk of impacting existing applications.

How customers could address these challenges? In this case, monitoring products that rely on data from BAM and BizTalk databases will become ineffective. Our product does solve this scenario with ease.

In addition to new powerful features specific to BizTalk ESB, the pack enables DevOps by introducing new metrics and efficient monitoring that are independent from BAM and global activity tracking. All itinerary flows can now be easily developed, tested and monitored.

In addition, the pack includes integration with Grafana software, which is de-facto industry standard for data visualization. The purpose of this integration is to enable BizTalk operators design and execute queries for a specific measurements.

The below picture shows Grafana dashboard with metrics for selected itinerary using data from the ESB Pack:

The itinerary and cache duration over time are shown for a single BizTalk Server node on the first chart. The cache duration represents off-wait time for synchronous responses from external services or systems that are triggered by this itinerary.  The next chart shows fault message counts for same itinerary with port name where faults have occurred.  BizTalk operators can drill down to a specific time period, server, itinerary instance details, cache, errors and other metrics that are stored without using BAM.

The below picture cache metrics for outbound transport location resolved by itinerary. There are two charts, one for each BizTalk node:

cache02

The bottom chart has no data because second BizTalk Server node has not sent any outbound requests to external service address determined by itinerary.

The ESB Pack metrics for itineraries, on-ramps, off-ramps and failed routing enable effective DevOps for BizTalk. The metrics collection is independent from BAM and global activity tracking. More details about metrics from other sources will be discussed in the future posts.

Please feel free to comment or contact us for more details.