S

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.

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

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:

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.

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.

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

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.

Either a Physical Server or a Virtual Cluster Server.

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.

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.

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.

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.

+

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.

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

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.

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.

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 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 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:

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.

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