# Cloud Service - Custom Checks

Here you will find detailed information about Custom Checks for Cloud monitored objects.

Custom checks are chosen, adapted and deployed by you for one or more monitored objects and they are designed to allow quick and easy fulfilling of business monitoring requirements. Avantra custom checks are a mix of no-code, low-code and pro-code extensions to the Avantra AIOps platform. Each monitored object type has a number of custom check capabilities.

| All custom checks within Avantra have a number of standard or common attributes. For more information please review our page on Custom Checks.

## RUN_JS

Description

RUN_JS is a very powerful Custom Check type, which combines several different ways to retrieve data and evaluate the results using JavaScript. RUN_JS can easily access ready-to-use objects. For example, established RFC connections to SAP ABAP systems, established database connections, an OS object to run commands, or make HTTP requests to Cloud Services. This custom check type can be used to generate comprehensive check results, including sortable tables, that can even combine different sources of data retrieval.

| The RUN_JS custom check is a very powerful tool. Data retrieval by RFC, SQL, OS, or HTTP is executed using the permissions you have provided for the corresponding user. You can gain access to sensitive data if RFC, database, or OS user permissions are not restricted. Use this custom check at your own risk. Avantra shall not be liable for any direct, indirect, special, incidental, or consequential damages arising from the use of this custom check. Nor can we provide any support for designing data retrieval and writing evaluation scripts.

| The RUN_JS custom check supports ECMAScript 2019 for Avantra Agents 20.11 and higher and ECMAScript 5.1 for older versions. Starting with Avantra 20.11.5, this custom check type depends on the global Avantra server setting Security.EnableOSCodeExec.

The check evaluation logic is provided by a (usually small) JavaScript program. This script can access objects which are provided by the Avantra Agent, so the programmer can focus on the check logic and not worry about establishing connections, etc.

To script the evaluation logic, users of this check type need to be familiar with the built-in variables and API to use them, as described in section API Documentation below.

The RUN_JS custom check can be created for any monitored object type, however, certain built-in variables are only available in the context of the corresponding system type, i. e. an RFC connection to an ABAP system is only available in the context of SAP systems and SAP instances.

Apart from the examples provided in the API Documentation below, see also solution document RUN_JS Custom Check Examples, which contains ready-to-use examples for download.

| You need a Java Virtual Machine 1.8.0_65 or higher in order to make use of all functions of this Check.

Reference Data

Managed Object | Dynamic Group or Static Group of Servers, SAP Instances, SAP Systems, stand-alone Databases, Cloud Services
Depends on | AGENTALIVE
Monitoring Parameter | RunJSAllowDBWrite

Configuration

Script

  The JavaScript program providing the check data retrieval and evaluation logic. See section API Documentation.

Script timeout

  Define a time values, in seconds, for the timeout of the script. If no value is defined, the default cycle time is used as for the timeout.

Return Timeout as

  If a timeout occurs, defined how the timeout is reported. Select from `OK, WARNING, CRITICAL, UNKNOWN`. `blank` is the default state of the dropdown as shouldn’t be used.

Report Execution Time

  If this option is enabled, the time to run the script is appended to the check result text. This might be useful to check if the performance of a script is good.

Execute Test Run

  Starting with Avantra Version 21.11, you can run tests for newly created RUN_JS checks on the selected Agent directly from the Avantra WebUI. This feature does not require saving or activating the check, i.e. it can be tested before affecting the execution of the check on other systems.

  To test your check code:

  After modifying your script in the Script field, click the Execute test run button under the check name at the top of the dialogue box. Select one or multiple system to test the check on and click the Test button to run your script directly on those selected systems.

  Although this is a testing tool, the script will execute on the systems in the same way it does in a real check execution. If the check has any side effects then these will also happen in test mode.

  This feature can be disabled by the `Security.RUNJSEnableTestExecution` setting in your Avantra Server.

## SCI_MessageLogs

Description

This custom check monitors the SAP Cloud Integration messages for all failed messages, where the statuses are either ESCALATED or FAILED.

| With the release of Avantra 25, SCI_MessageLogs replaces the existing built-in check

Reference Data

Managed Object | Cloud Server
Depends on | N/A

Configuration

Configuring this check requires you to define some General and Specific properties.

General Properties

The general properties are for defining the check, and how it is to be executed.

Field | Details
--- | ---
Custom Check Name | Mandatory field for the name of the check
Description | Description of the check
Customer | The chosen Customer
Execution | Select from either daily, RealTime Monitoring, or both. Selecting RealTime Monitoring by default will execute in the Agent basic cycle time of 5 minutes. Define a time if you do not want to use the default

Specific Properties

Specific properties defined how package(s) will be monitored. Multiple rows can be defined, allowing full customization.

Field | Details
--- | ---
Packages (wildcard * allowed) | Defines the packages to be included in the current configuration row. Wildcards (*) can be used. Multiple packages can be defined in one row by using a comma-separated list with no spaces.
Exclude packages (optional) | An optional field to define packages that are excluded in the current configuration row. Wildcards (*) can be used. Multiple packages can be defined in one row by using a comma-separated list with no spaces.
IDs (wildcard * allowed) | Defines the IDs to be included in the current configuration row. To include all IDs, set to *. Multiple IDs can be defined using a comma-separated list with no spaces. Wildcards (*) can be used.
Exclude IDs (optional) | An optional field to define IDs that are excluded in the current configuration row. Wildcards (*) can be used. Multiple packages can be defined in one row by using a comma-separated list with no spaces.
Threshold Window | The number of hours or days the current configuration row that the check uses as a time threshold to apply the Warning and Critical statuses to any matching messages in the row. This field provides the value of the time threshold. For example, if the Unit field is set to hours and this field has a value of 10, the check will look at messages during the last 10 hours.
Unit | Can be set to hours or days, and defines the period for the threshold window.
Warning | Defines the threshold for the number of messages that will set this configuration row to Warning. For example if there are 60 matching records, and the Warning threshold is set to 60 and the Critical threshold is set to 80, the check message will state the row has triggered a Warning status. The overall check result will be Warning, unless another configuration row triggers a Critical status.
Critical | Defines a threshold for the number of messages that will set this configuration row to Critical. The overall check status will always turn to Critical if one configuration row triggers a Critical status.
Tag | A free text field to add a custom reference that will appear in the check output.

| If you leave either the Warning or Critical fields as empty, the check result will be Ok. Be cautious about leaving these fields blank, unless this check is being used for informational purposes only.

The image below is an example of how to configure this check.

The image below is the results of the example.

| For existing users of the now deprecated built-in check CPI_MessageLogs, setting the SCI_MessageLogs check to have the following Specific properties in a single row will produce the same behavior.
Field | Details
--- | ---
Packages (wildcard * allowed) | *
Exclude packages (optional) | leave blank
IDs (wildcard * allowed) | *
Exclude IDs (optional) | leave blank
Threshold Window | Set to the value you set for the monitoring parameter `CPIMessageLogCheckDays`; by default, it was 21 days
Unit | Select days
Warning | 0
Critical | 1
Tag | All
The image below shows these settings.

## S4PubSecurityUsers

Description

This custom check alerts on report of business users that have specific Business Catalogs in their role, and/or specific Business Roles assigned.

If no configuration is done for this check, a tabled of all fields on all users is returned.

Reference Data

{_managed*object} | S/4HANA Cloud Public Edition
Depends on | N/A

Configuration

Security Users selection parameters

- In the Include User IDs field, define users with certain Business User IDs to include in the monitoring. Separate types by comma, and wildcards `*` are allowed.

- In the Exclude User IDs field, define users with certain Business User IDs to exclude in the monitoring. Separate types by comma, and wildcards `*` are allowed.

- In the Include Emails field, define users with certain email addresses to include in the monitoring. Separate types by comma, and wildcards `*` are allowed.

- In the Exclude Emails field, define users with certain email addresses to exclude in the monitoring. Separate types by comma, and wildcards `*` are allowed.

  You can filter either by Business Roles or by Catalogs.

- The Filter by Roles radio button, when selected, enables filtering by Business Role.

  - In the Include Roles field, define users with certain Business Roles to include in the monitoring. Separate types by comma, and wildcards `*` are allowed.

  - In the Exclude Roles field, define define users with certain Business Roles to exclude in the monitoring. Separate types by comma, and wildcards `*` are allowed.

- The Filter by Catalogs radio button, when selected, enables filtering by catalog.

  - In the Include Catalogs field, define users with a role that contains a certain Catalog to include in the monitoring. Separate types by comma, and wildcards `*` are allowed.

  - In the Exclude Catalogs field, define define users with a role that contains a certain Catalog to exclude in the monitoring. Separate types by comma, and wildcards `*` are allowed.

- For the Modified fields, select from the dropdown the option to select users within the last or NOT within the last defined amount of time. Define the time in the second field in the format `hh:mm`.

- The Lock Status dropdown is optional, and can be set to either include All, Locked or Unlocked users in the results.

- The Validity dropdown is optional, and can be set to either include All, Valid or Invalid users in the results.

Security Users check parameters

- The Threshold Logic dropdown defines how the Warning and Critical thresholds will evaluate the results and determine a check status. Define by less than or equal to (`⇐`) or greater than or equal to (`>=`).

- The Critical and Warning fields are number fields. Define the number that will be used to define the Warning and Critical thresholds. This value is dependent on the option selected for the Threshold Logic.