Alert: An alert is a notification informing its recipients that a critical or very important situation has arisen.

The situation is as severe that an action must be taken immediately in order to resolve the situation. The system recognizes the situation and sends the alert. Alerts can be used to prevent delays in the processing of critical situations, because the time between discovering and responding to such situations is reduced considerably.
Alert notification process:

PI errors can be classified into two categories (Integration Engine, Adapter Engine). All adapters (in J2EE) related errors like communication channel is inactivate, user authentication, invalid parameters etc are reporting from AE. Message process errors are (mapping, routing ...etc) notifying from IE. These errors are reported to the PI application program to process the alert notifications. Alerts are created in the local system (i.e PI DEV). Notifications are delivered through the different channels, if Central ALM is configured then this process handles from central system (i.e SOLMAN) otherwise local system deliver the notifications.

Alert Process Flow Diagram

1. 2. 3. 4. 5.

Error Occurred in Integration Engine (i.e Mapping error) Notification program checks for CentralMonitoringSever-XIAlerts RFC Destination. If the RFC destination does not exist it will create the above RFC destination. Check the RFC connection. If the connection is failed then the program will be terminated (Alert wont be generated), otherwise, check for matching rule. 6. The above checks are not applicable to Adapter Engine errors, they processed from here. 7. Get the RFC destination from SLART1 transaction. 8. Send the alert to the RFC destination, if central ALM is configured then it will go to the central server (i.e SOLMAN), otherwise, alert will be delivered to the local PI server.

An RFC destination must be maintained in the SALRT1 transaction in order for alerts to work. PI will create the CentralMonitoringServer-XIAlerts as default RFC destination automatically on the triggering of the first alert, it uses the Exchange Profile -> Runtime Workbench configuration information to create the RFC destination. If you maintain NONE in the SLART1 configuration it will uses the default (CentralMonitoringServer-XIAlerts) RFC destination. Even though different RFC destination is maintained in the SLART configuration the default RFC destination must be in valid state, otherwise, alerts wont be processed. Alert log can be viewed in the local system with the SXMSALERT_LOGREADER report.

Conclusion:

As alerts notification usage is increasing by number of applications (CRM, SRM etc), Central ALM process reduces significant maintenance. There are some cons if one central system maintains for entire landscape, separate alert categories need to be maintained for Production and Non-Production environment, otherwise, non-prod alerts may go to the production users. Once you cross these initial hurdles then it will be a smooth sailing.

Procedure to Create Alerts:

Open the alert category/classification definition environment (transaction ALRTCATDEF). 2. Ensure you are in change mode. 3. In the group box with the alert classifications, right-click All classifications to open the context menu, and choose Create. 4. Under Classification, enter a name for the classification ESAI_ALGOMA
1.

Under Description, enter a description of the classification. Save your entries. create a new alert category PI_ALGOMA_ALERT and provide a description. In the Properties tab provide the required description and the Alias name a. Description -- Alert Category for ESAI Algoma Integration b. Alias Email Alert 9. In the Container tab create a new container element. 10. Available Container Variables :
5. 6. 7. 8.

Container Variable SXMS_MSG_GUID SXMS_RULE_NAME SXMS_ERROR_CAT SXMS_ERROR_CODE SXMS_FROM_PARTY SXMS_FROM_SERVICE SXMS_FROM_NAMESPACE SXMS_FROM_INTERFACE SXMS_TO_PARTY SXMS_TO_SERVICE SXMS_TO_NAMESPACE SXMS_TO_INTERFACE SXMS_TO_ADAPTER_TYPE SXMS_TO_ADAPTER_ERRTXT

ABAP Dictionary Data Type SXMSMGUIDC SXMSDESCR SXMSERRCAT CHAR70 SXI_FROM_PARTY SXI_FROM_SERVICE SXI_FROM_ACTION_N S SXI_FROM_ACTION SXI_TO_PARTY SXI_TO_SERVICE SXI_TO_ACTION_NS SXI_TO_ACTION CHAR70 CHAR70

Meaning Message ID Description of the alert rule Error category Error code Sender party Sender service Sender namespace Sender interface Receiver party Receiver service Receiver namespace Receiver interface Adapter type Error text from the Adapter Engine

11.

In Long and Short Text tab provide the short and long texts of the messages.

Message Title: &SXMS_ERROR_CODE& ( category &SXMS_ERROR_CAT& ) was found in a message &SXMS_MSG_GUID& from the interface &SXMS_FROM_SERVICE& Short Text Error: &SXMS_ERROR_CODE& ( category &SXMS_ERROR_CAT& ) was found in a message &SXMS_MSG_GUID& from the interface &SXMS_FROM_SERVICE&

Long Text Message :

Dear Administrator, The Message ID: &SXMS_MSG_GUID& Alert Rule : &SXMS_RULE_NAME& Sender Namespace : &SXMS_FROM_NAMESPACE& Sender Service : &SXMS_FROM_SERVICE& Sender Interface: &SXMS_FROM_INTERFACE& Receiver Namespace : &SXMS_TO_NAMESPACE& Receiver Service : &SXMS_TO_SERVICE& Error Categeory : &SXMS_ERROR_CAT& Error Code : &SXMS_ERROR_CODE& Thanks Alert Management
12. 13. 14. 15. 16.

Click on the Fixed Recipients button and specify the users who would receive the alert mails. Save the alert configuration. Goto t-code SCOT; double-click SMTP and specify the mail-host and mail-port for the respective mail server. Make the Node in use check box as checked. Click on the Internet->Set button under Supported address types to specify the emailaddress of the recipient.

By performing the above steps the Alert has been successfully completed and to test the alert that we have created follow the below steps: a. To test our alert configurations run the report RSALERTTEST using the t-code se38. b. Specify the alert category that we have created PI_ALGOMA_ALERT. c. Execute (F8). d. If the alert configuration is correct, an email will be sent to the specified recipient of the alert mails.
Creating Rules for Receiving Alert Mails

1) In Runtime Workbench Alert Configuration choose the alert category that was created PI_ALGOMA_ALERT. 2) Create rules for the alert mails by specifying the appropriate sender and receiver parameters for the created alert category.

3) When an end-to-end scenario contains any errors, an email is automatically generated and sent to the required recipient of the alert mails. 4) Now you can go to the alert inbox to see if the alert was triggered: - you can do it from RWB - Alert inbox - or from sapgui TCODE - ALRTINBOX
Advantages:

1. Central ALM (Alert Management) will be reduced maintenance to one central system instead of multiple systems in the landscape. 2. No need to maintain alert categories in each system, categories can be maintained in central system which can be accessed to the connected systems (DEV, QA, PROD etc). 3. Alert rules can be created centrally and no need to transport or recreate them in each system in landscape. 4. Alert email notification (SCOT) configuration can be done centrally, no need to maintain in connected systems.