Basic Concepts

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 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 issues are 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 need to collect, track, and record data. Avantra provides:

All these data, among other things, 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.

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

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:

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.

Avantra consists of several components:

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

However, not all information we require is available with RFC-enabled function modules, or it is not available in a way that 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. Then these classes 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 with 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 older 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 that you may need to import the 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 the 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 at the outbound integrations.

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

Virtual Cluster Server does 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.

An SAP Business Object requires two licenses:

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 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, and Dashboards 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 installing the Avantra license, it is automatically activated, and the Activation process will run automatically every 12 hours. The same happens in the 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.