Reference: SAP System Checks

Runs the ABAP data dictionary / database consistency check inside SAP and displays the results.

If there are no inconsistencies the check is Ok, otherwise, a Warning will be reported.

Certain indexes may be excluded from the check by using ABAP_DD_DB_Exclude.

The check consists of three sub-checks.

For all three sub-checks, you may use BatchInputClientExclude to exclude clients, and BatchInputQIDExclude to exclude sessions by Queue-ID. By default client 000 and 066 are excluded.

The check verifies the status of BatchMan, a 3^rd-party product of HONICO. (If installed in your ABAP SAP System.)

BatchManStat will first look if BatchMan is active; if so it will further check if the BatchMan master job is active. Additionally, it will output the date and time of the last run of the master job. The check status is Ok if both, BatchMan itself and its master job are active. Otherwise, the check status is Critical.

If you are not using BatchMan but the Avantra Agent has found it in your SAP System and the BatchManStat check is Critical you may want to disable the check completely.

This check retrieves erroneous outbound business communication services records as displayed by SAP transaction SOST. BCS_OutboundErrors works exactly as the RealTime Monitoring check BCS_OutboundErrStat, except that the timespan is always to the previous Daily Check record. Please see BCS_OutboundErrStat for a description.

This check retrieves erroneous outbound business communication services records as displayed by SAP transaction SOST. BCS_OutboundErrStat check is designed to retrieve data of all clients found in an SAP system, no matter which client is used for RFC by the Avantra Agent. Per default, BCS_OutboundErrStat checks in all clients except 000 and 066. You may change this behaviour using BcsOutboundClientMode, which can be set to Blacklist or Whitelist. Blacklisted or whitelisted clients are specified by the BcsOutboundClientList parameter.

If the number of erroneous records in last BcsOutboundErrStatTimeSpan minutes is above configurable thresholds BcsOutboundErrStatNumWarn or BcsOutboundErrStatNumCrit, the status of the check is set to the corresponding status. This check is accompanied by Daily Check BCS_OutboundErrors, which checks erroneous records back to the previous Daily Check schedule.

Each client is checked separately against the thresholds. The client column of the result table is either colored with no color, meaning there are erroneous records but the number is below Warning and Critical thresholds, yellow, meaning the number of erroneous records are equal to or above the Warning threshold, or red, i.e. above the Critical threshold. The worst result per client will give the overall status of the check.

This check retrieves waiting outbound business communication services records as displayed by SAP transaction SOST. BCS_OutboundWaitStat check is designed to retrieve data of all clients found in an SAP system, no matter which client is used for RFC by the Avantra Agent. Per default, BCS_OutboundWaitStat checks in all clients except 000 and 066. You may change this behaviour using BcsOutboundClientMode, which can be set to Blacklist or Whitelist. Blacklisted or whitelisted clients are specified by the BcsOutboundClientList parameters.

If the number of waiting records is above configurable thresholds BcsOutboundWaitNumWarn and the wait time of these records exceeds BcsOutboundWaitTimeWarn minutes, the status is set to Warning. If records are found that exceed BcsOutboundWaitNumCrit in number and BcsOutboundWaitTimeWarn in time, the status is set to Critical.

Each client is checked separately against the thresholds. The client column of the result table is either colored in green, meaning there are waiting records but the wait time of each record is below BcsOutboundWaitTimeWarn. This can be normal behaviour, for instance, if waiting records are sent by a scheduled job. If the client column has no color at all, this means that there are waiting records above BcsOutboundWaitTimeWarn or BcsOutboundWaitTimeCrit but the number of them is below thresholds BcsOutboundWaitNumWarn or BcsOutboundWaitNumCrit. Yellow and red color means that there are waiting records above the corresponding time and number thresholds.

Since different send methods may require different time thresholds, for instance, if outbound requests using FAX are only sent at a certain schedule, you may use exception parameter BcsOutboundWaitTimeExceptions to define special thresholds. For syntax details, please see the documentation of this parameter. If an exception threshold is used for a record, a small info icon will be displayed beneath the waiting time.

The check retrieves the status and runtime of all Process Chain runs during the last day.

If one of the Process Chains terminates with status red, the check turns Critical. If one of the Process Chains exceeds the runtime thresholds, the check status turns to Critical or Warning, resp.

Certain Process Chains may be excluded from the check by using BWProcessChainsExclude, the Check Result for canceled (status X) Process Chains may be defined with BWProcessChainsCancelledStatus as well.

The check lists queries within an SAP BI System that exceed a configurable runtime threshold.

Reports the performance of dialog steps in an ABAP SAP System.

The check returns an alert if a certain ratio of the dialog steps runs longer than a configurable threshold (e.g. 1 second).

The ratio, as well as the runtime threshold, can be configured.

The results are listed during a time period of one day (as provided by the underlying SAP System; cannot be configured).

A minimum number of steps can be defined also. So, if there are fewer dialog steps in the monitoring period these values are not considered for the Check Result. This is to take into account that only a reasonably large number of data can provide some valuable statistics.

The check performs a test digital note download and alerts if this fails.

An overview of IDOCs status and the corresponding group is given for the previous Full Check Cycle.

If there are IDOCs in status group red, the check returns Warning. Additionally, a Warning message appears if IDOCs are found that are older than a configurable threshold.

This way, Avantra verifies if IDOCs are reorganized correctly.

The number of modified IDOCs with a status in the status group red is monitored over a configurable period of time (default is one hour). Thresholds Warning and Critical can be defined.

Monitors the status of jobs in the Java Scheduler that have run in the last 1 day (configurable by JavaJobsSelectRange). Shows a table of all jobs found, limited to 1000 entries. A job in status "Error" will turn the check to CRITICAL, a job in status "Cancelled" will turn it to WARNING.

Monitors the status of jobs in the Java Scheduler which have run in the last 60 minutes (configurable by JavaJobStatTimeSpan). Shows a table of all jobs found, limited to 1000 entries. A job in status "Error" will turn the check to CRITICAL, a job in status "Cancelled" will turn it to WARNING.

JavaSSLCertificatesValidity checks if SSL certificates are valid, considering the information of the Keystore Views configured in the NetWeaver keystore service.

If certificates are found which are about to expire, the check status will be Critical if the remaining validity period is equal to or below SSLCertificatesValidityCrit. If the remaining validity period of one or more certificates is above SSLCertificatesValidityCrit but equal to or below SSLCertificatesValidityWarn, the check status will be Warning.

Expired certificates are reported for SSLCertificatesValidityIgnore days. After SSLCertificatesValidityIgnore days they will be ignored and no longer contribute to the check status, however, they are still reported in the check result output.

All aborted jobs within the last Full Check Cycle; are counted, unless excluded by the JobAbortExclude Monitoring Parameter or excluded by JobUsersExclude Monitoring Parameter.

If the number of aborted jobs exceeds JobsDailyCountWarn or JobsDailyCountCrit the check will return the corresponding check status.

The JOBSTAT check consists of two sub-checks.

All entries within the lock table are analyzed for their age. If entries are older than the configurable thresholds a corresponding Warning or Critical alert is raised.

An SAP MII transaction is considered as failed if the transaction STATUS is either Invalid, Failed, Terminated, or Exception.

An SAP MII transaction is considered as failed if the transaction STATUS is either Invalid, Failed, Terminated, or Exception.

An SAP MII long-running transaction is a transaction that is currently running, and the current runtime is longer than a threshold.

NumberRanges checks the Number Ranges of an ABAP system for its usage. It works similar to SAP standard report RSNUMHOT, however, the check is designed to retrieve data of all clients found in an SAP system, no matter which client is used for RFC by the Avantra Agent. Per default, NumberRanges checks in all clients except 066, so client 000 is included per default. You may change this behaviour using NumRangesClientMode, which can be set to Blacklist (default) or Whitelist. Blacklisted or whitelisted clients are specified by the NumRangesClientList parameter.

Per default, all Number Ranges are checked against thresholds NumRangesUsageWarn and NumRangesUsageCrit. If the usage of a Number Range exceeds the corresponding threshold, the check result will be either Warning or Critical. Per default, rolling number ranges are included in the check as well. You may change this behavior by unchecking NumRangesRollingIntervals.

To even further individualize the check behavior, you can use exclude number ranges from being checked and you can as well instruct the check to use individual thresholds as defined in SAP transaction SNUM. To exclude Number Ranges, you list them in NumRangesExclude. Excludes always work on all clients. To use individual thresholds already defined in your SAP System, you use NumRangesUseObjectDef. If you want to define individual thresholds specifically, you use the advanced NumRangesUsageEx parameter.

Please see the reference of these Monitoring Parameters for further reference.

Checks the PI Adapter Engine on the current instance for availability and selftest errors.

The check works corresponding to the Component Monitoring in the SAP Runtime Workbench. If features report a not OK status, but this is not of concern, you can exclude these features from contributing to the check status by PIExcludeSelftestFeatures.

Checks all PI Java-based Adapter Engines (central and non-central) of all PI Domains accessible on the current instance for availability and selftest errors.

The check works corresponding to the Component Monitoring in the SAP Runtime Workbench. If features report a not OK status, but this is not of concern, you can exclude these features from contributing to the check status by PIExcludeSelftestFeatures.

Checks for erroneous XML messages of the PI Adapter Engine as displayed by the Message Monitor of an SAP NetWeaver PI system. PI_AEMessages works exactly as the RealTime Monitoring check PI_AEMessagesStat, except that the timespan is always to the previous Daily Check record. Please see PI_AEMessagesStat for a description.

Checks for erroneous XML messages of the PI Adapter Engine as displayed by the Message Monitor of an SAP NetWeaver PI system for the last PIAEMessagesStatTimeSpan minutes.

If the number of erroneous messages is above configurable threshold PIAEMessagesStatNumWarn, the status is set to Warning. If the number of messages found exceeds PIAEMessagesStatNumCrit, the status is set to Critical.

Checks the PI Business Process Engines of all PI Domains accessible on the current instance for availability and selftest errors.

The check works corresponding to the Component Monitoring in the SAP Runtime Workbench. If features report a not OK status, but this is not of concern, you can exclude these features from contributing to the check status by PIExcludeSelftestFeatures.

Retrieves the status of the XI Runtime Cache as performed with transaction SXI_CACHE (Exchange Infrastructure  Configuration  XI Cache Refresh).

The check message and status corresponds to the status of the XI Cache, i.e. a red light will be displayed as Critical and yellow as warning and green as Ok.

The following table lists the check results:

Checks the status of PI communication channels. If a channel’s status is INACTIVE, UNKNOWN, or UNREGISTERED, Avantra will report a Warning check status. If a channel’s status is ERROR, Avantra will report a Critical check status. For the remaining possible status OK, Avantra’s check status will be Ok, of course. The overall check status of PI_CommChannels will be the worst status of all channels.

Furthermore, you can use Monitoring Parameters PICommChannelsErrsWarn and PICommChannelsErrsCrit to delay the time an error is reported as Warning or Critical state. Per default, an error will be reported immediately as Critical since PICommChannelsErrsCrit is set to 1. If you change the parameters, e.g. to PICommChannelsErrsWarn 2 and PICommChannelsErrsCrit 3, a channels check status will be still Ok after the first error is detected. If the error persists to the next check cycle, check status will be Warning. If it still persists to the third check cycle in sequence, check status will be Critical.

{monitoring-parameter} PICommChannelsExclude is used to exclude certain communication channels from being checked. You can exclude on all information provided by the check’s result table, i.e. _Party, Service, Channel, Activation State, and Channel State.

This check verifies if the basic infrastructure for PI/XI monitoring is up and running.

This check returns Critical when the SAP Runtime Workbench is not accessible using the Avantra J2EE user. This can be due to a lack of permissions of the user or due to an incompletely configured PI system.

Additionally, PI_CONNECT serves as a master check for all other PI checks (except PI_CACHE), so if this check fails, all the other dependent checks will return Unknown.

Checks for erroneous XML messages of the PI Integration Engine as displayed by ABAP transaction SXMB_MONI. PI_IEMessages works exactly as the RealTime Monitoring check PI_IEMessagesStat, except that the timespan is always to the previous Daily Check record. Please see PI_IEMessagesStat for a description.

Checks for erroneous XML messages of the PI Integration Engine as displayed by ABAP transaction SXMB_MONI when queried for XML messages in status group Errors for the last PIIEMessagesStatTimeSpan minutes.

PI_IEMessagesStat check is designed to retrieve data of all clients found in an SAP system, no matter which client is used for RFC by the Avantra Agent. Per default, PI_IEMessagesStat checks in all clients except 000 and 066. You may change this behaviour using PIIEMessagesClientMode, which can be set to Blacklist or Whitelist. Blacklisted or whitelisted clients are specified by the PIIEMessagesClientList parameter.

If the number of erroneous messages is above configurable threshold PIIEMessagesStatNumWarn, the status is set to Warning. If the number of messages found exceeds PIIEMessagesStatNumCrit, the status is set to Critical.

Each client is checked separately against the thresholds. The client column of the result table hash either no color, meaning there are erroneous messages but the number for this client is still below PIIEMessagesStatNumWarn. Yellow and red color means that the number of erroneous messages exceeds the corresponding thresholds.

Checks the PI Integration Directories of all PI Domains accessible on the current instance for availability and selftest errors.

The check works corresponding to the Component Monitoring in the SAP Runtime Workbench. If features report a not OK status, but this is not of concern, you can exclude these features from contributing to the check status by PIExcludeSelftestFeatures.

Checks the PI Integration Engines of all PI Domains accessible on the current instance for availability and selftest errors

The check works corresponding to the Component Monitoring in the SAP Runtime Workbench. If features report a not OK status, but this is not of concern, you can exclude these features from contributing to the check status by PIExcludeSelftestFeatures.

Checks the PI Integration Repositories of all PI Domains accessible on the current instance for availability and selftest errors

The check works corresponding to the Component Monitoring in the SAP Runtime Workbench. If features report a not OK status, but this is not of concern, you can exclude these features from contributing to the check status by PIExcludeSelftestFeatures.

Checks all J2SE-based adapter engines of all PI Domains accessible on the current instance for availability and selftest errors

The check works corresponding to the Component Monitoring in the SAP Runtime Workbench. If features report a not OK status, but this is not of concern, you can exclude these features from contributing to the check status by PIExcludeSelftestFeatures.

Checks the PI Mapping Runtimes of all PI Domains accessible on the current instance for availability and selftest errors.

The check works corresponding to the Component Monitoring in the SAP Runtime Workbench. If features report a not OK status, but this is not of concern, you can exclude these features from contributing to the check status by PIExcludeSelftestFeatures.

Checks the PI Runtime Workbench of all PI Domains accessible on the current instance for availability and selftest errors.

The check works corresponding to the Component Monitoring in the SAP Runtime Workbench. If features report a not OK status, but this is not of concern, you can exclude these features from contributing to the check status by PIExcludeSelftestFeatures.

Checks the PI System Landscape Directory of all PI Domains accessible on the current instance for availability.

The check works corresponding to the Component Monitoring in the SAP Runtime Workbench. If features report a not OK status, but this is not of concern, you can exclude these features from contributing to the check status by PIExcludeSelftestFeatures.

Checks the number of queued records for all inbound qRFC queues as done with SAP qRFC Monitor (SAP transaction SMQ2 for inbound queues). If the number of waiting records is above the Warning or Critical threshold a corresponding alert is raised.

The queue state is not monitored with this check, but with QRFC_IN_ERRQ.

It is possible to exclude queues from being monitored by defining QRFCInQueueExclude.

Checks inbound qRFC queues as done with SAP qRFC Monitor (SAP transaction SMQ2 for inbound queues).

If the number of hanging or erroneous queues is equal to or above QRFCInQueueHangWarn but below QRFCInQueueHangCrit, the check status will be Warning. If the number of hanging or erroneous queues is higher than QRFCInQueueHangCrit, a critical alert is raised.

It is possible to exclude queues from being monitored by defining QRFCInQueueExclude.

Checks the number of queued records for all outbound qRFC queues as done with SAP qRFC Monitor (SAP transaction SMQ1 for outbound queues). If the number of waiting records is above the Warning or Critical threshold a corresponding alert is raised.

The queue state is not monitored with this check, but with QRFC_OUT_ERRQ.

It is possible to exclude queues from being monitored by defining QRFCOutQueueExclude.

Checks outbound qRFC queues as done with SAP qRFC Monitor (SAP transaction SMQ1 for outbound queues).

If the number of hanging or erroneous queues is equal to or above QRFCOutQueueHangWarn but below QRFCOutQueueHangCrit, the check status will be Warning. If the number of hanging or erroneous queues is higher than QRFCOutQueueHangCrit, a critical alert is raised.

It is possible to exclude queues from being monitored by defining QRFCOutQueueExclude.

This check is to access the SAP support backbone and monitor whether the current SAP system meets all necessary prerequisites. It forms a list of the actions to allow support services delivery to the given SAP system. This includes note installation, software patches, etc. It is executed only on systems with ABAP component ST-A/PI.

This check collects the information about SAP Notes implemented in the system. The data includes the note number, note version, implementation status, etc. If at least one note is in the Incompletely implemented status, the check result is Critical. If such notes are not found, but there are some in the Obsolete version implemented status, then the check result is Warning. If all notes are in the Completely implemented or Obsolete status, then the result is Ok.

This check consist of two sub-checks:

The check verifies the number of short dumps over a configurable period of time (default one hour).

If Warning or Critical thresholds are exceeded, a corresponding Warning or Critical Check Result is returned.

You can define a list of short dumps that shall be excluded from this check by using ShortDumpExclude, e.g. you may want to suppress TIME_OUT short dumps which may happen once a user maximum dialog idle time has been exceeded.

The check compares the number of records in the source and target tables. It is generated for each configuration name/MTID found in the SLT system, however, you can use the SLTSrcTrgtConfigName and SLTSrcTrgtMtId parameters to filter them. You can also set a WARNING/CRITICAL threshold for the difference between the source and target line numbers.

We currently only support a combination of an SAP source system and a HANA HDB target system. Therefore, if the SLT configuration has unsupported source and target types, an error message will be returned.

The check returns the status for each corresponding SLT configuration - SLT_Status_<Configuration_name> - along with the available sub-check statuses. Considered configurations can be filtered using the SLTStatusConfigName parameter. If the connection to the replication source or (and) replication target is broken, then the check result is CRITICAL, otherwise - OK. If the connection is inactive, the check result will be UNKNOWN with the message “Configuration <configuration name> is not inactive”.

The check retrieves the number of unprocessed records for each table to be replicated. A separate check entry is created for each SLT configuration available in SLT system - SLT_UnprocessedRecords_<configuration_name>. In case the configuration is inactive, the check result will be UNKNOWN with the message “Configuration <configuration name> is not inactive”.

The check allows you to get the number of SLT jobs completed over the time periods defined by parameters SLTIucJobsMinutesWarn and SLTIucJobsMinutesCrit. If there are no finished jobs during the SLTIucJobsMinutesCrit period, the check result is CRITICAL. If there are no finished jobs during the SLTIucJobsMinutesWarn period, the check result is WARNING. Currently, only finished jobs are taken into account, active jobs are not selected.

The check retrieves the Solution Manager LMDB consistency status. The check status is set dependent of the rating number where 1 = Ok, 2 = Warning and 3 = Critical. This check is enabled automatically when a Solution Manager sytem is detected.

This check reflects the statuses of the mandatory scenarios of SAP Solution Manager (i.e. System Preparation, Infrastructure Preparation, Basic Configuration). The overall check status will show Critical if some of the mandatory configurations contain errors or Warning if some contain warnings or configurations that were not performed. This check is enabled automatically when a Solution Manager sytem is detected.

This check consist of two sub-checks:

This check consists of two sub-checks:

SSLCertificatesValidity checks if SSL certificates are valid, just the same way as transaction STRUST or the report SSF_ALERT_CERTEXPIRE would do.

The output of the check is similar to report SSF_ALERT_CERTEXPIRE. If certificates are found, which are about to expire, the check status will be Critical if the remaining validity period is equal to or below SSLCertificatesValidityCrit. If the remaining validity period of one or more certificates is above SSLCertificatesValidityCrit but equal to or below SSLCertificatesValidityWarn, the check status will be Warning.

Expired certificates are reported for SSLCertificatesValidityIgnore days. After SSLCertificatesValidityIgnore days they will be ignored and no longer contribute to the check status, however, they are still reported in the check result output.

Checks for erroneous XML messages of the PI Integration Engine as displayed by ABAP transaction SXMB_MONI. SXMB_Messages works exactly as the RealTime Monitoring check SXMB_MessagesStat, except that the timespan is always to the previous Daily Check record. Please see SXMB_MessagesStat for a description.

Checks for erroneous XML messages of the PI Integration Engine as displayed by ABAP transaction SXMB_MONI when queried for XML messages in status group Errors for the last SXMBMessagesStatTimeSpan minutes.

SXMB_MessagesStat check is designed to retrieve data of all clients found in an SAP system, no matter which client is used for RFC by the Avantra Agent. Per default, SXMB_MessagesStat checks in all clients except 000 and 066. You may change this behaviour using SXMBMessagesClientMode, which can be set to Blacklist or Whitelist. Blacklisted or whitelisted clients are specified by the SXMBMessagesClientList parameter.

If the number of erroneous messages is above configurable threshold SXMBMessagesStatNumWarn, the status is set to Warning. If the number of messages found exceeds SXMBMessagesStatNumCrit, the status is set to Critical.

Each client is checked separately against the thresholds. The client column of the result table hash either no color, meaning there are erroneous messages but the number for this client is still below SXMBMessagesStatNumWarn. Yellow and red color means that the number of erroneous messages exceeds the corresponding thresholds.

The check verifies if the minimum requirements for the technical operation of a SAP System are fulfilled from a monitoring perspective.

These requirements depend on the nature of the SAP System, but basically there has to be a minimum number of SAP Instances available, i.e. they have to be detected and the corresponding connect checks have to succeed. If one of the required SAP Instances is not available SystemAlive will report an error message.

The following list describes the conditions that have to be fulfilled for the SystemAlive check to be Ok:

The Monitoring Parameter SysAliveIncompleteTimeCrit plays an important role once it comes to a cluster switch. If a cluster does switch, one of the required SAP Instances may vanish until the cluster switch has finally finished. To cover these situations the SystemAlive check first turns to Warning. If the SAP Instances does not come up withinSysAliveIncompleteTimeCrit minutes, the check turns to Critical.

Checks the return code of imported transport requests and works exactly like the RealTime Monitoring check TMS_ImportStat, except that the timespan is always to the previous Daily Check record and non-imported transport requests are shown. Please see TMS_ImportStat for a description. Please note that TMS_Imports uses its own Monitoring Parameters TMSImportReturnCodeCrit and TMSImportReturnCodeWarn.

Checks the return code of imported transport requests of last TMSImportStatTimeSpan minutes. If one or more imports are finished with return code ≥ 8, the check status will be Critical. If no import with return code ≥ 8, but one or more ≥ 4 are found, the check status will be Warning. Otherwise, the check status will be Ok.

This default behaviour can be changed by Monitoring Parameters TMSImportStatReturnCodeCrit and TMSImportStatReturnCodeWarn. For example, you might not want to have warning return codes to contribute to the check result. To do this, you simply change Monitoring Parameter TMSImportStatReturnCodeWarn from the default value 4 to off. Or you might not want to have erroneous return codes starting from 8 be reported as critical result for development or quality assurance systems but as warning. To achieve this, you would change TMSImportStatReturnCodeCrit from 8 to off and TMSImportStatReturnCodeWarn from 4 to 8. See more examples in table below.

This check is accompanied by Daily Check TMS_Imports, which checks transport request imports back to the previous Daily Check schedule.

This check performs various TMS-related tests.

Checks transport requests on the general compliance rule that owner and importer of a transport request are different users. If transport requests are found with the owner of the transport request equal to the user importing it, the Check Result will show the corresponding transport requests and the status will be Warning.

Displays an overview of all incoming tRFC records (see SAP transaction SM58) and displays the amount of records and the date / time of the oldest record for each different tRFC state.

The check will return a Warning if there are incoming tRFC records older than a configurable period of time (default one day).

Displays an overview of all outgoing tRFC records (see SAP transaction SM58) and displays the amount of records and the date / time of the oldest record for each different tRFC state.

The check will return a Warning if there are outgoing tRFC records older than a configurable period of time (default one day).

Checks the status of outgoing transactional RFC records (see SAP transaction SM58) over a configurable period of time (default is one hour). If the sum of records with status CPICERR, SYSFAIL, or SYSLOAD is greater than the Warning or Critical threshold, a corresponding alert is raised.

If the number of unprocessed update records older than UpdateQueueAgeCrit seconds exceeds UpdateQueueCountCrit the check turns Critical.

Otherwise, if the number of unprocessed update records older than UpdateQueueAgeWarn seconds exceeds UpdateQueueCountWarn the check turns Warning. Otherwise, the check is Ok.

All erroneous or unprocessed update requests within the Full Check Cycle are reported as Warning messages.

The number of erroneous update records is checked during a configurable period of time (default is one hour). Warning and Critical thresholds may be defined.

If the SAP System's global update switch as displayed in transaction SM13 is deactivated, the check turns Critical. The reason why the updating has been deactivated is reported in the check message.

Checks SAP standard users SAP*, DDIC, SAPCPIC, TMSADM, and EARLYWATCH for well-known standard passwords.

If the basis release of your SAP system is 7.00 onwards, the results of the original SAP report RSUSR003 are reported using the advanced check result format including tabular details for each checked user.

The table displayed corresponds to the one displayed by RSUSR003, except that a new column Excluded is added to show which users have been excluded by Monitoring Parameter UserPWDAuditExclude.

If the Password Status of one or more users is reported in red color by RSUSR003, the check result will be Critical. If a user with red color Password Status is locked, USER_PWD_AUDIT will return a Warning status and the user is marked in yellow color in the result table.

Furthermore, the lock status is checked. If one of the standard users is locked due to unsuccessful login attempts, by default a Warning is raised. This behaviour can be controlled by Monitoring Parameter UserPWDAuditFailedLogonSeverity: if this parameter is set to Critical a user locked due to unsuccessful login attempts will be reported as Critical.

If UserPWDAuditFailedLogonSeverity is set to OK (not recommended), a user locked due to unsuccessful login attempts will not contribute to the check result.

For SAP systems prior to 7.00, the check result will use a text table presentation and the following check logic which does not depend on RSUSR003. If a users password is set to a well-known standard password, the check will return a Warning status, unless the user is excluded by parameter UserPWDAuditExclude.

This check additionally verifies if the users exist in each client. If the user SAP* does not exist, the check will return a Warning status (unless the profile parameter login/no_automatic_user_sapstar is set to 1) since login with password pass may still be possible.

The user does not exist message is suppressed for user EARLYWATCH for all clients other than 066.

The average dialog response time of the SAP System during the last Full Check Cycle is reported and compared with the Warning (default 1000 ms) and Critical (default 2000 ms) thresholds. If responses times are higher than the defined thresholds, the check will return the corresponding Check Result.

Only transactions with at least DialogPerfMinStepCount steps are considered.