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.

Service Hours in Avantra define certain parts of the week, like 24x7 or from 8 am to 6 pm 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 consists 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 settings is considered to compute the availability rate.

In Avantra, Service Level Agreements are strongly related to availability data. Usually, in the Service Level Reports the System's availability rates are calculated based on 7x24 time ranges.

Within Service Level Agreements you can define Service Hours. Once a Service Level Agreement is assigned to a certain System, this System's availability rate is calculated with respect to the defined Service Hours. Each Service Hours record itself consists of a single or multiple Time Ranges defining one or more time slices on one or more days of the week.

To create a Service Level Agreement, you need to define Service Hours (or select one of the pre-defined ones), and in order to define Service Hours, you need to define Time Ranges.

For a Service Level Agreement, you can decide if the attached Service Hours are meant to be in UTC or in local time. If they are meant to be in UTC, all System's availability rates (of the Systems having theService Level Agreement assigned) are computed based on UTC times. Otherwise, for each System, its TimeZone information is considered for availability rate computation.

If there is no TimeZone defined for a particular Server or SAP System, the TimeZone value of the Customer owning the System is considered. If this one is set neither, the local timezone of Avantra WebUI is taken into account.

Further, a Service Level Agreement requires the definition of the Committed Availability Rate. In the Service Level Reports, the System's availability rate will be reported against exactly this value.

To view Service Level Agreements, you need the View SLA Permission. In order to create, modify, or delete Service Level Agreements, Service Hours, Time Ranges, and in order to view all defined Service Hours you need the 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: