Alert Notification Step-by-Step
Purpose
This section describes the steps that are necessary to trigger an alert in the central alert system and to notify the persons in charge.
Prerequisites
The following prerequisites have to be met in order to use the Alert Management (ALM):
· For using the Alert Inbox (BSP based display program of ALM), the corresponding service has to be activated in the service maintenance transaction SICF. Choose Default_host → sap → bc → bsp → sap → alert inbox, and Activate in the context menu.
· For customizing or administration of the Alert Management the corresponding authorization role has to be assigned. The end users do not need any additional authorization. You find more information under Authorization Concept.
·
The
central alert server must be maintained as an RFC destination in transaction
SM59 in the local system. If there is
no suitable user, you have to create a user for the RFC connection in the
central alert system in transaction SU01 (see
User
Administration and Authorization
Concept). To make this RFC destination known as the RFC destination of the
Alert Management System in the local system, the central alert server must
also be selected as the RFC destination in transaction SALRT1 of the local system or in Settings → RFC-Destination of Alert Server.
If the central alert server is running on the local system in the same client, you do not have to maintain an RFC destination. In this case, you can simply enter NONE in transaction SALRT1.
·
If
external communication types, such as e-mail, SMS, and fax are used, these
communication types must be correctly configured in
SAPconnect,
because the alerts are then sent from the central alert system via
SAPconnect.
Process Flow
The following describes the process flow from alert configuration (transaction ALRTCATDEF) to alert display and confirmation (for example in the alert inbox transaction ALRTINBOX):
1. Optional: You can define alert classifications. These are useful to group alert categories. For example, you can create an alert classification CRM that contains alert categories referring to CRM. Alert classifications can now have subclassifications. This enables you to build up your own classification hierarchy. Especially, if you use the Alert Mangement (ALM) extensively, classification and subclassification help you to organize your ALM alert landscape and to have a clear overview.
2. For different types of alerts you have to define different categories. The category contains various properties and other specifications that define the alerts within that category, for example expiry date, or the escalation recipient. You can define an alert category to suit your business requirements and assign the category to the corresponding classification. For example, for the alert classification CRM you can create the alert categories Contract Cancelled and Decrease in Sales. When the critical situation defined in the alert category arises, the system recognizes this and sends an alert instance of this category to the recipients determined. The alerts can always be found in the display programs configured for the recipient (UWL, application-specific program, or alert inbox). Additionally, the alerts are sent via eventual external communication channels, such as e-mail, sms, or fax.
3. You have to determine recipients so that the Alert Management knows who the recipients of alerts of a particular category are and that the correct parties are informed.
4. You can configure the way how alerts are processed. For the general use of the Alert Management you do not have to change the default settings. However, if for example you want to send alerts to third-party systems, or to be able to confirm alerts by SMS/Internet mail, or to have logs written, then you have to configure alert processing.
5. There is a number of Alert Management administration reports that you must schedule according to your requirements. For example, report RSALERTPROC must be executed in order to enable escalation.
6. Alerts of a particular category must be triggered by an application at runtime. Triggering alerts can be done in various ways. You can call a function module directly or use middleware components that trigger alerts, such as the Business Object Repository (BOR), Post Processing Framework (PPF), SAP Workflow, or CCMS.
7.
Recipients can view the alerts assigned to them in
the
UWL of
Enteprise Portal, in application-specific display programs, or in the alert inbox.
In addition, alerts can be received as e-mail, SMS, or fax, if these external
communication channels are configured in SAPconnect.
8. If the problem causing the alert is solved by a recipient, the recipient can confirm the alert, this means its status is changed and it will not be delivered, escalated, or displayed anymore. Alerts are generally confirmed by the recipient in the display program, such as the UWL or Alert Inbox. However, if an alert is sent by Internet mail or SMS message, it is also possible to confirm it by sending an Internet mail or SMS message back to the SAP system. Alert Management uses inbound processing for this.
