Basic Concepts

Within this chapter we describe some of the basic concepts Avantra is built on. It is intended to provide you a better understanding of how Avantra works. It also describes some of the terms we use throughout this document and the product itself.

One of the major building blocks of this document is the Glossary covering the most important aspects of the product. So we will only discuss the concepts of Avantra very briefly at this point and link to the corresponding glossary terms instead.

For the beginning, it is important to know that Avantra is a shared application consisting of central server components and decentralized monitoring and management agents.


One of the most important aspects in the area of system management is Monitoring. Monitoring in Avantra is the execution of health Checks on the target Systems. Avantra follows a split monitoring approach: many System conditions have to be checked frequently and the results are reported in the RealTime Monitoring. Other conditions, especially in the context of SAP Systems, only need to be verified once a day, for example, the backup. These results are summarized in the Daily Checks. And in addition to the Checks executed on the monitored Systems there is also an End-to-End Application Monitoring providing system monitoring from an end-user perspective.

Every Check provides a Check Result that can be confirmed, as well as a Check history. Check Confirmation in Avantra is not a click-and-forget kind of thing. Even confirmed Checks pop-up periodically until issue is finally solved.

The configuration of Checks (or Monitoring as such) is implemented by means of the so called Monitoring Parameters. They can be defined on a per-System level or for a Static Group or Dynamic Group of Systems by the so called Parameter Sets. Using Parameter Sets allows you to enforce a consistent Monitoring Policy across your System landscape.

You can interrupt the monitoring process either ad-hoc or in a scheduled way by using Maintenance Windows. Like the other monitoring configuration items, Maintenance Windows can be defined on a per-System level or for a Static Group or Dynamic Group of Systems.

While there is a comprehensive list of built-in Checks in Avantra you may want to extend monitoring to other applications, interfaces, or to specific aspects of a System. Avantra provides a feature rich toolbox of the so called Custom Checks that allow you to extend monitoring to your needs easily. If you need to extend monitoring vertically instead, i.e. building new Checks based on the Check Results of existing Checks (or Custom Checks), you may want to define the so called Composite Checks. Or even Business Services if you want to correlate across System boundaries.

Finally, if you want to forward Check Results to administrators, Customers, or third-party applications, you can use the built-in Notifications mechanism to integrate Avantra perfectly into your operation environment.


Reporting is another important area in system management. But before there is something to report you have to collect, track, and record data. Avantra provides:

All these data, among other, is contained in the Service Level Reports that can be generated manually or per-schedule under consideration of Service Level Agreements and Maintenance Windows.

You can define different styles for the Service Level Reports, customize the content using templates, and define multiple scheduled jobs for the generation process.

Compliance, Governance, Auditing & Security

Avantra provides a bunch of features that are really helpful in this context:

  • System Change Auto Detection tracks all important changes within your SAP System.

  • You can monitor profile settings of your SAP System and Database continuously and compare them to a set of target values.

  • Avantra automatically verifies if special administrative users in your SAP System are locked or have the password changed from their default values.

  • Monitoring the audit log of the SAP ABAP systems, user authorizations and profiles (only available in the Avantra Pro Edition).

  • Monitoring of System Change Options and Client Settings

  • Finally, the rich toolbox of Custom Checks comes in handy in these scenarios, in particular, the ability to run arbitrary SQL statements on managed Database and evaluate them according to your needs.

Service Provider Perspective

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).

The best is probably to think of Customers as a simple grouping mechanism (for example, for Systems) on one hand, and as the smallest entity you can grant Permissions for 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:

  • Service Level Reports: they are generated on a per-Customer level, obviously.

  • The completely web-based user interface - Avantra UI: it allows representatives of the Service Provider and the Customers to work on exactly the same data without the need to deploy any GUI application.

  • An integrated problem management (ticketing) and change request application.

  • Mobile Access: XanMobile provides a reasonable subset of Avantra UI functions optimized for smartphones, like Android, BlackBerry or Windows Phones. There is also an Avantra Mobile App available for Android and iOS mobile devices.

  • Agent Self Updates: Once installed the monitoring agents can be updated centrally with multiple agents updated at the same time. There is no need to access the Customer's System on the operating system level.

  • Service Providers can delegate almost any functionality or task to their Customers to support multi-tenant operating concepts, for instance in SaaS deployments.


Automation is at the core of Avantra and powers everything from custom checks through to the intelligent notification system. To build a landscape that is resilient and able to react to the ever changing situation, Avantra gives you access to a powerful, customizable and intelligent automation engine. The latest version of Avantra includes the following capabilities out of the box:

Each of these actions can be performed either manually, in conjunction with a Maintenance Window, or as a Notification Action (meaning they can be triggered as a result of the output of a system or landscape check). You can also dynamically adjust resources in conjunction with Composite Checks and your Business Services. Avantra’s automation engine is incredibly powerful and is the foundation for intelligent operations.

This function is only available with the Avantra Pro Edition.

Avantra Architecture

Avantra consists of several components:

  • Avantra Agents are installed on the operating system of the Systems you plan to manage.

  • On the central server there are:

  • For more complex network scenarios there is a gateway service within each Avantra Agent that can be used to route traffic between other Avantra Agents and the server components.

xandria architecture

Avantra ABAP Interface

We are often asked questions about our ABAP interface, specifically what is in our two transports and why do customers have to import them to their ABAP-based systems. We understand the concerns given the importance for companies to run their production systems as stably as possible.

First, Avantra, i.e. the Avantra Agent, uses RFC (Remote Functions Calls) to communicate with ABAP systems. We are using a recent version of the official SAP JCo library, which provides RFC capabilities for Java-based software, like the Avantra Agent. Using original RFC capable SAP function modules, we can already get a lot of useful information to do our job, for example, we use a function module called TH_WPINFO to get information on the work processes of a SAP NetWeaver or S/4HANA instance; or we use SWNC_COLLECTOR_GET_AGGREGATES to read the performance data, like the number of dialog steps and the response times.

Avantra can also manage ABAP systems without the transports being applied, as long as the RFC user has enough permissions. It is clearly indicated which checks work and what does not work. This is especially useful to quickly rollout the Avantra Agent while the transports are being approved, to immediately benefit from all functionality which works without the transport being imported.

However, not all information we require is available with RFC enabled function modules, or it is not available in a way which suits important Avantra principles, like the separation of RealTime Monitoring and Daily Checks. Therefore, we have created our own RFC function module together with some ABAP classes to get the data we need to do our job. These classes then either call non-RFC capable original SAP function modules, or do queries on data directly from SAP tables. Certainly, you can examine this ABAP code once imported into your first ABAP system, if you wish to do so. Our ABAP interface is protected by our own authorization object ZSYSXANMON. So only RFC users, which have this authorization object included in their role, can use our interface. For all data being transferred via our interface, the Agent then calls the function module /SYSLINK/MON_XANDRIA together with some parameters: the name of the ABAP class which actually delivers the data, and other input data to do the queries, for example, a start date/time to look for records in tables. All this code is delivered in the first of the two transport requests.

Another important principle for the ABAP interface is that we whitelist any authorization we require. All these authorizations are provided as a role called ZAVANTRA which is delivered in the 2nd transport of the interface. It includes a complete role with authorizations being reduced to the very minimal set. For instance, each of the function modules we call in our ABAP code are whitelisted one by one. For example, we do not have access to business data unless required. These authorizations were frequently reviewed by security departments of large scale enterprises, or audited by external companies.

In many organizations importing a transport request requires going through an approval process. Since this can take some time, we are frequently asked how often we update the ABAP interface and provide new transports. Now, as with all software, we do further enhance the product and fix problems, however, not every customer might need a new function or a fix. That’s why the Avantra Agent is backward compatible to previous versions of the Avantra ABAP interface (at least to a certain extend). So you can rest assured that a new version of our Agent is able to use an oder version of the ABAP interface.

Lastly, people are sometimes concerned if our ABAP interface will cause issues during SAP System upgrades. The short answer is: it will not. First, all our objects are delivered within our own namespace /SYSLINK, which is officially registered at SAP. Second, our ABAP code does not modify any of SAP’s programs. And third, if our interface would be reported by an SAP upgrade phase, simply let the upgrade process delete them and reimport afterwards. The only thing to take care of, is you may need to import a version suitable for your new basis release after the upgrade.


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 Cloud Integration to the hyperscaler platforms like AWS, Microsoft Azure, and Google, or the ServiceNow Integration, work in both directions. These integrations are first set up in a general way on API level, and then the same API integration can be used in different outbound and inbound scenarios throughout the product. Please see Cloud Integration and ServiceNow Integration for more information.

Let us first have a look on the outbound integrations.

Outbound integrations

Notification Management

The first and most frequently used integration is provided by our notification management. In short, 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 his mobile phone. A notification can as well trigger a whole automation job, for instance to resolve a problematic situation automatically. There are many other ways to work with Notifications, please see Concepts of Notifications. Almost all Avantra customers are integrating to an already existing ITSM/ITOPs solution. Most prominent example is ServiceNow, with a certified integration.

For AWS, there are dedicated output channels to integrate with the AWS Simple Notification Service, and the AWS SMS service. All other services can be used by the generic REST and SOAP interfaces. There are as well many more output channel types, a simple but versatile one is running a command line executable.

ServiceNow CMDB

Another outbound integration is to the ServiceNow CMDB. Avantra can deliver information from our SAP system repository to the ServiceNow CMDB and is able to synchronize it in the background. See ServiceNow Integration.


Automation Actions provide a versatile way to integrate with other systems too. For instance, start/stop an SAP System or cloud VM or run a command or script, or do something on the SSH level. Automation jobs can be triggered by Notifications, run scheduled, or on demand. They can as well be triggered by interactive dashlets from within a dashboard.


Dashboards can be configured in such a way, that they can be integrated into other web pages. For instance, they might provide specific SAP or business application level insights to a broader service management web site. The example below shows an Avantra dashboard being integrated to a ServiceNow portal. See Working with Dashboards for further information.

dashboard integration to servicenow

Inbound integrations

Certified integrations to SAP

Avantra has been certified by SAP for the following two integrations:

  • Integration with SAP S/4HANA External Interface for Alert Management via the SAP integration scenario S/4HANA BC-XAL

    SAP Certi Integration SAPS4HANA R
  • Integration with SAP NetWeaver via the SAP integration scenario BC-XAL 6.10.

    SAPCerti Int SAPNetW CG10 R pos

Custom Checks

The most commonly used inbound integration to Avantra is being provided by Custom Checks. A Custom Check uses our extensive toolbox to get additional monitoring related information from managed systems and other systems and services into Avantra. Custom Checks use the pull principle, this means the Avantra Agent actively runs a Custom Check to get the data. Some Custom Check types provide scripting capabilities with deployment of scripts and can be very powerful. See sections Extending by Custom Checks and JavaScript based Custom Check API for more information.

Externally Managed Checks

Externally Managed Checks are similar to Custom Checks, however, they need to be pushed to Avantra, either by using the web service API or by command line. Externally Managed Checks are under complete control of an external program or script, they are not triggered automatically like Custom Checks. However, Avantra checks that Externally Managed Checks are up-to-date to make sure that there is no orphaned information. Technically, the externally managed checks are created by the web service or command line interface (see below).

Web service API & Command line interface

Avantra provides a SOAP web service to be used for 3rd party integrations. It provides access to the objects; for example, you can list, read and create many types of data in Avantra. Please see Setting Up and Configuring Avantra Web Service how to enable and use the web service.

The web service can as well be used by a command line interface. For further information, please see How to use the Avantra Web Service by Command Line Executable. The command line interface can also be used for mass import of pre-filled list of objects, Servers, SAP Systems.

Cloud VMs (IaaS)

Avantra automatically detects virtual servers running on the following IaaS platforms (in alphabetical order):

Metadata of the cloud VMs are displayed in the Avantra UI and this information is as well used for outbound integration, for example, to start/stop management of the VMs. You can also jump off directly to the hyperscaler consoles.

aws azure metadata examples

Cloud Services (SaaS)

Avantra provides the object type Cloud Service to integrate with SaaS solutions. There is a generic way of integration, which supports various authentication methods, and there are dedicated integrations, which simplify the setup and provide out-of-the-box support for business relevant checks.

Currently, there is a direct support for the SAP Cloud Platform Neo, others are planned, for example, SAP SaaS solutions, Ariba, SAP Cloud Platform Integration, SuccessFactors, Concur, etc.

The generic integration is intended to be used together with the RUN_JS Custom Check type and the JavaScript based Custom Check API. There are examples available in our knowledge base at

Import of Server Objects

Avantra can synchronize cloud VMs via the AWS API too and automatically creates an Avantra Server managed object. Google and Microsoft Azure will be supported soon.

Same works for ServiceNow CMDB. Avantra can directly synchronize Server data from ServiceNow CMDB. You can choose which type of servers you want to synchronize and you can also match ServiceNow CMDB data to Avantra fields. See Synchronization of Servers for further reference.


Avantra’s dashboards provide a function to include other web pages as iframes. See Working with Dashboards.


Avantra distinguishes five types of licensed items: SID, Additional SAP Instance, Stand-alone Database, Server, and Cloud Service.


This license type comprises the primary application server instance (formerly known as Central) of an SAP System (for example, SAP NetWeaver, SAP S/4HANA) and the (primary) logical Database of the same SAP System ID.

Additional SAP Instance

This license type is required for

  • any additional application server instance (formerly known as Dialog) of an SAP System that already consumes an SID license.

  • a stand-alone Web Dispatcher SAP System

  • a Web Dispatcher instance of an SAP System that already consumes an SID license.

  • an Abap_Scs with Web Dispatcher instance of an SAP System that already consumes an SID license.

  • a Trex instance.

  • a SAP Business Object instance.

Stand-alone Database

This license type is required for any supported Database that is not the primary Database of an SAP System, for instance:

  • any additional database instance (for example, liveCache) of an SAP System that already consumes an SID license

  • any supported Database that is not part of an SAP System at all.


This license type is required for any Physical Server running Avantra Agent on one of the following operating systems: AIX, Linux (Intel), PowerLinux, Solaris, Microsoft Windows.

Cloud Service

This license type is required for any monitored Cloud Service, for example:

Virtual Cluster Server do not require a license itself, but they can only run on a Physical Server that consumes a Server license.

You do not need a license for instances of type Java_Scs, Abap_Scs, or Enqueue Replication Server.

You do not need a license for the System Database of an SAP HANA multi-container installation.

A SAP Business Object requires two licenses:

  • an Additional SAP Instance license for the application server.

  • a Stand-alone Database license for the database.

All Systems require a license once they are active, even if monitoring is turned off manually or by a Maintenance Window. A System switches to the license state Retired once it is not operational. Retired systems still require a license for 40 days starting from the day they were set to not operational. After 40 consecutive days in state Retired, they automatically change to the license state to Decommissioned and the license is available again for other Systems.

If you delete a System from Avantra, the license will be immediately available for other Systems.

If there are more Physical Servers, SAP Systems, SAP Instances and Databases active than actually licensed, the ones entered last into Avantra are ignored, i.e. messages sent by the affected monitoring agent are dropped, instead there are UNKNOWN Check Results in the RealTime Monitoring.

Avantra comes in two Editions: Avantra and Avantra Pro. Certain features, like Cloud Integration, Automation, Business Services, Dashboards, and SAML are only available in the Avantra Pro Edition.

Licenses are issued by means of a license key that you request using the UI, and that is mailed to you in return. This process is described in detail in Obtaining and Installing the License.

The license key usually is restricted to a certain license period, depending on your contract. It is also bound to one Avantra Server instance with failover scenarios being supported.

After the installation of the license key, your license will run through an Activation process automatically every 30 days. The same happens in case of failover scenarios, hardware changes, network configuration changes, etc. If your Avantra Server has no Internet connection, you need to perform this Activation procedure manually through your browser.

Your Avantra server needs to be able to connect to,, and