Show TOC

Procedure documentationConfiguring Alert Notifications


You specify who is to be notified when alerts are raised.


  • You have specified meaningful threshold values for raising alerts, and the system is running normally. For more information, see Specifying Alert Thresholds.

  • You have administrator authorization.

  • You are currently performing the Alerting step of the guided procedure for setting up End User Experience Monitoring in the SAP Solution Manager: Configuration work center.


  1. To configure the settings globally or for individual EEMon scripts, choose the Global tab, or choose the Scripts tab and select the relevant EEMon script.

  2. Choose Edit. You have the following options:

    • On the Incidents tab, specify whether support messages are to be created:

      1. Set the Auto-Incidents flag to specify that a support message is automatically created if a script fails and an alert is raised.

      2. In the Assigned Support Component field, specify the component to which support messages are to be assigned.

      3. In the CRM Transaction Type field, specify the support process for which support messages are to be created.

      4. The field Incident Confirmation Closes Alert specifies that when a support message is confirmed, the relevant alert is closed and removed from the list in the alert inbox.

    • On the Notifications tab, specify who is to be informed by e-mail or SMS about alerts.

      1. The field Auto-Notifications specifies whether automatic e-Mail or SMS notifications are to be sent when an alert is raised.

      2. Choose Add to add a recipient list to specify who is to be notified.

      3. Optional: Choose Maintain Recipients to create or change a recipient list.

      For more information, see Technical Monitoring Alert Inbox.

    • On the Event Rule tab, specify globally for all locations, how and under what conditions availability and performance alerts are to be generated. Set the event propagation rules for availability and performance:

      • from the layer of steps executed on a robot to the layer of the script execution on a robot

      • from the script execution layer (execution of a script on different robots) to the script layer

      Possible propagation rules are:

      • Best Case Rule:

        • An EEMon script does not raise an alert as long as at least one step can be performed in an EEMon script.

        • The overall status of an EEM script is green as long as at least one EEM robot is rated green..

        Example Example

        You check the availability of an internet portal. As long as you can call at least one instance, the portal is considered technically available.

        End of the example.
      • Worst Case Rule:

        • An EEMon script raises an alert if any step in an EEMon script fails.

        • The overall status of an EEM script is red if any EEM robot is rated red.

        Example Example

        You monitor the performance of a business-critical system.

        End of the example.

        Note Note

        By default, events are propagated from the step layer to the script layer according to the worst case rule. A click sequence, for example, often only produces valid results if it is executed step by step in a fixed order while each step depends on the previous one.

        End of the note.
      • Worst rating of last N best events: When calculating the overall status of an EEM script, a combination of the best case rule and the worst case rule allows you to filter outliers without setting less restrictive threshold values. This increases the significance of the alerts and is useful if the worst case rule generates too many alerts due to random spikes during monitoring.

        1. In a first step, the system identifies the best of the last n (default: n=3) script executions on each EEM robot, for a script. For example, three consecutive red script executions are required to raise a red rating for a time interval. So on the local (EEM robot) level, outliers are filtered.

        2. In a second step, the local statuses of the EEM robots are propagated according to the worst case rule. A red alert, for example, is raised if any robot is rated red, since the status of a business scenario at the location represented by the EEM robot is proven to be red for a significant time.

      Note Note

      You can use a BAdI implementation to define custom propagation rules based on the Worst rating of last N best events rule. For more information, contact the SAP support.

      End of the note.