If below points are not covering a question, please check SAP Online Help about ALM.
Frequently occured problems in Alert Management (ALM)
- 1. Error "Internal error in configuration", message number SALERT125
- 2. Loggings in Alert Management
- 3. Error "Alert has no recipients"
- 4. "Day off" can not be deleted
- 5. Alert was not sent by E-mail
- 6. Tables SALRT and SALRTCNT contain many entries
- 7. Text of alert is not correct
- 8. Forwarding Central Monitoring System (CCMS) alerts to Alert Management (ALM)
- 9. Time-dependent delivery is not working
- 10. Required data for ALM customer messages
1. Error "Internal error in configuration", message number SALERT125
By configuring alerts in transaction ALRTCATDEF, for (some) users this error message appears. The reason is most probably the following:
In transaction SALRT1 no RFC destination is maintained or the maintained RFC destination does not exist in transaction SM59.
Other reason for the error can be, that user does not have enough authorization to execute the RFC call. Therefore check whether or not the following authorizaion is assigned to the user:
- Object: S_RFC
- RFC_TYPE: FUGR (function group)
- RFC_NAME: SALRT_WPRFC
- ACTVT: 16 (execute)
2. Loggings in Alert Management
To create logs, please set option "Write Log" in ALRTCATDEF in menu „Settings -> Configuration".
All applications which are connected to the alert management, use the function module SALRT_CREATE_API. This has a parameter IP_WAIT_ON_COMMIT. If this is set, the application calls the function module asynchron (RFC call), and corresponding entries can be found in tr. SM58, if the RFC call is not yet finished.
If the RFC call during the alert creation is executed and finished, independently of the parameter IP_WAIT_ON_COMMIT, a relevant log about information for alerts can be checked in transaction SLG1:
- Tr. SLG1 >> Object: ALERT
Please check these logs to get more information about problems while using ALM.
3. Error "Alert has no recipients"
Error "Alert has no recipients" occurs by creating alerts for a particular alert category.
There are several ways to define a recipient for an alert category:
- Tr. ALRTCATDEF >> Buttons „Fixed Recipients", „Recipients Via User Roles", „Subscription Authorization"
- Tr. ALRTCATDEF >> Choose one alert category >> check the rule-based recipients
- It is also possible, that the relevant application which creates the alert gives the information directly to the Alert Management. This can be done, if the application calls the function SALRT_CREATE_API, and fills the tables IT_RECIPIENTS or IT_EXT_RECIPIENTS. In this case the recipient can be found in the alert container also, can be checked in transaction ALRTDISP.
The name of the relevant alert category can be found out in transaction SLG1 or in tr. SM58 by clicking on the Transaction ID. For more info please see point 2 (Loggings in Alert Management).
4. "Day off" can not be deleted
User has definded time-dependet delivery in personalization in alert inbox (transaction ALRTINBOX).
However this entry can not be deleted. Please check SAP Note 1325141.
5. Alert was not sent by E-mail
Application creates alerts, which can be seen in alert inbox of alert recipients, however these alerts are not sent by mail, altough alert recipient has set the "Mail" delivery type either in time-independent or in time-dependent delivery in personalization of alert inbox.
- Non-existing user is set for inbound processing of alerts
Within transaction ALRTCATDEF under menu „Settings -> Configuration" a user can be maintained for inbound processing. The mail address of this user is used as a „Reply-To" address for outgoing alert mails, if the alert should be confirmed by internet mail. If a non-existing (missing in Tr. SU01) user is set here, the alert mail can not be generated.
Either do not set any user for inbound processing if you do not use the confirmation of alerts by mail, or set a valid user in this section.
See also the online documentation.
(Alert Confirmation with Inbound Processing)
- Error "BCS exception (OSERR_BCS) occurred"
Check KBA 1690014.
- Bug in System
It happens, that some recipients do not get the alert by mail. In this case it is useful to implement the newest version of SAP Note 1088231, which corrects code errors causing not just the dump described in the note, but also as side effect the issue with non-delivered alert mails.
- Communication method is RML
If user sets "Mail" delivery type under personalization in alert inbox, and the communication method of the user is set to RML in transaction SU01 (under "Address" tab), the alert will be sent by Remote Mail (RML) and not via E-mail to the external mail address of the user. To avoid the alerts to be sent via RML, set the communication method in SU01 to "E-Mail".
Read SAP Note 931675 for background information.
6. Tables SALRT and SALRTCNT contain many entries
In a system where the alert management is used frequently by the applications, the relevant tables SALRT and SALRTCNT can easily grow big. To process and delete alerts, use the report RSALERTPROC. Please consider following suggestions while using this programm in order to avoid database related short dumps like TSV_TNEW_PAGE_ALLOC_FAILED or TSV_TNEW_BLOCKS_NO_ROLL_MEMORY:
- Always implement the RSALERTPROC related SAP notes before using the report, especially SAP Notes 1088231 and 1311029.
- Set an alert category, for which the alerts should be processed/deleted. Do not use asterisk if all alert categories should be considered. In this case leave the field „Alert Category" empty.
- Use small time intervalls for deleting old alerts, if the tables contain many entries, for instance more than 1 million. Suggested time interval, one week or one day.
- If there is a huge amount of alerts which should be deleted, make sure that the report does only delete alerts in this run (not escalate or deliver alerts). So only checkbox "Delete Old Alerts" is checked.
7. Text of alert is not correct
The text of alert mail is language dependent. It means the text for an alert category have to be created in all used languages in tr. ALRTCATDEF. For example: with logon language EN the english text of an alert is created, with logon language DE the german text.
When an alert is sent out as e-mail the text is built up in different languages depending on the settings of the recipients. For each recipient the default logon language is taken as language for the alert e-mail (see transaction SU01, tab Defaults, field 'Logon language'). If there is no language maintained sy-langu is taken.
8. Forwarding Central Monitoring System (CCMS) alerts to Alert Management (ALM)
More information can be found in following online documentation:
9. Time-dependent delivery is not working
The BAdI ALERT_DELIVERY is responsible for time-dependent delivery. This BAdI has to be active to use the time-dependent delivery. You can activate the standard delivered implementation of the BAdI as follows:
- Tr. SE18 >> BAdi-Name: ALERT_DELIVERY
- Menu -> Implementation -> Overview
- Double click on ALERT_DELIVERY
- Change into changes modus and activate
After the activation of the BAdI the time-dependent deilvery should work fine.
10. Required data for ALM customer messages
In case the above mentioned solutions do not solve the problem occured in Alert Management, and you open an SAP customer incident in component BC-SRV-GBT-ALM, please provide following data in the message:
- Steps to generate the alerts.
- Name of alert category from tr. ALTRCATDEF.
- Alert Container data from tr. ALRTDISP.
- Attach the application log info from tr. SLG1, which corresponds to the error.
- Set the logging for alert managament in tr. ALTRCATDEF >> Menu: Settings -> Configuration >> Logging.
- Reproduce the error. Check application log in tr. SLG1 with "Object = alert".
- Check whether the error can be reproduced also with report RSALERTTEST from tr. SE38.
- Inform us in the message, that you have checked this wiki page about ALM issues.
Thank you for providing all these informations in the customer message. These details help us to analyse and solve the problem quicker.
11. Priority of an alert can only be set to "High" or "Very High"
There is no need to have more priorities inside Alert Management: An alert can have the priority "High" or "Very High".
In transaction ALRTCATDEF the priority can be set. Behind this field the structure SALRTSCATV with field PRIORITY lies. In transaction SE11 if you check the field PRIORITY, it has the data element SALRTDPRIO, it has the domain SALRTOPRIO, which has only two default entries, "Very High" and "High".
There is no other priority that can be set in ALRTCATDEF. This is the standard behaviour.
The priorities in Alert Management are not related to any other application priorities.