SAP Alert Notification

12/20/2019
Alert Management (BC-SRV-GBT-ALM)

Generated on: 2019-12-20
SAP NetWeaver 7.5 | SPS16
PUBLIC
Original content: https://help.sap.com/viewer/fff5965a513a4c69ae68f8c6cafb5d22/7.5.16/en-US
Warning
This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product
documentation. The information included in custom documentation may not re ect the arrangement of topics in the SAP Help
Portal, and may be missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.
For more information, please visit the https://help.sap.com/viewer/disclaimer.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000348&topics=494782b737042221e10000000a… 1/24
12/20/2019
Alert Management (BC-SRV-GBT-ALM)

Use
Alert Management (ALM) comes into play, when business-critical problems occur. Within ALM, conditions for critical situations
are prede ned. When an is triggered in ALM that meets these conditions, responsible or interested parties are determined and
informed immediately. Examples of critical situations might be an important customer terminating a contract or a budget being
exceeded.
The alerts are polled from the UWL of the Enterprise Portal, application-speci c display programs, or the alert inbox. These display
programs can be personalized due to the user's needs. In addition, the users can receive alerts as e-mail, SMS, and fax, if these
external methods of communication are con gured in SAPconnect. End users can personalize their alert noti cations, for
example, create noti cation variants or determine a substitute.
Alert Management helps prevent delays in the processing of critical situations, because the time between discovering and
responding to such situations is reduced considerably.
Implementation Considerations
Alert Management (ALM) is an ideal solution if you can identify speci c business or technical situations that are critical and could
jeopardize efficient operation, and you want speci c parties to be informed if these situations arise.
The ALM server has to be a SAP Web AS as of release 6.20. The local application systems can be a SAP Web AS as of release 4.6C.
Note
For local systems of SAP Web AS release 6.10 or lower you need a speci c workplace plugin.
Integration
The Alert Framework is provided as part of the SAP Web Application Server. The application that wants to trigger alerts must
de ne its own alert categories, assign them to alert classi cations and implement the triggering of the alert instances to realize
Alert Management. (For more information, see Alert Classi cation, Alert Category, and Triggering Alerts.) Alerts are all sent to the
display program (UWL, application-speci c program, or alert inbox) of the de ned alert recipients. Additionally, alerts can be sent
by other channels, such as by Internet mail, SMS, or fax.
There is a number of administration reports that you must schedule according to your requirements. For example, report
RSALERTPROC must be executed in order to enable escalation. Also, you can con gure alert processing to be able to send alerts
to third-party systems, to be able to con rm alerts by SMS/Internet mail, or to have logs written.
Note
If you want to send alerts not only to the recipient's display program (UWL, application-speci c program, or alert inbox), but
also via external communication methods (e-mail, sms, and fax), the chosen communication type must be correctly con gured
in SAPconnect.
12/20/2019
Features
An application triggers an alert of a particular alert category based on an important or critical business or technical situation. (For
more information, see Triggering Alerts.) The alert recipients are determined either by the application, by an administrator, or
using a subscription procedure. (For more information, see Recipient Determination.) An alert outlining the situation is delivered
to the recipients immediately. Depending on the con guration, the alert can be viewed by the recipients in the UWL, application-
speci c display programs, or in the alert inbox. In additions, the alerts can be delivered using other channels as well, if the
recipients have made the appropriate settings and the communication method is con gured in SAPconnect. If the receipt of the
alert is not con rmed by any of the recipients, the alert can be sent to an escalation recipient.
Constraints
The following are not incorporated into Alert Management:
Feedback to the triggering application. However, it is possible to model feedback to the application, such as con rming that
a subsequent activity has been executed, using SAP Business Work ow.
Merging of alerts that are related from a content perspective.
Alert Noti cation Step-by-Step

Use
12/20/2019
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 nd 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.
Note
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
con gured in SAPconnect, because the alerts are then sent from the central alert system via SAPconnect.
Process
The following describes the process ow from alert con guration (transaction ALRTCATDEF) to alert display and con rmation (for
example in the alert inbox transaction ALRTINBOX):
1. Optional: You can de ne alert classi cations. These are useful to group alert categories. For example, you can create an
alert classi cation CRM that contains alert categories referring to CRM. Alert classi cations can now have
subclassi cations. This enables you to build up your own classi cation hierarchy. Especially, if you use the Alert
Mangement (ALM) extensively, classi cation and subclassi cation help you to organize your ALM alert landscape and to
have a clear overview.
2. For different types of alerts you have to de ne different categories. The category contains various properties and other
speci cations that de ne the alerts within that category, for example expiry date, or the escalation recipient. You can
de ne an alert category to suit your business requirements and assign the category to the corresponding classi cation. For
example, for the alert classi cation CRM you can create the alert categories Contract Cancelled and
Decrease in Sales. When the critical situation de ned 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 con gured for the recipient (UWL, application-speci c 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 con gure 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 con rm
alerts by SMS/Internet mail, or to have logs written, then you have to con gure alert processing.
5. There is a number of Alert Management adminstration reports that you must schedule according to your requirements. For
example, report RSALERTPROC must be executed in order to enable escalation.
12/20/2019
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 Work ow, or CCMS.
7. Recipients can view the alerts assigned to them in the UWL of Enteprise Portal (if installed), in application-speci c 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 con gured in SAPconnect.
8. If the problem causing the alert is solved by a recipient, the recipient can con rm the alert, this means its status is changed
and it will not be delivered, escalated, or displayed anymore. Alerts are generally con rmed 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
con rm it by sending an Internet mail or SMS message back to the SAP system. Alert Management uses inbound
processing for this.
Alert Inbox
Use
The alert inbox is user-speci c and shows all alerts that are sent to you in accordance with the alert con guration.
Integration
There are several ways you can receive ALM alerts. For example, you can receive alerts via the external communication methods e-
mail, fax, or SMS, if these methods were con gured for you and you have chosen this way of noti cation in the personalization.
However, irrespective of these external communication methods, you nd the alerts in any case in your main display program. This
can be:
In the Universal Work List (UWL) of Enterprise Portal as of SAP NetWeaver '04
In applications accessing alerts via the API
For testing and for fast access, also in the Alert Inbox with its personalization and subscription functions. The Alert Inbox is
called with transaction ALRTINBOX or the corresponding URL ( http://<host>:
<port>/sap/bc/bsp/sap/alertinbox).
Note
The alert inbox description here refers to the alert inbox found in transaction ALRTINBOX or via a URL. Descriptions of
the alert display in the UWL or application-speci c display programs can be found in the corresponding documentation.
Prerequisites
The alert inbox is con gured for you by your administrator.
Features
The alert inbox offers the following features:
The main view of the alert inbox contains a list of alerts that you can forward to other users or con rm.
Con rmed alerts are deleted from the alert inbox list. If con gured, alerts can also be con rmed by e-mail, or SMS by
merely sending a reply e-mail or SMS. For con rmation by SMS, you need an appropriate SMS provider. When you select
an alert from the alert list, several tab pages appear on the screen. These tab pages display the alert short text sent to
pager/SMS as well as the more detailed alert long text used for e-mails and fax. In addition, you can view a list of all alert
12/20/2019
recipients together with a description of why the alert is sent to these speci c users. You can nd information on how
recipients are determined in the Recipient Determination section. Also you can nd possible follow-up actions on the
corresponding tab page.
You can also send the alert back to the list, if you are not able to solve the problem.
Note
The last person on the recipient list cannot send the alert back to the inbox list, but has to solve the problem.
You can personalize the way in which you receive alerts.
Simply choose Personalization to make individual settings for your alert inbox. You can determine a substitute who will
then receive the alerts. In addition, you can choose whether alerts are sent to you time-independently or time-dependently.
The default setting is that alerts are sent time-independently to your alert inbox and via e-mail when they occur. You can
additionally select the communication methods FAX and SMS for time-independent alert noti cation.
If you want to receive alerts only on certain days for a certain time, simply select the option for time-dependent sending of
alerts and choose Create to create a new table entry. You can then choose the corresponding factory calendar, the time
interval, and communication channel. Alerts that arise during this time frame will be sent in any case to your alert inbox. If
you have also selected other communication channels, the alerts are additionally sent to you using these other channels.
You can subscribe to alert categories in order to receive alerts from these categories.
Some alerts are sent to you based on the settings that your administrator or application developer have made for you. In
these cases, you cannot choose if you want to receive these alerts or not.
However, there are also alert categories where you have the choice. These are the categories for which you have
subscription authorization. To see a list of the alert categories for which you have subscription authorization, choose
Subscription in the main alert inbox view. You can subscribe to a category by either choosing Subscribe or by clicking the
status symbol ('light bulb'). You can also see the classi cation of a category on the same screen; for example the category
Contract cancelled has the classi cation CRM.
Alert
De nition
An alert is a noti cation 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.
Use
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.
Integration
An alert is an instance of an alert category.
Example
An alert could be used to notify recipients in the event of a production standstill or a budget being exceeded, for example.
12/20/2019
Alert Classi cation

De nition
To be able to send different types of alerts under speci c conditions, different alert categories are to be de ned. A category
contains various properties and other speci cations that de ne the alerts within that category, for example expiry date, or the
escalation recipient.
Alert categories can be assigned to an alert classi cation. If you do not want to create a classi cation on your own, you can always
create categories within the default classi cation folder Unclassi ed. However, for a better overview, it is recommendable to
create different alert classi cations to group alert categories that belong to the same topic. For example, you can create the alert
classi cation CRM to group all CRM speci c categories such as Contract Cancelled and Decrease in Sales. Alert classi cations
can have sub classi cations which enables you to build up your own classi cation hierarchy.
Alert classi cations are de ned in the Alert Management Con guration transaction ALRTCATDEF, see also De ning Alert
Classi cations.
De ning Alert Classi cations

Context
Alert classi cations are used to group alert categories according to their subject. Several categories from one application could be
assigned to the same classi cation, for example. When using transaction ALRTCATDEF_SEL or the administration reports
RSALAERTDISP and RSALERTPROC, the administrator can simply enter the classi cation to process all alerts of all categories
assigned to that classi cation.
Since sub-classi cations are supported, you can build up an elaborated hierarchy for the various application scenarios. For
instance, you de ne top-classi cations like CRM, APO, BW and beneath these classi cations you create your sub-classi cations.
Note
Alert categories can be assigned to speci c alert classi cations. If you do not need a speci c classi cation for a certain kind of
alerts, you can use the default classi cation folder Unclassi ed. You nd this folder when you follow the procedure description
below until step 3.
Procedure
1. Open the alert category/classi cation de nition environment (transaction ALRTCATDEF).
2. Ensure you are in change mode.
3. In the group box with the alert classi cations, right-click All classi cations to open the context menu, and choose Create.
4. Under Classi cation, enter a name for the classi cation.
5. Under Description, enter a description of the classi cation.
6. Optional: If you want to create a sub-classi cation, open the context menu of the classi cation, choose Create, and enter a
name and description for the sub-classi cation.
7. Save your entries.
12/20/2019
Results
You have created a classi cation for alert categories. When you de ne alert categories in the de nition environment, this
classi cation will now be available for selection.
Example
If you want to group all your mySAP CRM alert categories together, you could create a classi cation called CRM with description
Customer Relationship Management. Beneath this category you could for example create the sub-categories Order s
and Marketing.
Maintaining a Rule
Prerequisites
The data passed to the rule is included in the alert container.
Context
Alert Management provides you with the exibility to maintain a rule which meets your demands, such as maintaining a rule which
addresses alert recipients at a certain time.
Procedure
1. Ensure that you are in change mode in the rule maintenance environment (transaction PFAC ). For more information on
the transaction, see Rules for Agent Determination for Tasks.
2. Enter a name for the new rule and choose Create.
3. On the Rule De nition tab page, enter a short description of the rule and select a category for the rule de nition. You have
selected the data passed to the rule.
4. Under Description, enter information about the newly-created rule.
5. On the Container tab page, choose Create Element and create rule container elements corresponding to the alert
container elements you want to use in the rule. Save your entries.
Note
The rule container is the counterpart to the alert container. You should use a name that is similar or the same to identify
the containers later on. The content of the container does not have to be the same.
For information, see Rule-Based Proposal for Binding De nitions.
6. On the Responsibilities tab page, choose Create Responsibility and con rm the pop-up.
7. On the screen Responsibility Change for Rule... specify the responsibilities in the table Responsibility Specs. Save your
entries.
8. Return to Rule Maintenance (transaction PFAC) and select the responsibilities you created above.
9. On the Responsibilities tab page, assign a user by selecting the rule and choosing Insert agent assignment. Select an
object type and create a relationship between the user and the de ned responsibilities. See Maintenance of Agent
12/20/2019
Assignment for more information. Save your entries.
Results
You have created a recipient rule. Note the rule number for the test described in De ning Alert Categories.
Alert Category
De nition
An alert category contains various properties and other speci cations that de ne the alert within that category. The category
de nes the conditions when a speci c alert is sent to whom.
Use
Use
Alert categories can be de ned by applications or customers using the alert category de nition environment, which is accessed in
transaction ALRTCATDEF. You can de ne an alert category to suit your business requirements. When the critical situation de ned
in the alert category arises, the system recognizes this and sends an alert instance of this category to the recipients determined.
Integration
An alert category can be assigned to a speci c alert classi cation. Alert classi cations help to organize and group alert categories.
If you do not assign a category to a speci c classi cation, it will be stored in the classi cation folder Unclassi ed.
Structure
An alert category is de ned by the following:
Technical key (language-independent) for identi cation purposes
Description (language-dependent)
Classi cation
Priority
Maximum number of deliveries. (This applies to delivery to a destination other than the alert inbox.)
Expiry time (in minutes) after which the alert is deleted
Escalation recipient to whom the alert is sent if it is not con rmed by any of its recipients
Tolerance time before escalation
Short text, long text, and title
The title is used as mail title, fax subject, and alert title in the inbox. The long text is used as mail/fax body and the long text
view in the inbox. The short text is used for pager and SMS.
Container for variable de nition if variables are to be used in the texts, or for other application-speci c attributes
Subsequent activities in the form of URLs
For more information about these properties and speci cations, see De ning Alert Categories.
12/20/2019
De ning Alert Categories

Prerequisites
You must be familiar with the business aspects of the critical situation for which the alert category is to be de ned. In addition, the
authorization activities should be assigned to your SAP user as described in Authorization Concept section.
Context
You can perform the logical administration of alerts by de ning alert categories. During alert category de nition, you specify the
alert text, expiry time, escalation, and all other conditions related to the sending of this kind of alert.
Procedure
1. Ensure that you are in change mode in the alert category de nition environment (transaction ALRTCATDEF).
2. Choose Create Alert Category.
3. In the Alert Category column, enter a technical key. Choose a key that describes the situation that triggers the alert, such
as CUSTCANC for a category responding to a customer cancellation. This key is language-independent and identi es the
alert category. The standard namespace convention applies to the key, this means keys Z* und Y* belong to the customer
namespace.
4. In the Description of Alert column, enter a description of the alert category.
5. On the Properties tab page:
a. In the Description eld, enter a description for the alert category. Choose a description that outlines the content of
the alert category. The description is language-dependent.
b. If required, you can select a classi cation in the Classi cation eld. If you do not choose a speci c classi cation,
the category is stored in the classi cation folder Unclassi ed. For more information on classi cations, see Alert
Classi cation.
c. In the Max. No. of Dels eld, specify a maximum number of times that an alert of this category is to be delivered if it
is not con rmed. This refers to delivery using a communication channel other than to the recipient's display
program (UWL, application-speci c program, or alert inbox).
d. Select Dynamic Text if the texts of the alert category cannot be de ned at this stage. This refers to situations in
which the texts are not known until runtime, for example when CCMS Alerts are forwarded to ALM.
Note
No translation can be performed for alerts with dynamic text. System messages can be entered manually in
several languages.
e. In the Expiry Time in Min. eld, you can enter a life span for alerts of this category if the alerts will no longer be
relevant after a speci c period of time. If the expiry time elapses, the alert is removed from the alert inbox and is no
longer delivered using any other channel.
Expiry times can be derived from various sources. Priority is given rst to the data provided by the triggering
application, second to the BAdI ALERT_EXP_DATE, and third to this eld in the alert category de nition. If none is
found in any of these sources, the default expiry of 31.12.2099 applies.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000348&topics=494782b737042221e10000000… 10/24
12/20/2019
f. In the Rule-Based Recipients eld, enter the eight-digit number of the rule to be applied. Select Process Data Flow
and nd a list of the corresponding alert and rule containers. For information on binding containers, see Rule-Based
Proposal for Binding De nitions.
Assign an element of the rule to each element of the rule container in the second part of the window. Select the
binding instructions and con rm your input. For information on rule-based maintenance, see Maintaining a Rule.
g. If you wish to specify an escalation recipient, select Escalation Active and enter the escalation recipient. Also
specify a tolerance time in minutes. When escalation is active for an alert category, an alert is escalated if none of
the alert recipients has con rmed the alert after this tolerance time. The escalation recipient is also informed that
he or she has received the alert because of an escalation.
Note
The escalation function is based on the administrator report RSALERTPROC. This report has to be scheduled as
a regular job. For information on this report, see Adminstration Reports.
6. On the Container tab page, de ne any variables that you may want to use in the short text or long text. You can also de ne
other application-speci c variables, such as company code or material number. These variables are then replaced at
runtime with values from the application. For more information, see Alert Container.
7. On the Long and Short Text tab page, enter texts for the alert category. You can include text variables referring to elements
of the alert container or system symbols. In the case of a container element, the variable must be de ned in the alert
container. The entry in the text must be in the form &<ElementName>&.
Note
The title is used as mail title, fax subject, and alert title in the inbox. The long text is used as mail/fax body text and the
long text view in the inbox. The short text is used for pager and SMS messages.
8. On the Optional Subsequent Activities tab page, you can enter URLs for subsequent activities. If you trigger your alerts by
calling a function module, you can also specify dynamic subsequent activities. For more information, see Triggering by
Calling a Function Module Directly in Triggering Alerts.
9. Save your entries.
Results
The alert category has been de ned. You can now implement the recipient determination for this category.
Alert Container
De nition
The alert container is a container for the exchange of (application-speci c) variables, such as company code or material number,
between the local systems (alert providers) and the central alert server. It is therefore the interface between the application that
triggers the alert and the central Alert Framework.
Use
When you use application-speci c variables in your container de nition, you supply the values for these variables by writing them
into the container as name-value pairs. These are then interpreted by the Alert Framework on the central system. The runtime
container is implemented as an internal table of the structure SWCONT with only the columns Element Name and Value being
relevant.
12/20/2019
Caution
When the container is lled, no check is performed as to whether the elements entered and the data type of their values are in
accordance with the container de nition. You must ensure that the element names and the data types that you use are in
accordance with the de nition.
Caution
Due to technical restrictions between the Work ow Container and SAPscript, only the rst 80 characters of a container
element are taken into account, when the variables are replaced during runtime.
For more information on using containers in general, see Macro Instructions for Processing a Container in the SAP Business
Work ow documentation.
Internal Usage of the Container
The Alert Framework uses the alert container not only for the exchange of application-speci c variables, but also for the exchange
of internal information. The following variables are used for this purpose.
Name Meaning Typing
_ALERT_RECIPIENTS Recipient list type salrttrcp
_ALERT_ACTIVITIES Subsequent activities type table of salrtsacti
_ALERT_EXPIRATION Expiry date/time (time stamp) type timestamp
_ALERT_DYNAMIC_SHORTTEXT Short text type salrtdcatd (CHAR60)
_ALERT_DYNAMIC_LONGTEXT Long text type table of CHAR255
_EVT_OBJECT Triggering object type BORIDENT
_ALERT_LOGICAL_SYSTEM Logical system in which the alert is triggered type RFCDEST
Note
If you de ne your own variables, ensure that no naming con icts arise. The names of the variables used internally by the Alert
Framework all start with an underscore.
It may sometimes be appropriate to write variables used internally directly into the container. If, for example, you want to pass
URLs to the Alert Framework as subsequent activities, you could instead ll an internal table of the structure SALRTSACTI and
write the table into the container with the element name _ALERT_ACTIVITIES.
Note
Constants for standard elements in the alert container can be found in the include <ALRT01>.
Integration
The alert container is the main component of the interface between the alert provider (triggering application) and the central alert
server.
Transporting Alert Categories

12/20/2019
Use
You can transport alert categories in order to make them available in other systems.
Prerequisites
To transport alert categories the following prerequisites have to be met:
In the Client s Overview (transaction SCC4) choose Details. The setting Automatic recordings of changes has to be
selected in the group box Changes and Transports for Client-Speci c Objects.
There must exist the corresponding transport connection.
Procedure
To transport alert categories proceed as follows:
1. Open the ALM customizing transaction ALRTCATDEF.
2. Choose Transport Current Alert Category or Transport all alert categories.
You are asked to specify a customizing request.
3. Choose an existing customizing request or create a new one.
Result
You can check in transaction SE09, if the category was inserted into the customizing request.
Triggering Alerts
Use
Alerts of a particular category must be triggered by an application at runtime. This can be done in various ways. You can call a
function module directly or use middleware components that trigger alerts, such as:
Business Object Repository triggering events in case certain changes occur in a BOR object (event linkage). For example,
an alert is to be triggered if a purchase order was changed.
Post Processing Framework (PPF) checking certain conditions and triggering alerts if the conditions are met.
SAP Work ow
CCMS triggering alerts if the corresponding autoreaction was assigned in CCMS.
Prerequisites
The following prerequisites must be met to trigger alerts:
The central alert server must be maintained as an RFC destination in transaction SM59 in the local system. This central
alert server must also be selected as the RFC destination in transaction SALRT1 or in Settings RFC-Destination of Alert
Server. (This constitutes the unique entry in table TALRTDST.)
Note
12/20/2019
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 the alerts are to be sent from the central alert system additionally with an external communication method, the chosen
external communication method (e-mail, sms, fax) must be correctly con gured in SAPconnect.
Note
During SAPconnect con guration, the communication data, for example e-mail address, has to be customized in the
user settings of the recipient in transaction SU01.
Process
The various options for triggering an alert are detailed below.
Triggering by Calling a Function Module Directly
The function module SALRT_CREATE_API is called directly by the application in the local system and passes the data to the
central alert server by RFC.
The alert category (IP_CATEGORY) is the only mandatory import parameter. The parameters IP_EXPIRATION_TIME and
IP_EXPIRATION_DATE are optional import parameters for an expiry time and date. The optional import parameter
IP_WAIT_ON_COMMIT is used to control whether an alert is triggered immediately or with the next commit. The default setting
is to wait for the application's commit.
When triggering using the function module, it is also possible to de ne dynamic subsequent activities. These could be used in a
situation where a subsequent activity is to refer to a document that is not added to the alert until runtime, for example. You pass
these activities to the function module by lling an internal table of the structure SALRTSACT and passing this table to the
module as table parameter IT_ACTIVITIES. The structure SALRTSACT contains a name for the activity in the eld ACTTEXT,
and the URL that refers to the subsequent activity in the eld ACTURL.
The parameter tables IT_EXT_RECIPIENTS, IT_EXT_ADDR, and IT_ROLES offer the possibility to add non-SAP-user
addresses, SAP-users (entry in the Central Address Management), and SAP-roles as additional alert recipients.
Triggering by Calling a Function Module in the Workplace Plug-In
Using the SAP Workplace Plug-In, it is possible to use the alert management in SAP Web AS 6.10 or older SAP Basis releases. The
function module for triggering an alert is called SALERT_CREATE_API. This function module possesses an interface analogous
to the previously described SALRT_CREATE_API.
The central alert management server needs an SAP Web AS 6.20 or higher. The alert functionality only enhances the local alert
system, for example an application based on an SAP Web AS 6.10 or an older SAP Basis release can raise alerts in a customer exit
using the above mentioned function module.
Triggering with an Event Linkage
An alert can also be triggered by the occurrence of an event de ned in the Business Object Repository (BOR). In transaction SWE2
in the local system, you enter the alert category as the receiver type and the function module SALRT_CREATE_VIA_EVENT as
the receiver function module for the event. The Alert Framework receives your alert category from your entry in the event linkage
table.
Note
If you need application-speci c attributes, you must de ne appropriate attributes for the object in the BOR. The receiver
module determines all non-table attributes that are de ned for the triggering object in the BOR, and writes them into the alert
12/20/2019
container, providing the attributes are also de ned as elements of the alert container in the de nition of the alert category.
Alternatively, you can implement a check function module or a receiver function module. This enables you to populate the
container according to your requirements.
Note
You should only trigger alerts with an event linkage if you have already implemented a BOR object for your application.
Triggering with the Post Processing Framework (PPF) or Message Control (MC)
Using PPF/MC to trigger alerts enables you to de ne general conditions and initiate output, such as printing, sending an Internet
mail, or starting a work ow. The triggering of an alert can be modeled as a method call (PPF) or by writing a processing program
for the medium "special function" (MC).
Caution
You should only trigger alerts using PPF/MC if you already use PPF/MC in your application.
Triggering from a Work ow
You can de ne the triggering of an alert as a step in a work ow de nition, although you would usually only do this as an extension
to an existing work ow. Elements in the work ow container can be used as attributes. For more information on work ows, see SAP
Business Work ow (BC-BMT-WFM).
Triggering from CCMS with autoreaction
CCMS offers the autoreaction method CCMS_Send_Alert_to_ALM. If this method is assigned to a monitoring node, the monitoring
architecture sends the alerts of this node to ALM. For more information about using this autoreaction, see Forwarding Alerts to
Alert Management (ALM).
Example
The following example report RSALERTDEMO1 shows how an alert can be called directly by a function module, and is available in
the package SALERT_LOCAL.
Note
You can nd further example reports in the package SALERT_DEMO.
*&---------------------------------------------------------------------*
*& Report RSALRTDEMO1 *
*& *
*&---------------------------------------------------------------------*
*& *
*& *
*&---------------------------------------------------------------------*
REPORT rsalrtdemo1.
* Here, you find almost all constants, which are relevant for
* the Alert Framework.
TYPE-POOLS:
salrt.
CONSTANTS:
* Name of your alert category
c_category TYPE salrtdcat VALUE 'ALRTFRMWRKTST',
* Name of application specific attribute / container element
12/20/2019
c_docnumber TYPE swfdname VALUE 'DOCNUMBER'.
* Declaration of the alert-container including application data
DATA: li_container TYPE REF TO if_swf_cnt_container.
TRY.
li_container = cl_swf_cnt_factory=>create( ).
CATCH cx_swf_utl_no_instance_found
cx_swf_utl_obj_create_failed .
ENDTRY.
* Fill in the document number as an element of the container
TRY.
li_container->element_set(
name = c_docnumber
value = '0815' ).
CATCH cx_swf_cnt_cont_access_denied
cx_swf_cnt_elem_not_found
cx_swf_cnt_elem_access_denied
cx_swf_cnt_elem_type_conflict
cx_swf_cnt_unit_type_conflict
cx_swf_cnt_elem_def_invalid
cx_swf_cnt_invalid_qname
cx_swf_cnt_container.
ENDTRY.
* Create an alert of category 'ALRTFRMWRKTEST'.
* Recipient, texts and other attributes are added from
* the definition of the alert category, i.e. the document
* number is the only dynamic element of this API call.
CALL FUNCTION 'SALRT_CREATE_API'
EXPORTING
ip_category = c_category
ii_container = li_container
ip_wait_on_commit = salrt_true "An explicite COMMIT WORK statement
"within the application is mandatory for
"the alert delivery.
EXCEPTIONS
OTHERS = 1.
IF sy-subrc NE 0.
* message "error when creating alert
ENDIF.
* Here is our COMMIT WORK
COMMIT WORK.
Recipient Determination
Use
Alert Management must know who the recipients of alerts of a particular category are, so that it can inform the correct parties.
There are various ways of determining the recipients of alerts.
Prerequisites
You have de ned the alert category for which the recipients are to be determined. For more information, see De ning Alert
Categories. In addition, the authorization activities should be assigned to your SAP user as described in section Authorization
Concept
Process
The various options for determining recipients are detailed below. They can be used in combination.
User subscription
12/20/2019
The user chooses the alert categories that are relevant for him or her. Subscription is implemented as the Business Server Page
(BSP) application ALERTSUBSCRIPTION. A user can only subscribe to alert categories for which he or she has the authorization.
This authorization is assigned to roles using Subscription Authorization in the alert category de nition environment (transaction
ALRTCATDEF). If the user has the role to which a particular alert category is assigned, he or she can subscribe to that alert
category in the alert inbox.
Administrator Determines Recipients
A system administrator determines the recipients of a particular alert category in the de nition environment (transaction
ALRTCATDEF). The administrator can de ne individual recipients (using Fixed Recipients) or roles (using Recipients Via User
Roles). If a role is speci ed, all recipients who have the assigned role receive the alerts of the category in question.
Application Determines Recipients
For recipient determination during runtime, applications can pass speci c recipients to the alert server in the API. If the
application knows precisely who is to receive a particular alert instance, the application can pass the speci c recipients to the alert
server in the API. This might be on the basis of the organization model or application customizing, for example. The application
must ensure that the recipients are authorized to receive the particular alert. These recipients will receive the alert regardless of
whether they have subscribed to the relevant alert category.
If an alert is triggered by calling a function module, the application passes the recipients in the table IT_RECIPIENTS, which is
declared as a table of the structure SALRTSRCP.
Note
Since recipients can be determined in various ways, the reason for a recipient receiving an alert may not be immediately
apparent. Therefore, the recipient also receives an explanation as to why he or she is receiving the alert. These reasons are
implemented as messages of the class SALERT and can include variables. Several reasons are supplied as standard and it is
possible to add application-speci c reasons.
Alert Con rmation

Use
When an alert is con rmed, its status is changed and it will not be delivered, escalated, or displayed.
There are two ways to con rm an alert:
Generally, alerts are con rmed by the recipient in his or her display program (UWL, application-speci c program, or alert
inbox). The users just have to select the alerts to be con rmed, and to choose the alert con rmation option.
If an alert is sent by Internet mail or SMS message, it is also possible to con rm alerts by sending an Internet mail or SMS
message back to the SAP system. Alert Management uses inbound processing for this. For more information, see Alert
Con rmation with Inbound Processing.
Alert Con rmation with Inbound Processing

Use
If an alert is sent by Internet mail or SMS message, it is also possible to con rm alerts by sending an Internet mail or SMS
message back to the SAP system. Alert Management uses inbound processing for this.
12/20/2019
Prerequisites
The following prerequisites have to be met in order to con rm alerts with inbound processing:
A user has been created to receive the mails con rming the alerts. An Internet mail address has been assigned to this user.
The user has been entered for inbound processing in alert con guration.
Inbound processing has been set up in transaction SO50.
You must enter the Internet mail address of the alert user, * for document class, and CL_ALERT_CONFIRM_BY_MAIL as
the exit name.
Note
The incoming e-mails have to be processed via an SMTP plugin. You nd further information in the SAPconnect
documentation.
Activities
Con rming Alerts by Internet Mail
When an alert is sent by Internet mail, the Internet address of the alert user entered in alert con guration is entered as the Reply
To address of the mail. An alert ID is inserted into the text of the mail. When the recipient answers the mail from the alert system,
the alert is con rmed automatically. Inbound processing sends a status mail to the sender stating either that the alert has been
con rmed successfully, or that an error has occurred. The alert ID must be included in the body of the reply mail.
Con rming Alerts by SMS Message
A service provider is required for con rming alerts by SMS. The alert system itself can only work with incoming mails. The SMS
message con rming the alert is sent to an SMS-to-mail service. The text of the message must include the alert ID. The service
converts the SMS message into a mail and forwards this to the alert system. The status mail from the alert system to the sender is
sent to the mail address of the SMS-to-mail service, but it is also possible to send the status mail back to the mobile device using a
mail-to-SMS service.
Con rming Alerts by an Application
Besides the user-driven con rmation, it is possible to con rm within an application. Therefore, the application uses the
corresponding API-function module SALRT_CONFIRM_ALERT.
Example
Business contract 1 has a critical status, for example Customer escalation. An alert is raised whereby the responsible manager
is informed. Before the responsible manager can react, a follow-up contract 2 is changed and leads to an update of contract 1.
This update induces that the customer escalation is no longer relevant. In such a situation, the deletion of the escalation
should imply the automatic con rmation of the corresponding alerts.
Con guring Alert Processing

Use
There are several options that can be con gured concerning the processing of alerts. These settings affect all alerts of all
categories processed using the current system as the central alert system. For the general use of the Alert Management you do
12/20/2019
not have to change the default settings. However, if for example you want to be able to con rm alerts by SMS/Internet mail, or to
have logs written, then you have to con gure alert processing.
Prerequisites
The authorization activities as described in section Authorization Concept are assigned to your SAP user.
Procedure
1. From the alert category de nition environment (transaction ALRTCATDEF), choose Settings Con guration .
2. Ensure you are in change mode.
3. If you want to be able to con rm alerts by SMS or Internet mail, you must enter the user created to receive all incoming
mails in the Inbound Processing section. For more information, see Alert Con rmation.
4. In the Status Handling for Mails section, you can specify which statuses are to be reported. The rst setting refers to the
system being informed, and the second refers to a status mail being sent to the sender.
5. In the Logging section, select Write Log only if you want additional information about the actual processing of the alerts.
This information is logged using the standard application log and can be viewed in transaction SLG1 (object ALERT).
Result
You have con gured the alert processing.
Note
If the alerts are sent from the central alert with external communication methods (e-mail, sms, or fax), the chosen external
communication method must be correctly con gured in SAPconnect.
Administration Reports
Use
A number of administration reports exist for Alert Management. You must schedule these reports according to your requirements.
Prerequisites
The authorization activities as described in section Authorization Concept are assigned to your SAP user.
Functions
The following table lists the reports together with their functions:
Report Name Function
RSALERTPROC The report is necessary for the productive use of ALM. It is

responsible for:
Escalation - The report must be executed, if classi cations

and categories have to be escalated. If the report is not
executed, you are able to activate the escalation option in
12/20/2019
transaction ALRTCATDEF on the Properties tab, but the
alert is not escalated.
Reorganisation - Deletes old protocols and con rmed alerts.
Multiple noti cation - With multiple noti cation the

recipients receive several noti cations for the same alert, if
the alert is not con rmed. The recipients are noti ed as
often as is speci ed in transaction ALRTCATDEF Properties
tab Maximum number of deliveries. The time interval
depends on the report execution interval.
Log display - The report must be executed, if you want to

display logs as spool lists.
RSALERTDISP Test report for displaying alerts and associated data on the central
server.
RSALERTTEST Test report for testing alerts
Note
This report only functions on the central alert management
server. You can send alerts with this report, however, not via RFC.
It does not test the connections from local systems to central
alert server.
Activities
The following describes how to use the different reports:
RSALERTPROC
Proceed as follows for the correct execution of report RSALERTPROC:
1. In the top report elds, you can enter the classi cations and categories for which you want the report to become active.
You can also use placeholders, such as asterisk *.
2. You can then choose if alerts are deleted after expiry time, escalated, or delivered various times according to the report
execution interval. The number how often the alert is sent to the recipients is entered in the Properties tab in transaction
ALERTCATDEF.
3. You can also choose to delete old alerts or old logs and enter the number of days, after which they are to be deleted. In the
case of deleting old alerts, you can also choose to have only con rmed alerts deleted.
4. It makes sense to use different jobs for the report RSALRERTPROC according to its various purposes: escalation, multiple
delivery, reorganization. For example, one job for the escalation every 5 minutes and one for the reorganisation on Sunday
evening. You just have to save report variants, for example, Escalation variant. Then choose System Services Jobs De ne
Jobs , and de ne the Job with the Escalation report variant as ABAP program.
RSALERTDISP
You can display alerts by ltering them according to category, classi cation, number of deliveries, status, external ID, or
creation/escalation date and time.
RSALERTTEST
When executing report RSALERTTEST, you can choose the alert category for which you want to test ALM noti cation. The report
then triggers a test alert for the category and returns the ID of the created alert.
12/20/2019
UWL Con guration for Viewing ALM alerts

Use
Note
This documentation is only relevant if you have an SAP Enterprise Portal installed and con gured in your landscape.
The Universal Worklist (UWL) of Enterprise Portal can poll for ALM alerts in the ALM system and display the alerts.
Process
The following describes the basic steps necessary to view ALM alerts in the UWL. You nd further information in the UWL
con guration documentation:
1. The ALM system has to be made known to the Portal ( System Con guration Portal Content alertsystems ).
2. Then the system has to be determined as UWL system in the UWL administration with the connector AlertConnector.
3. Finally, the users between Portal and the ALM system have to be mapped in the user mapping so that the portal user
knows under which user the ALM alerts can be found in the ALM system.
Authorization Concept
Use
For the interaction with the Alert Management the following scenarios are possible:
Starting from an application scenario, you edit some alert categories. Editing implies the creation, display, modi cation,
deletion, and the transport of categories. Additionally, you work with related recipient data, for example xed recipients,
recipients through user roles, and subscription authorizations.
Independent of the application, you con gure the landscape of the alert management from a technical point of view. This
includes the de nition of the central alert server and protocol functionality.
You schedule and set the parameters of the administration reports.
Applications, users, or proxy users on a local alert system call the central alert server in order to receive the alerts of a
certain user, to escalate, to con rm, or to forward an alert, and so on.
Prede ned User Roles
Note
Note that you do not need to give the end user any additional authorization.
The following prede ned user roles are available for customizing and administration:
SAP_BC_ALM_CUST for customizing authorization.
SAP_BC_ALM_ADMIN for administration authorization. The administrator has the authorization for all activities. He or she
can also read and con rm alerts for other users. In addition, the administrator can execute report RSALRTPROC to delete,
escalate, and deliver alerts as well as to delete logs.
12/20/2019
For the sending of alerts via external communication methods (e-mail, sms, fax) and for inbound processing, an RFC user
has to be created on the central alert server with the role SAP_BC_ALM_ALERT_USER. The authorization objects
contained in this role are S_OC_SEND and S_RFC.
Authorization Objects
In case you prefer to create your own user roles that are more appropriate for your application or landscape, SAP offers the
following authorization objects:
S_ALM_CUST - Application Speci c Customizing
The authorization object S_ALM_CUST is checked when you edit, display, or transport any alert category (transaction
ALRTCATDEF). Since parts of these tasks can also be handled by table view (transaction SM30), the object is also checked there.
The following activities can be assigned:
Change, create, and delete alert de nitions and associated data (technical key 02)
Display alert de nitions and associated data (technical key 03)
Transport alert de nitions and associated data (technical key 21)
S_ALM_CONF - Landscape Speci c Con guration
The authorization object S_ALM_CONF is checked as soon as the landscape con guration is invoked. This con guration can be
accessed
in transaction ALRTCATDEF by choosing Settings Con guration .
using the table view maintenance options (transaction SM30) of table SALRTCONF
The following activities are available:
Change the setting (technical key 02)
Display the setting (technical key 03)
The same applies to the maintenance of the RFC destination to the central alert server on the local systems (via transaction
SALRT1). The checks are only performed in local systems as of release SAP NetWeaver '04.
The same activities are offered:
Change, create, delete, or transport destination to central alert server (technical key 02)
Display the destination to central alert server (technical key 03)
In order to be able to start the administrative reports, the user needs the authorization to execute reports RSALERTDISP and
RSALERTPROC (technical key 16).
S_ALM_ROLE - Runtime Modi cation of Alerts of Other Users
Whenever a user tries to manipulate or to display the alerts of another user, the corresponding activities of authorization object
S_ALM_ROLE are checked.
The following activities are available:
Change the alerts for other users (technical key 02)
12/20/2019
Display the alerts of other users (technical key 03)
The API function modules only perform the checks.
Appendix: Business Add-Ins

Use
A number of Business Add-Ins (BAdIs) are available to enable you to make enhancements without having to perform a
modi cation.
BAdI ALERT_EXP_DATE
Method GET_EXP_DATE
This method is used to determine the expiry date of an alert. It is provided with the alert category as lter value.
The method is called if the application does not pass any expiry date in the container.
Parameter Meaning
FLT_VAL Filter value of BAdI (alert category in this case)
II_CONTAINER Container with parameters passed by the application
IP_LOGHANDLE Current log (you can add your own messages)
RP_EXP_DATE Desired expiry date as time stamp
Example
For an example implementation with an expiry time of one day (86,400 seconds), see the BAdI ALERT_EXP_1DAY.
BAdI ALERT_EXIT
Method TO_BE_DELETED
This method is called immediately before an alert is deleted, and enables the application to react at this point in time.
Parameter Meaning
IO_ALERT Alert to be deleted
Method WAS_CONFIRMED
This method enables the application to react after an alert has been con rmed.
Parameter Meaning
IO_ALERT Alert that was con rmed
12/20/2019
IP_UNAME User who con rmed the alert (optional)
Method MODIFY_LONG_TEXT
This method enables the application to change the content of the long text after it has been created.
Parameter Meaning
IO_ALERT Current alert
IP_LANGU Current language
CT_LONG_TEXT Text
BAdI ALERT_DELIVERY
Method DECIDE
This method enables the application to override the standard implementation for time-dependent delivery (personalization).
Parameter Meaning
IO_ALERT Alert
IS_PERS Personalization data
IP_UNAME User name
IP_PROTOCOL Log handle
PE_PAG Dispatch by SMS
PE_INT Dispatch by Internet mail
PE_FAX Dispatch by fax

SAP Alert Notification

Uploaded by

Copyright:

Available Formats

You might also like

SAP Alert Notification

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP Alert Notification

Uploaded by

Copyright:

Available Formats

12/20/2019

Alert Management (BC-SRV-GBT-ALM)

SAP NetWeaver 7.5 | SPS16

Original content: https://help.sap.com/viewer/ﬀf5965a513a4c69ae68f8c6cafb5d22/7.5.16/en-US

For more information, please visit the https://help.sap.com/viewer/disclaimer.

Alert Management (BC-SRV-GBT-ALM)

Merging of alerts that are related from a content perspective.

Alert Noti cation Step-by-Step

In applications accessing alerts via the API

You can personalize the way in which you receive alerts.

Alert Classi cation

De ning Alert Classi cations

1. Open the alert category/classi cation de nition environment (transaction ALRTCATDEF).

2. Ensure you are in change mode.

4. Under Classi cation, enter a name for the classi cation.

5. Under Description, enter a description of the classi cation.

7. Save your entries.

2. Enter a name for the new rule and choose Create.

4. Under Description, enter information about the newly-created rule.

For information, see Rule-Based Proposal for Binding De nitions.

An alert category is de ned by the following:

Technical key (language-independent) for identi cation purposes

Expiry time (in minutes) after which the alert is deleted

Tolerance time before escalation

Short text, long text, and title

Subsequent activities in the form of URLs

De ning Alert Categories

2. Choose Create Alert Category.

4. In the Description of Alert column, enter a description of the alert category.

5. On the Properties tab page:

9. Save your entries.

Internal Usage of the Container

Name Meaning Typing

_ALERT_RECIPIENTS Recipient list type salrttrcp

_ALERT_ACTIVITIES Subsequent activities type table of salrtsacti

_ALERT_EXPIRATION Expiry date/time (time stamp) type timestamp

_ALERT_DYNAMIC_SHORTTEXT Short text type salrtdcatd (CHAR60)

_ALERT_DYNAMIC_LONGTEXT Long text type table of CHAR255

_EVT_OBJECT Triggering object type BORIDENT

_ALERT_LOGICAL_SYSTEM Logical system in which the alert is triggered type RFCDEST

Transporting Alert Categories

There must exist the corresponding transport connection.

1. Open the ALM customizing transaction ALRTCATDEF.

2. Choose Transport Current Alert Category or Transport all alert categories.

You are asked to specify a customizing request.

3. Choose an existing customizing request or create a new one.

CCMS triggering alerts if the corresponding autoreaction was assigned in CCMS.

Triggering by Calling a Function Module Directly

Triggering by Calling a Function Module in the Workplace Plug-In

Triggering with an Event Linkage

Triggering from a Work ow

Triggering from CCMS with autoreaction

Administrator Determines Recipients

Application Determines Recipients

Alert Con rmation

There are two ways to con rm an alert:

Alert Con rmation with Inbound Processing