Welcome to Avantra

Monitoring & observation (Checks and Reporting) is key to understanding the health of your SAP world. Avantra has had monitoring at its core since the start. Avantra is designed from the core to excel at landscape observation across 5 types of monitored objects:

A grouping of monitored systems including any or all of the above is called a System Selector. System selectors can be dynamic where the contents of the group are based on criteria (e.g. all systems that are running a Windows operating system) or they can be static where you decide which systems are included.

Each of these monitored objects is monitored and observed across:

Notifications are one of the most important components of Avantra (after our monitoring and observation capabilities). You need to be able to inform the right people/systems and automations at the right time and in-response to an event. The Avantra notification management system will do this for you.

A Notification is a response when something has changed within Avantra. For instance, a critical check result needs to be passed on to a 3rd party IT service management solution, or somebody wants to receive a notification on their mobile phone. A notification can also trigger an automation, for instance, perhaps you want to auto-gather root-cause analysis information at the exact moment when a problem was detected.

While Avantra comes with native integration to platforms like ServiceNow and AWS SMS, other services can be used by the generic REST and SOAP interfaces. To date, there is no 3rd party system Avantra has failed to connect-to and work with. There are also many more output channel types, a simple but versatile one is running a command-line executable.

Key areas for notifications and integrations include:

Avantra provides many ways of integrating with 3rd party products and platforms. In general, we distinguish two ways of integrations: outbound and inbound. Some integrations, for example, the integration to the hyperscaler platforms like AWS, Microsoft Azure, and Google, or the ServiceNow, work in both directions. These integrations are first set up in a general way on the API level, and then the same API integration can be used in different outbound and inbound scenarios throughout the product.

Key areas for integrations include:

Automation is defined in Avantra as reducing the amount of human interaction that is needed to perform a task or activity that changes a monitored system in some way. This is to distinguish it from our monitoring capabilities, or Observe Automation where we automate your daily and real time checks to keep a system up and running.

For example, activities that automatically read and calculate the current status and performance of your SAP Jobs are best implemented as checks to give the full power of notification management, reporting and analytics we provide. Whereas starting new SAP Jobs or rerunning existing failed jobs are best implemented as an automation workflow to make use of the specific features of our automation engine, such as building upon the many built in and Step Library steps, track execution progress and combine manual and automatic tasks together.

The automation engine at the heart of Avantra is designed to provide you out of the box automation capability as well as allowing you design and deploy your own custom automations (even if you’re not a coding expert!).

In this section we will describe our automation engine in detail and how you can make best use of it in your Avantra.

We’ve defined a series of terms used to create an automation. Let’s look at each of them:

A major difference between Avantra and almost all other system management applications is the focus on a Service Provider perspective. Avantra is designed consistently keeping Service Provider and large-scale enterprises in mind.

Therefore Customers are a fundamental building block in Avantra. Every System is assigned to a Customer (in the meaning of the Customer being the System owner). On the other hand, Users in Avantra are assigned to Customers as well when it comes to Permissions: a User either represents a Customer or has the permission to perform certain tasks on behalf of the Customer (or even for all Customers if a user represents the Service Provider itself).

It is perhaps best to think of Customers as a simple grouping mechanism (for example, for Systems) on the one hand, and as the smallest entity for which you can grant Permissions on the other.

Even more, Customers can be arranged in a hierarchical structure. Due to the inheritance of Permissions, more complex groupings can be achieved.

Other areas, where the Service Provider perspective plays an important role, are: