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

Central | An SAP Web Application Server ABAP instance. The one marked as Central by Avantra is usually the primary Application Server as well. The term Central is still used by Avantra to indicate that this is the Application Server where the SAP System related checks are executed.
Central+Java | Same as the SAP Web Application Server ABAP CENTRAL instance above, but includes a Java stack as SAP NetWeaver Add-In installation. Central+Java instance types are deprecated by SAP. It is recommended to run separate ABAP or Java systems.
Dialog | An instance of an SAP Web Application Server ABAP that is not the central instance
Dialog+Java | An instance of an SAP NetWeaver Add-In installation with ABAP and Java stack that is not the central instance.
Java | An instance of an SAP Web Application Server Java.
Java_Scs | A (Java) SAP Central Services instance.
Abap_Scs | An ABAP SAP Central Services instance.
Trex | A TREX engine.
Web Dispatcher | An SAP Web Dispatcher instance.
Abap_Scs with Web Dispatcher | An ABAP SAP Central Services with integrated Web Dispatcher.
Enqueue Replication Server | An Enqueue Replication Server.

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

ABAP or ABAP-only instance | An instance of type Central or Dialog or Abap_Scs.
ABAP+Java instance | An instance of type Central+Java or Dialog+Java.
Java or Java-only instance | An instance of type Java or Java_Scs.

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.

## 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 - Supported Basis Releases

## Supported SAP Basis Releases

The Avantra Agent monitors the following SAP Basis Releases:

- Releases 4.6C, 4.6D

- Release 6.40

- Releases 7.0x, 7.1x, 7.2x, 7.3x, 7.4x, 7.5x, 7.7.x

Unicode Kernels are supported as well.

## 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 main 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 authorizing 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

Either a Physical Server or a Virtual Cluster Server.

A Physical Server in terms of Avantra is either:

- a real server that runs a copy of the supported operating systems

- a system virtual machine (or hardware virtual machine) running its own operating system (the so-called guest operating system)

- a partition in operating system-level virtualization (virtual environment, virtual private server, guest, zone, container, jail, etc.).

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.

## Service Authentication

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

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.

## Service Level Agreement

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.

## Maintaining Service Level Agreements

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.

### Creating a Service Level Agreement

To create a new Service Level Agreement, perform the following steps:

1. Select Reporting Service Level Agreements from the top-level menu. Choose New from the toolbar.

2. Fill in Name and push the New button.

3. Fill in an optional Description and define the percentage (without the % sign) for the Committed Avail.~Rate

4. Select a value from the Service Hours list. See also Service hours.

5. If you want the Service Hours to be treated as UTC time, flag the UTC check box.

6. Push Apply.

### Assign a Service Level Agreement

Finally, you need to assign the defined Service Level Agreement to some Systems, either Servers, SAP Systems, Databases or a combination of these:

1. Choose Systems SAP Systems, or Systems SAP Instances, or Systems Databases, or Systems Servers, or Systems SAP Business Objects, or Systems Cloud Services from the top-level menu.

2. Select the list items and choose More Assign SLA.

3. Select the appropriate Service Level Agreement and push the Assign button.

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

## Generating Service Level Reports

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:

- Reports: use this tab to view and create Service Level Reports.

- Templates: use this tab to manage Service Level Report templates.

  Templates are used to define generation settings that can be reused.

- Remarks: use this tab to create Service Level Report remarks.

  Remarks are special comments which are inserted into Service Level Reports.

- Styles: use this tab to create Service Level Report styles.

  Styles are used to customize the layout of the generated Service Level Report.

- Jobs: use this tab to administrate Service Level Report jobs.

  Jobs trigger the automated generation of Service Level Reports.

### Generating Service Level Reports ad-hoc

Select the first Report tab. You can find the following actions:

- Press New to create a new Service Level Report. A template can be selected which provides default settings. The Service Level Report generation dialog opens where the content of the Service Level Report can be defined. See below for more details about generation.

- Press Show to view a Service Level Report

- Press Generate Again to create a Service Level Report again. This is only available for unpublished Service Level Reports. Generating a Service Level Report again is useful in case you want to do some modifications.

- Press Publish to publish a Service Level Report. Only published Service Level Reports are visible to other users. Unpublished Service Level Reports are only visible to the user who created the Service Level Report.

- Press Rename to rename a Service Level Report.

- Press Delete to delete a Service Level Report.

The Service Level Report generation dialog provides the following configuration options:

Customer

  Define the customer to include in the Service Level Report. You can select the Include sub customers checkbox to include also the sub customers. Only systems which belong to this customer can be included in this report.

Select Systems

  To include all systems from the selected customer select the radio button All systems. To include only systems with a specific system role, select Select by System Role. Select Advanced Selection to define a specific selection of systems to include in the report.

Time Period

  This can be either the previous month, or any other month in the past, or an arbitrarily defined period in time. Choose Last Month, Select Month, Select Month(s), or Select Day and make further selections accordingly.

Remark

  Include the remarks defined for this customer in the report. See below.

Summary of Availabilities

  Include a chapter with a summary of system availabilities. Select the checkboxes to exactly define what to include in the report.

Business Services

  Include a chapter about Business Services.

Servers

  Include a chapter about the monitored servers. You have several checkboxes to define which collected data to include.

SAP Systems

  Include a chapter about the monitored SAP Systems. You have several checkboxes to define which collected data to include.

Databases

  Include a chapter about the monitored Databases. You have several checkboxes to define which collected data to include.

Changes

  Include a chapter about the system changes. You have several checkboxes to define which data to include.

RealTime Monitoring

  Include a chapter with RealTime Monitoring check results. You can include All RTM Checks or a selection, which is the recommended approach.

  | Please be aware that this option will always report the latest RealTime Monitoring results, no matter which Time period you choose for other data. This is indicated by a timestamp in the RealTime Monitoring section of the Service Level Report.

  You may use the option Group checks by check name to report a sub-section for each check name. Otherwise, it will be a single section with all checks being sorted alphabetically.

Daily Checks

  Include a chapter with the daily check results. You have the option to include all daily check results, daily checks which have a specific status, or only daily checks for a specific check type.

Customer Users

  Include a chapter with all users who have access to this customer.

Tickets

  Include a chapter with the tickets which have been opened, worked on, or closed within the given time period.

Hide table of content

  Select the checkbox to exclude the table of content. If you want to include only some levels of the table of content, select the checkbox and set the number of levels to include.

Ignore downtimes if less than

  In order to avoid very short Downtimes being shown in the availability statistics, you may select this checkbox. Downtimes less than the defined number of minutes are ignored and considered as uptime.

Group systems by application type

  Select this option to create chapters for each application type. This will introduce an additional level in the table of content.

Exclude performance data for days which are not covered by SLA

  By default, all collected performance data is used for the report. Select this checkbox if you only want to include performance data that was collected when an SLA is defined and active.

Don’t show forecast for performance charts

  By default, the reported data is extrapolated into the future for those types of resources where it is useful. The extrapolation is suppressed if you set this flag.

Rename document

  You have the option to define a name for the generated report.

Publish SLR automatically after generation

  Select this checkbox to publish the report. If the report is not published, the report is not visible to other users, only the user who created the report can view see the report. It is not recommended to publish a report during testing and fine-tuning.

| Published reports are stored in the Avantra database. Unpublished reports are stored in the file system.

Apply style

  Select a style to apply to the report. Styles can be defined in the Styles tab, see below.

Once you configured what to include in the report, press Generate SLR. If you did not set all mandatory settings, a message indicating the reason is shown. If all mandatory settings are set, the Generating SLR dialog is opened which shows you the progress of the generation. During generation, you have the option to stop the generation, or you can send the generation to the background. Sending a generation to the background closes the generation dialog and you can continue to work in Avantra WebUI. You will find the report after a time in the Reports tab. Once the report is generated you have the option to view the report, press Close and open SLR.

You need the `Generate SLRs` Permission in order to generate Service Level Reports.

### Generating Service Level Report templates

Service Level Report templates define a set of settings used to generate a Service Level Report. Typical settings are the customer, the monitored systems to include, which performance data to include, and many more. It is highly recommended to create a set of templates that can be used to create a Service Level Report. Templates are also used for the automated generation of Service Level Reports.

Select the second Templates tab.

You can find the following actions:

- Press New to create a new template. After setting a name for the template, a dialog to define the template settings is opened. The template can be saved to be used later for Service Level Report generation.

- Press Open to view or edit a template.

- Press Copy to copy a template and give a new name.

- Press Delete to delete a template.

The Service Level Report template dialog is the same as the Generate SLR dialog with two more form fields. You have the option to set a name for the template and a Shared checkbox that indicates whether this template is shared or not. Shared templates are visible and useable by other users. Templates which are not shared are only visible by the user who created the template. Templates must not contain all mandatory fields which are required to create a Service Level Report. If you later select the template to create the report, you must set the remaining mandatory fields.

You need the `Edit SLR Templates` Permission in order to create, modify, and delete Service Level Report Templates.

### Managing Service Level Report Remarks

The intended use for SLR Remarks is to include customized free text messages in Service Level Reports. Assume you have had a special incident during the reporting period that is supposed to be part of the Service Level Report.

There is a default SLR Remark assigned to all customers. This remark can be modified, and — of course — you can select if it will be included in the Service Level Report during the generation process. The default SLR Remark cannot be deleted.

You may also define new SLR Remark records, but at most one per customer. If there is a customer assigned SLR Remark (and you choose to include SLR Remarks during Service Level Report generation), this one will be included instead of the global one.

- Press New to create a new remark.

- Press Open to view or edit a remark.

- Press Delete to delete a remark.

You need the `Edit SLR Remarks` Permission in order to create, modify, and delete Service Level Report Templates.

### Managing Service Level Report Styles

Service Level Report styles can be used to customize a Service Level Report. Avantra provides a default style, but if you want to change colors, fonts, images, and more, you can do so with styles.

In the Service Level Report generation dialog, a style can be selected.

- Press New to create a new style.

- Press Open to view or edit a style.

- Press Delete to delete a style.

| You do not have to define all available style settings in the style definition dialog. Only define the settings where you want to modify the default settings. Settings that are not changed in a style will always use the built-in default styles. Styles have no influence on the content and data in the report.

You must have either the `Administrator Role` or the `Super Administrator Role` assigned in order to manage Service Level Report Styles.

### Managing Service Level Report Jobs

Service Level Report jobs are used to automate the creation of Service Level Reports.

A Service Level Report job is based on a schedule that defined when to create the report and a template that defines what to include in the report.

- Press New to create a new job.

- Press Open to view or edit a job.

- Press Delete to delete a job.

SLR Jobs are configured in the SLR Job Details dialog. The following options can be set:

Active

  Select this checkbox to actually execute the job based on the schedule. SLR jobs that are not active are not executed.

Name

  Set a name for the job.

SLR Template

  Select the template which defines the content and data to include in the report. Make sure that the template contains all mandatory settings. If the template does not contain all mandatory settings, the job cannot create the Service Level Report.

Customer

  Set the customer (or override the customer from the template) to be used in the report.

Schedule

  Click Edit to define a schedule when the job runs and create the Service Level Report.

Last

  Select the number of months, weeks, or days to include in the report.

  | A time period in the SLR template is ignored from the SLR job.

  An SLR job will always calculate a new time period based on the current execution time. For example: if you want to create a Service Level Report on the 2nd day of the month which includes data from the previous month, then create a schedule, select Monthly, select Day, and choose 2. For Last type 1 and select months.

Publish

  Check to publish the Service Level Report into the database and to make it visible to other users.

Copy to folder

  Check to copy the generated report to the specified folder. Please make sure that Avantra has write permission on this folder. You can use macros (%%CUSTOMER%, %%YEAR%%, %%MONTH%%, %%DAY%%) for the folder. Avantra will create that folder if it does not exist.

Send Email

  Check Send Email to send the Service Level Report to an email receiver. Set the following email options. The Service Level Report will be inserted as an attachment to the email.

  - From email address which is used as sender.

  - To email address which defines the recipient.

  - CC / Bcc email address which defines CC and BCC recipients.

  - Subject the email subject.

  - Body the email body.

You must have either the `Administrator Role` or the `Super Administrator Role` assigned in order to manage Service Level Report Jobs.

To define mail settings for your automatic reports, navigate to Administration Settings Avantra Master and verify the following fields: Mail.from, Mail.host, Mail.password, Mail.port, and Mail.user. In case your outgoing email server requires additional encryption, please also set the value for the fields Mail.ssl, Mail.ssl-port, Mail.tls.

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

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

## System Change Auto Detection

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

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

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

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