S

SAPControl

SAPControl provides a monitoring and management interface for SAP Instances. It can be accessed as a SOAP web service via Named Pipes (Windows), Domain Sockets (Unix), HTTP, or HTTPS. See SAP documentation for more details.

SAPControl User / Password

Credentials needed for access to SAPControl using HTTP/HTTPS protocols. The specified user must be a valid OS user authorized by service/admin_users, service/admin_groups profile parameters or sapstartsrv executable file permissions (Windows: execute permission, Unix: write permission).

SAP Instance

An SAP Instance is an administrative unit that groups components of an SAP System that provide one or more services, as defined in the SAP Glossary:

Administrative unit that groups components of an SAP system running on one physical host. Application server instances provide the actual computing capabilities of a system and offer corresponding services. Instances are started, stopped, and monitored as one unit. There can be multiple instances (belonging to the same or to different systems) on one host. An instance can be uniquely identified by the host name and a two-digit instance number.

— SAP Glossary

An SAP Instance can be one of the types listed in Instance Type. An SAP Instance is hosted by exactly one Physical Server or Virtual Cluster Server, but multiple SAP Instances can be hosted on the same server.

If you want to manage or monitor an SAP Instance, you need to manage or monitor the Physical Server or the Virtual Cluster Server that the SAP Instance is hosted on.

SAP System

An SAP System comprises one or several SAP Instances and a Database. It corresponds to SAP products like SAP R/3, SAP R/3 Enterprise, SAP NetWeaver, SAP S/4 HANA, etc.

In terms of SAP, the instances of an SAP System share the same SID (SAP system ID).

In Avantra terms, an SAP System is uniquely identified by the so-called Unified SAP SID. By convention, the Unified SAP SID consists of the SAP System Identifier (SID) with a prefix or suffix to make the Unified SAP SID unique within Avantra installation. In order to avoid confusion, we use the term Real SAP SID to refer to the SID within Avantra.

If you want to manage or monitor an SAP System, you need to manage or monitor the Physical Server, the Database, the primary application server (in old terminology, the Central instance) and, possibly, additional SAP Instances comprising the whole SAP System.

From a license perspective, you need at least an SAP System license and usually a Physical Server as well. If you have additional SAP Instances, you need additional SAP Instance licenses.

Trex and Web Dispatcher SAP Systems only consist of an SAP Instance without a Database, and hence only need an SAP Instance license.

SAP System Users (required by Avantra)

The Avantra Agent requires credentials of the SAP System users in order to connect to the SAP Instances.

ABAP (or ABAP+Java) SAP System

Requires an RFC user with the ZAVANTR role (as created by the transport requests shipped with Avantra), and we recommend creating a dedicated user, for example, avantra_rfc. This user is also called the Avantra RFC User. For the logon client of the user you should consider the following rules:

  • For ABAP+Java SAP System using the SAP Java User Management Engine (UME), the user has to be created in the master client used by UME in order to enable it for monitoring of the Java stack.

  • If you monitor an SAP BI/BW system, you need to create the user in the standard client of the BI/BW system.

  • If you monitor an SAP PI/XI system, you need to create the user in the productive client of the PI/XI system.

  • Otherwise we recommend using client 000

  • For an ABAP+Java SAP System, we recommend to authorize the Avantra RFC User as an administrator in the Java stack: Assign the ABAP role SAP_J2EE_ADMIN to the Avantra RFC User.

  • If you monitor an SAP PI/XI system, also assign the ABAP role SAP_XI_MONITOR to the Avantra RFC User.

Java-only SAP System

{avantra-agent} requires an administrator user. We recommend creating the avantra_j2ee user and assigning the Administrator role to it. This user is also called the _Avantra J2EE User.

Trex and a Web Dispatcher SAP System

There are no users required.

In order to access the Database instance of an SAP System, Avantra Agent also needs the credentials of the ABAP schema user and/or the Java schema user.

Server

Service Hours

Service Hours in Avantra define certain parts of the week, like 24x7 or from 8am to 6pm every working day, etc.

They can be used in Service Level Agreements, Filters and Parameter Sets.

Service Level Agreement

You can define Service Level Agreements and assign the agreements to Servers and/or SAP Systems. A Service Level Agreement primarily consist of a definition of Service Hours and a Committed Availability Rate.

For Systems having a Service Level Agreement assigned, the Service Level Report generation process considers Availability Data within the Service Hours (instead of the default 7x24) and compares the computed availability rate with the Committed Availability Rate.

For Service Level Agreements, you can also choose whether the Service Hours are defined in local system time or in UTC. If they are in local system time, then each of the System’s TimeZone setting is considered to compute the availability rate.

Service Level Report

You can easily generate a Service Level Report for each Customer. If, for example, you schedule the Service Level Report generation at the beginning of each month, your Customers can easily download the monthly reports. But you can also generate the Service Level Reports manually using Avantra UI in order to select content, reporting period, etc.

Service Level Reports can be customized. It is possible to change language, colors, fonts, page size, images, etc. to suit your specific needs and requirements.

All Service Level Reports are generated in the PDF format and stored in the Avantra Database. Service Level Reports generated automatically based on a schedule and can be sent to email addresses.

Solution Documents

The idea of Solution Documents is to provide functions to document all kinds of things in the area of system management.

Probably, the most important, but not limited to, is the option to create documents describing problem resolution and to easily find the most appropriate solution document once you face the same class of problems. It is exactly this purpose giving the function its name. More generally you can provide Solution Documents for the following objects within Avantra: RealTime Monitoring, Daily Checks, Systems, Parameter Sets, Custom Checks, Maintenance Windows, Customers, and Changes.

A Solution Document can be written using the built-in editor WYSIWYG HTML-Editor. In addition, you can attach any existing document, or you can simply provide an external link to refer to any other document you may have in place already.

Every Solution Document may have the so-called References. These references may be used to link the Solution Documents to the objects mentioned above. However, the references do not imply direct links between Solution Documents and other objects, but they reflect a relationship between the two, and the number and types of references indicate how relevant a certain Solution Document is for a given object.

In other words if you search for Solution Documents you will find multiple results with the most relevant Solution Documents at the top of the results, as known from other search engines.

Solution Documents are always assigned to a Customer. This way a Solution Document has an access control, since documents can be viewed only from users having the necessary permission for this customer. If you want to create a Solution Document that users of other customers can read, you should create a role for a generic customer and assign this role to the users who should be able to read the given document.

+

Static Group (of Systems)

A Static Group is a way to implicitly define a group of Systems for use with Parameter Sets, Custom Checks, and Maintenance Windows.

A Static Group is defined by naming one or more Systems being the members of the group. If you delete a System from Avantra it is also removed from the group. The most simple Static Group consist of a single System only.

Static Groups are implemented using System Selectors.

System

In Avantra terms a System is one of the following System Types:

  • Physical Server

  • Virtual Cluster Server

  • SAP Instance

  • SAP System

  • Database

  • SAP Business Object

  • Cloud Service

As a synonym we also use the term Monitored System. Every System is “owned” by a Customer.

Basically, if you want to manage or monitor a Physical Server, you need to install Avantra Agent on top of it. The same holds true if you want to perform End-to-End Application Monitoring: for every End Point you need to install Avantra Agent.

If you want to monitor a Virtual Cluster Server, you have to install Avantra Agent on all Physical Servers that may host the Virtual Cluster Server.

If you want to monitor an SAP Instance, you need to install Avantra Agent on the Physical Server hosting the SAP Instance, or on all Physical Servers a Virtual Cluster Server may run on hosting the SAP Instance. The Auto Discovery functions will automatically find all hosted SAP Instances.

If you want to monitor a Database — either a SAP Database instance or a stand-alone Database — you need to install Avantra Agent on the Physical Server hosting the Database, or on all Physical Servers a Virtual Cluster Server may run on hosting the Database.

Of course, you need only a single Avantra Agent monitoring the Physical Server itself, any Virtual Cluster Server configured on top of it, and all the SAP Instances or Databases installed on either the Physical Server or the Virtual Cluster Server. This Avantra Agent may as well serve as an End Point in End-to-End Application Monitoring.

If you want to manage an SAP System, you need to install Avantra Agent on all Physical Servers hosting SAP Instances (either directly or via Virtual Cluster Servers) of the particular SAP Systems, and on all Physical Servers hosting SAP Database instances (either directly or via Virtual Cluster Servers).

Due to the Auto Discovery algorithm, the SAP Instances hosted on a Server running Avantra Agent are automatically detected in almost all cases.

System Change Auto Detection

Avantra is able to automatically detect the most important SAP System and Database changes and create corresponding records in its integrated change management system. This feature is also known as Automatic Change Detection.

If you use Virtual Cluster Servers, even switches of your cluster switchover solution will be recorded. The idea is to avoid documenting a system change manually if the change documentation can be retrieved from the system itself.

Table 1. Objects covered by System Change Auto Detection
Object Data Source

SAP client settings

SAP System — see transaction SCC4

SAP System change option

SAP System — see transaction SE06

SAP component and SPAM version/patch level

SAP System — see transaction SPAM

SAP Instance kernel version/patch level

SAP System — see transaction SM51

SAP System RDBMS version

SAP System — see transaction ST04

SAP Instance profile parameters

Files located in profiles directory

J2EE System Properties per process (Dispatcher/ServerX)

J2EE JMX Interface

J2EE VM Properties per process (Dispatcher/ServerX)

J2EE JMX Interface

J2EE software components

Java SAP System Database

J2EE kernel/patch level

J2EE JMX Interface

Database parameters

depends on Database type

Oracle Database changes done with SAPDBA or BR*Tools

sapreorg directory

Virtual Cluster Server node switches

Physical Server

Version changes

Trex and Web Dispatcher SAP Instance

SAP HANA Configuration Layers

SAP HANA Database

More details, although most things are pretty much self-explaining, can be found in the Knowledge Base article Avantra System Change Auto-Detection.

System Role

System Role is one of the attributes and a standard grouping mechanism every System in Avantra has. Default System Roles are: Production, Test, Quality assurance, Development, Sandpit, Integration, Education, and Consolidation.

Other System Roles can de defined as well.

System Selector

System Selector is a user interface element to define a Dynamic Group or Static Group of Systems for use in Parameters Sets, Custom Checks, Composite Checks, and Business Services.

The group can be defined either by attributes of the corresponding System Type (like described in Dynamic Group), or by further restriction to hosted or hosting Systems according to the following paths:

  • Server → Database or Server → SAP Instance → SAP System

  • SAP Instance → SAP System or SAP Instance → Server → Database

  • SAP System → SAP Instance → Server → Database

  • Database → Server → SAP Instance → SAP System

This allows subtle selections, like return all productive SAP Systems that have a Java SAP Instance. You can even exclude particular Systems from the selection.

System Selectors can be defined ad-hoc, in which case they are only available for the CustomCheck, Composite Check, etc. they are defined for. Or they can be defined generically, in which case they can be shared across multiple objects.

System Status

Every System has a so-called System Status. The System Status is defined as follows:

  • For a Server it is the Check Status of the AGENTALIVE Check.

  • For an SAP Instance the System Status depends on the Instance Type:

    • For an ABAP-only SAP Instance it is the Check Status of the RFCConnect Check.

    • For a Java-only SAP Instance it is the Check Status of the J2EECONNECT Check.

    • For an ABAP+Java SAP Instance it is the worse of the Check Status of the J2EECONNECT and the RFCConnect Checks.

    • For an Abap_Scs SAP Instance it is the Check Status of the ASCS_MSGSRV Check.

    • For a Java_Scs SAP Instance it is the Check Status of the SCS_MSGSRV Check.

    • For a Trex SAP Instance it is the Check Status of the {_TREX Connect} Check.

    • For a Web Dispatcher SAP Instance it is the Check Status of the WD_Connect Check.

  • For an SAP System it is the Check Status of the SystemAlive Check.

  • For a stand-alone Database it is the Check Status of the DBCONNECT Check.