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.
To begin with, 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 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.
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:
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:
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 the managed Database and evaluate them according to your needs.
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).
Other areas, where the Service Provider perspective plays an important role, are:
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.
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 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.
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 roll out the Avantra Agent while the transports are being approved, to immediately benefit from all functionality that 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 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.
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. The most prominent example is ServiceNow with 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.
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 website. The example below shows an Avantra dashboard being integrated into a ServiceNow portal. See Working with Dashboards for further information.
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
Integration with SAP NetWeaver via the SAP integration scenario BC-XAL 6.10.
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).
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 on 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 a pre-filled list of objects, Servers, SAP Systems.
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.
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 direct support for the SAP Cloud Platform Neo, others are planned, for example, SAP SaaS solutions, Ariba, SAP Cloud Platform Integration, SuccessFactors, Concur, etc.
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.
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.
an Abap_Scs with Web Dispatcher instance of an SAP System that already consumes an SID license.
a Trex instance.
an SAP Business Object instance.
- Stand-alone Database
- Cloud Service
This license type is required for any monitored Cloud Service, for example:
SAP Cloud Neo Environment
generic Cloud Service.
You do not need a license for the System Database of an SAP HANA multi-container installation.
An SAP Business Object requires two licenses:
Additional SAP Instancelicense for the application server.
Stand-alone Databaselicense 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 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.