Docs / Monitoring / Active Alerting

Active Alerting

Threshold alerting enables pro-active notifications about connection errors when sending messages. Notifications happen via the SAP Business Workplace. A notification is only triggered when a configured threshold is exceeded — the system calculates an error rate for all calls in a configured time range, and sends an alert to the inbox if the rate is above the configured threshold.

Alerting configuration

The alerting can be configured in two dimensions:

The evaluation can either be calculated on:

The notification can be configured on:

For connection-level notification, the evaluation can be selected as either connection level or object level in the variant. Object-level notifications only support object-level evaluation.

Connection-level notificationObject-level notification
Connection-level evaluation✓
Object-level evaluation✓✓

New in Release 9.32304: option to specify different thresholds for different connections/objects, so specific alerting configurations can be defined for certain interfaces.

Active Alerting report — per-connection/per-object threshold options
Active Alerting report — configure different threshold variants per connection or object

Example configuration. Assuming you have the following connections and objects:

The different selections in the Active Alerting report resolve to the following evaluations:

Selected instancesSelected objectsEvaluated instancesEvaluated objects
Azure—AzureSales Order Change, Material Change
AzureSales Order ChangeAzureSales Order Change
Azure, SolaceMaterial ChangeAzureMaterial Change (if objects are specified, they must be specified for every instance)
Azure, SolaceMaterial Change, Delivery Notification, Invoice CreateAzure, SolaceMaterial Change, Delivery Notification, Invoice Create
——Azure, SolaceSales Order Change, Material Change, Delivery Notification, Invoice Create (if no connections/objects are selected, everything is evaluated, as in previous releases)

Set-up notification on connection level

Edit the connection instance customizing that ties together the RFC destination and the cloud connector type:

Connection instance customizing — Threshold Alerting, Agent ID and Agent Type fields
Connection instance customizing – Threshold Alerting, Agent ID and Agent Type

Set-up notification on outbound object level

Edit the outbound objects customizing:

Outbound Objects customizing — Threshold Alerting, Agent ID and Agent Type fields
Outbound Objects customizing – Threshold Alerting, Agent ID and Agent Type

Set-up linkage to notification workflow

Configure the linkage to the notification workflow:

SWE2 event linkage configuration for Active Alerting
SWE2 – event linkage for Active Alerting

Set-up job for error evaluation

Create a variant

The variant defines the customizing of the job:

/ASADEV/ACI_ACTIVE_ALERTING report selection screen
/ASADEV/ACI_ACTIVE_ALERTING – report selection screen

Report customizing options:

Once the customizing is done, Save as Variant… (Ctrl+S).

Save as Variant dialog for the Active Alerting report
Save as Variant – Active Alerting report

Enter a Variant Name and Description, then Save (Ctrl+S).

Variant Name and Description entry screen
Variant Attributes – name and description

Schedule a job

A job must be scheduled for report /ASADEV/ACI_ACTIVE_ALERTING for regular checking of calls and continuous notifications, using the variant created above.

See the SAP Help Portal for a detailed explanation on Scheduling Background Jobs.

BAdI for Active Alerting

Overview

This BAdI implementation extends the Active Alerting report with the capability to send alert information to an external ticketing system. The goal is:

This enhances alerting flexibility and allows external systems (e.g. ServiceNow, Jira, ITSM tools) to consume runtime alerts from the Integration Add-on.

Trigger point

The BAdI is called during runtime of report /ASADEV/ACI_ACTIVE_ALERTING, specifically after:

  1. Threshold calculation is completed
  2. Violations are evaluated
  3. AMR log data is retrieved

If an implementation exists, the report:

BAdI methods

Method send_all_to_external

Purpose: sends all collected AMR logs within the selected timeframe to the external ticketing system.

Call location: executed after retrieving lt_amrlog (all relevant logs).

ParameterDirectionTypeDescription
it_amr_logsIMPORTING/asadev/a_amrlog (table)All AMR logs matching the selection criteria
ev_messageEXPORTINGstringStatus/message returned by the external system
et_returnEXPORTING/asadev/aci_tt_bapiret2Error/success log

All exceptions of type cx_root are caught and converted to a BAPIRET2 structure using helper class /asadev/cl_aci_helper.

Method send_filtered_to_external

Purpose: sends only the subset of logs relevant to the specific threshold record currently processed in the loop.

Call location: inside the main loop over lt_overview (threshold violations).

Filtering logic: the system creates lt_amrlog_filtered, containing only logs where instance = <fs_overview>-instance (extendable if the object-level condition should also filter on object).

Parameters: same as send_all_to_external above.

Method skip_standard

Purpose: decides whether the report should skip:

Parameter: CHANGING cv_skip_standard

Find notification in inbox

Notifications are all collected in one area in the Business Workplace:

Business Workplace inbox — Active Alerting workflow notification
Business Workplace inbox – Active Alerting notification, grouped by task

Function modules

Two RFC function modules return the error rates, so you can feed a custom monitoring system if needed – one calculates rates at the connection level, the other at the object level.