Business Context Configuration

What is the Business Context good for?

APM is often understood from a technical point of view where technical people have a look on the application. In fact the reality is that APM heavily affects operating and business people who need to undestand APM-related data as well. Even for technically affine people it is hard to understand the technical monitoring of an application if the business context is missing.
Understanding the impact of slow or failing requests necessitates that the person knows what part of the application is affected. This is where the business context comes into play.

The business context allows to quickly understand what the user tried to achieve.

Concepts of the Business Context Definition

The goal of defining the business context is to specify how technical requests are mapped to different business goals of the target system's users. The business context comprises two conceptual layers: Applications and Business Transactions.

Business Transactions

A business transaction is the mapping of one technical request / user request to one specific business goal of a user. The boundaries of a business transaction are scenario dependent. Hence, a business transaction may span multiple nodes or only single nodes of a system.

Applications

An application is a grouping of business transactions that logically belong to the same overall business goal.

Example:

Let's assume that we are monitoring two systems with inspectIT:

• An online shop called DVDStore
• And an online shop called PetStore 

Both systems are using common components in the backend, as depicted in the following picture:

Although this looks like one system, conceptually, we can differentiate two aplications (DVDStore and Petstore) as, from the perspective of the users, these two have different overall busines goals (selling DVDs vs. selling Pets). The red (dotted) user requests belong to the DVDStore application. The green (dashed) users requests belong to the PetStore application. 

In this example the DVDStore requests can be easily differentiated from the PetStore requests by the path in the URL (/dvdstore/...  vs. /petstore/...). Each of these two onlilne shops may have (potentually individual) different types of user requests like

• visit the start page
• search for products
• view product details
• put an item to cart
• checkout cart
• etc.

Without vs. With Business Context Definition

The business context enriches technical requests with business use case information and, thus, provides a better understanding of what actually happens in the monitored system. The following two screenshots demonstrate the value of the business context.

Both screenshots show an overview of monitored user requests, whereby, each row in the table represents one user request.

• The Method column shows the entry method of the request. We see that the entry method is the same for all requests (doFilter). Hence, in this case the entry method does not tell anything about the business goal of the request. 
• The URI column shows the URI that has been accessed for the corresponding user request. In this case, the URI even gives an indicator what might be the business goal of the request (e.g. home, browse, checkout, etc.).

But, is this the whole truth? What if the URI is more cryptical?

The second scrennshot shows the same overview with the business context set up. In the columns Application and Use Case we now clearly see the application that has been called and the use case / business transaction of the requests.

The great benefit of having a business context definition becomes clear when looking the two requests that are outlined yellow (dashed). Although both requests have the same URI (/dvdstore/browse) they represent absolutely different use cases (Browse vs. Search). Thus, only with a properly configured business context definition it becomes clear what happens in the application from the business perspective!