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.

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

Avantra supports the following SAP Instance Types:

In addition to these terms we also use the following grouping terms:

For those SAP Systems that do not have a primary application server (i.e. a classical Central SAP Instance), Avantra chooses one to be considered central. This SAP Instance is performing the monitoring of the SAP System. It is flagged with a  icon.

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 monitors the following SAP Basis Releases:

Unicode Kernels are supported as well.

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.

A Physical Server in terms of Avantra is either:

In other words, if it looks like a real server from the point of view of its users, it is called a Physical Server in Avantra.

If you want to manage or monitor a Physical Server you need to install an Avantra Agent on it.The same holds true if you want to define an End Point on it.

In Avantra, a Physical Server refers to anything that has an operating system installed and running an Avantra Agent. In the Cloud context, these are usually “instances” or “virtual machines”.

For VMware, installations on ESXi servers are supported as well as the cloud offerings VMware Engine on GCP and VMware Cloud on AWS. Even if installations on ESXi are not strictly cloud resources, Avantra handles them in the same way.

Avantra automatically detects if it is running in a Cloud Server. If so, and if Cloud Authentication is configured properly, you can start and stop Cloud Servers from the UI, within Maintenance Windows, and using Notifications.

In case Avantra detects a Cloud Server, it needs to access the API of the corresponding cloud provider in order to provide automation options, e.g. to stop and start these Cloud Servers. For VMware, the API is provided by the VMware vCenter managing the virtual machines in question.

Servicezeiten in Avantra definieren bestimmte Teile der Woche, wie z. B. 24x7 oder von 8 bis 18 Uhr an jedem Werktag usw.

Sie können in Service-Level-Vereinbarungen, Filtern und Parameter Sets verwendet werden.

Sie können Service-Level-Vereinbarungen[[sla,SLA] definieren und diese Vereinbarungen Servern und/oder SAP-Systemen zuweisen. Eine Service-Level-Vereinbarung besteht in erster Linie aus einer Definition der Servicezeiten und einer zugesicherten Verfügbarkeitsrate.

Bei Systemen, denen ein Service-Level-Agreement zugewiesen ist, werden bei der Erstellung des Service-Level-Berichts die Verfügbarkeitsdaten innerhalb der Servicezeiten (anstelle der standardmäßigen 7x24) berücksichtigt und die berechnete Verfügbarkeitsrate mit der zugesagten Verfügbarkeitsrate verglichen.

Bei Service-Level-Vereinbarungen können Sie auch wählen, ob die Servicezeiten in der lokalen Systemzeit oder in UTC definiert werden. Wenn sie in der lokalen Systemzeit angegeben sind, wird jede der Zeitzoneneinstellungen des Systems zur Berechnung der Verfügbarkeitsrate herangezogen.

In Avantra sind Service Level Agreements eng mit availability data verknüpft. In der Regel werden in den Service Level Report die availability des Systems auf der Grundlage von 7x24-Zeitbereichen berechnet.

In Service Level Agreement können Service Hours definiert werden. Sobald eine Service Level Agreement einem bestimmten System zugewiesen ist, wird die availability dieses Systems unter Berücksichtigung der definierten Service Hours berechnet. Jeder Service Hours-Datensatz selbst besteht aus einem oder mehreren Zeiträumen, die eine oder mehrere Zeitabschnitte an einem oder mehreren Wochentagen definieren.

Um eine Service Level Agreement zu erstellen, müssen Sie Service Hours definieren (oder eine der vordefinierten auswählen), und um Service Hours zu definieren, müssen Sie Zeitbereiche definieren.

Bei einer Service Level Agreement können Sie entscheiden, ob die angehängten Service Hours in UTC oder in Ortszeit angegeben werden sollen. Wenn sie in UTC angegeben werden sollen, werden alle availability von System (der System, denen die Service Level Agreement zugewiesen ist) auf der Grundlage von UTC-Zeiten berechnet. Andernfalls wird für jedes System die Information TimeZone für die Berechnung der availability berücksichtigt.

Wenn für einen bestimmten Server oder SAP System keine Zeitzone definiert ist, wird der Zeitzonenwert des Customer, dem das System gehört, berücksichtigt. Wenn auch dieser nicht festgelegt ist, wird die lokale Zeitzone von Avantra WebUI berücksichtigt.

Darüber hinaus erfordert ein Service Level Agreement die Definition der Committed Availability Rate. In den Service Level Reports wird die availability-Rate von System mit genau diesem Wert verglichen.

Um Service Level Agreement anzuzeigen, benötigen Sie die View SLA Permission. Um Service Level Agreement zu erstellen, zu ändern oder zu löschen, Service Hours, Zeiträume und um alle definierten Service Hours anzuzeigen, benötigen Sie die Edit SLA Permission.

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 WebUI 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 PDF format and stored in the Avantra Database. Service Level Reports are generated automatically based on a schedule and can be sent to email addresses.

In Avantra WebUI, Service Level Reports can be generated manually or automatically based on a schedule.

Select Reporting  Service Level Reports from the top-level menu to create and manage Service Level Reports. There are five tabs:

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 specific customer. This way, solution documents have access control since documents can only be viewed by users who have the necessary permissions 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.

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 an 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 provides a built-in Change Management solution allowing Customers to request changes on their Systems. Many of the System changes are recorded automatically using 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 be 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 returning 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: