Alert Management

A| ert Hanagement (6-8RV-
CT-ALH}

Rel ease 650
H
E
L
P
.
B
C
S
R
V
G
B
T
A
L
M

SAP Online Help 22.12.2004
Alert Management (BC-SRV-GBT-ALM) 650 2
Copyright

Copyright 2004 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP AG. The information contained herein may be
changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary
software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft
Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400,
OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner,
WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM
Corporation in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are
trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World
Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for
technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and
services mentioned herein as well as their respective logos are trademarks or registered
trademarks of SAP AG in Germany and in several other countries all over the world. All other
product and service names mentioned are the trademarks of their respective companies.
Data contained in this document serves informational purposes only. National product
specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP
AG and its affiliated companies ("SAP Group") for informational purposes only, without
representation or warranty of any kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP Group products and
services are those that are set forth in the express warranty statements accompanying such
products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
Icons in Body Text

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Additional icons are used in SAP Library documentation to help you identify different types of
information at a glance. For more information, see Help on Help General Information
Classes and Information Classes for Business Information Warehouse on the first page of any
version of SAP Library.

Typographic Conventions

Type Style Description
Example text Words or characters quoted from the screen. These include field
names, screen titles, pushbuttons labels, menu names, menu paths,
and menu options.
Cross-references to other documentation.
Example text Emphasized words or phrases in body text, graphic titles, and table
titles.
EXAMPLE TEXT Technical names of system objects. These include report names,
program names, transaction codes, table names, and key concepts of a
programming language when they are surrounded by body text, for
example, SELECT and INCLUDE.
Example text Output on the screen. This includes file and directory names and their
paths, messages, names of variables and parameters, source text, and
names of installation, upgrade and database tools.
Example text Exact user entry. These are words or characters that you enter in the
system exactly as they appear in the documentation.
<Example text> Variable user entry. Angle brackets indicate that you replace these
words and characters with appropriate entries to make entries in the
system.
EXAMPLE TEXT
Keys on the keyboard, for example, F2 or ENTER.

Alert Management (BC-SRV-GBT-ALM) ................................................................................... 5
New Features......................................................................................................................... 6
Alert Notification Step-by-Step............................................................................................... 7
Alert Inbox.............................................................................................................................. 9
Alert ...................................................................................................................................... 10
Alert Classification................................................................................................................ 11
Defining Alert Classifications............................................................................................ 11
Alert Category ...................................................................................................................... 12
Defining Alert Categories ................................................................................................. 13
Alert Container .............................................................................................................. 15
Transporting Alert Categories .......................................................................................... 17
Triggering Alerts................................................................................................................... 17
Recipient Determination....................................................................................................... 20
Alert Confirmation ................................................................................................................ 21
Alert Confirmation with Inbound Processing .................................................................... 22
Configuring Alert Processing ............................................................................................... 23
Administration Reports......................................................................................................... 25
UWL Configuration for Viewing ALM alerts ......................................................................... 26
Authorization Concept.......................................................................................................... 27
Appendix: Business Add-Ins................................................................................................ 28
Appendix: External Alert Systems........................................................................................ 30

Alert Management (BC-SRV-GBT-ALM)
Purpose
Alert Management (ALM) comes into play, when business-critical problems occur. Within
ALM, conditions for critical situations are predefined. When an alert [Seite 10] 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-specific display
programs, or the alert inbox [Seite 9]. These display programs can be personalized due to the
users needs. In addition, the users can receive alerts as e-mail, sms, and fax, if these
external methods of communication are configured in SAPconnect. End users can
personalize their alert notifications, for example, create notification 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 specific business or technical
situations that are critical and could jeopardize efficient operation, and you want specific
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.

For local systems of SAP Web AS release 6.10 or lower you need a specific
workplace plugin.

Integration
The Alert Framework is provided as part of the SAP Web Application Server. The application
that wants to trigger alerts must define its own alert categories, assign them to alert
classifications and implement the triggering of the alert instances to realize Alert
Management. (For more information, see Alert Classification [Seite 11], Alert Category [Seite
12], and Triggering Alerts [Seite 17].) Alerts can also be triggered by external alert providers
[Seite 30]. They are all sent to the display program (UWL, application-specific program, or
alert inbox) of the defined alert recipients. Additionally, alerts can be sent by other channels,
such as by Internet mail, SMS, or to external alert systems.
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 configure [Seite 23] alert processing to be able to send alerts to
third-party systems, to be able to confirm alerts by SMS/Internet mail, or to have logs writenn.

If you want to send alerts not only to the recipients display program (UWL,
application-specific program, or alert inbox), but also via external communication
methods (e-mail, sms, and fax), the chosen communication type must be
correctly configured in SAPconnect [Extern].

SAP
Component
(e.g. R/3 Enterprise,
CRM, SCM, PLM)
SAP Web AS
Alert Engine
SAP
Component
External
System
(Providing
Alerts)
Internet
Mail
Cellular
Phone,
SMS, Pager,
WAP, ...
Alert Inbox (Portal)
SAP
Component
External Alert
Server
(Delivering
Alerts)

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 [Seite 17].) The
alert recipients are determined either by the application, by an administrator, or using a
subscription procedure. (For more information, see Recipient Determination [Seite 20].) An
alert outlining the situation is delivered to the recipients immediately. Depending on the
configuration, the alert can be viewed by the recipients in the UWL, application-specific
display programs, or in the alert inbox [Seite 9]. 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 configured in SAPconnect. If the receipt of the alert is not confirmed
[Seite 21] by any of the recipients, the alert can be sent to an escalation recipient.
For a detailed list with new ALM Features for SAP Web AS 6.40, see also New Features
[Seite 6].

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 confirming that a subsequent activity has been executed, using
SAP Business Workflow.
Merging of alerts that are related from a content perspective.

New Features

Alert Management was first introduced with SAP Web Application Server 6.20. A number of
enhancements to the Alert Management system is shipped with SAP Web Application Server
6.40:
In the alert inbox [Seite 9], end users have already been able to choose the
communication channel via which they want to receive alerts. The options available
were enhanced by the addition of calendar-based rules. This means that a user is able
to choose to receive alerts only in his or her alert inbox during the day, as a text
message to his or her cellular phone outside this time, and asan e-mail if he or she is
on vacation, for example.
Transaction ALRTCATDEF_SEL allows the maintenance of alert categories of a given
alert classification. For example, you can choose to display only the alert categories
with the classification CCMS Alerts, which makes sense on a central server.
New authorization concept [Seite 27]
Different types of subsequent activities
An alert has title, short text, and long text. Until now the short text had been used as
mail title. Now 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.
Alert classifications [Seite 11] can now have subclassifications. This enables you to
build up your own classification hierarchy.
With the new interaction possibilities, you can pass an application GUID when
triggering an alert. The application can be updated after an alert was confirmed and all
alerts of a given scenario can be confirmed. For example, a processed receipt has a
unique GUID. Therefore, you can query directly, if there are confirmed alerts for this
receipt.
Roles are passed when triggering alerts and all users in this role will get the alert.
Extended demo applications are available in package SALERT_DEMO.
Container supports table and structure types.
Extension of the API for external recipients. This will make it possible to inform people
about critical situations or integrate people into business processes, even if they do not
generally work with an SAP system or do not have an SAP user license at all.

Alert Management [Seite 1]

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 [Seite 27].
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
[Extern] and Authorization Concept [Seite 27]). 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 systemor 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 [Extern], 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 [Seite 11]. 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 [Seite 13]. The
category [Seite 12] 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 [Seite 20] 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 [Seite 23]. 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 [Seite 25] 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 [Seite 17] 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
[Extern], in application-specific display programs, or in the alert inbox [Seite 9]. 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 [Seite 21], 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 [Seite
22] for this.


Alert Inbox
Use
The alert inbox is user-specific and shows all alerts that are sent to you in accordance with
the alert configuration.
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 configured
for you and you have chosen this way of notification in the personalization. However,
irrespective of these external communication methods, you find 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).

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 [Extern]
or application-specific display programs can be found in the corresponding
documentation.
Prerequisites
The alert inbox is configured 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 confirm.
Confirmed alerts are deleted from the alert inbox list. If configured, alerts can also be
confirmed by e-mail, or SMS by merely sending a reply e-mail or SMS. For confirmation
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 recipients together with a
description of why the alert is sent to these specific users. You can find information on
how recipients are determined in the Recipient determination [Seite 20] section. Also
you can find possible follow-up actions on the corresponding tab page.
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 notification.
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.

The default communication channel options in the Personalization screen are
Mail, FAX, SMS, and WAP. Optionally, the administrator can offer you the
possibility to send alerts to an external system as XML documents. If your
administrator has set up this possibility for you, you can choose also XML in
your Personalization screen.
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 classification of a
category on the same screen; for example the category Contract cancelled has the
classification CRM.
Alert
Definition
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.

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 [Seite 12].

Example
An alert could be used to notify recipients in the event of a production standstill or a budget
being exceeded, for example.


Alert Classification
Definition
To be able to send different types of alerts under specific conditions, different alert categories
[Seite 12] are to be defined. A category contains various properties and other specifications
that define the alerts within that category, for example expiry date, or the escalation recipient.
Alert categories can be assigned to an alert classification. If you do not want to create a
classification on your own, you can always create categories within the default classification
folder Unclassified. However, for a better overview, it is recommendable to create different
alert classifications to group alert categories that belong to the same topic. For example, you
can create the alert classification CRM to group all CRM specific categories such as Contract
Cancelled and Decrease in Sales. Alert classifications can have sub classifications which
enables you to build up your own classification hierarchy.
Alert classifications are defined in the Alert Management Configuration transaction
ALRTCATDEF, see also Defining Alert Classifications [Seite 11].


Defining Alert Classifications
Use
Alert classifications [Seite 11] are used to group alert categories [Seite 12] according to their
subject. Several categories from one application could be assigned to the same classification,
for example. When using transaction ALRTCATDEF_SEL or the administration reports [Seite
25] RSALAERTDISP and RSALERTPROC, the administrator can simply enter the
classification to process all alerts of all categories assigned to that classification.
Since sub-classifications are supported, you can build up an elaborated hierarchy for the
various application scenarios. For instance, you define top-classifications like CRM, APO, BW
and beneath these classifications you create your sub-classifications.

Alert categories can be assigned to specific alert classifications. If you do not
need a specific classification for a certain kind of alerts, you can use the default
classification folder Unclassified. You find this folder when you follow the
procedure description below until step 3.
Procedure
...
1. 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.
5. Under Description, enter a description of the classification.
6. Optional: If you want to create a sub-classification, open the context menu of the
classification, choose Create, and enter a name and description for the sub-
classification.
7. Save your entries.

Result
You have created a classification for alert categories. When you define alert categories in the
definition environment, this classification will now be available for selection.

Example
If you want to group all your mySAP CRM alert categories together, you could create a
classification called CRM with description Customer Relationship Management.
Beneath this category you could for example create the sub-categories Orders and
Marketing.

Alert Category
Definition
An alert category contains various properties and other specifications that define the alerts
[Seite 10] within that category. The category defines the conditions when a specific alert is
sent to whom.
Use
Alert categories can be defined by applications or customers using the alert category
definition environment, which is accessed in transaction ALRTCATDEF. You can define an
alert category to suit your business requirements. 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.
Integration
An alert category can be assigned to a specific alert classification. Alert classifications [Seite
11] help to organize and group alert categories. If you do not assign a category to a specific
classification, it will be stored in the classification folder Unclassified.
Structure
An alert category is defined by the following:
Technical key (language-independent) for identification purposes
Description (language-dependent)
Classification
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 confirmed 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 definition if variables are to be used in the texts, or for other
application-specific attributes
Subsequent activities in the form of URLs
For more information about these properties and specifications, see Defining Alert Categories
[Seite 13].


Defining Alert Categories
Use
During alert category definition, you specify the alert text, expiry time, escalation, and all other
conditions related to the sending of this kind of alert.

Prerequisites
You must be familiar with the business aspects of the critical situation for which the alert
category is to be defined. In addition, the authorization activities should be assigned to your
SAP user as described in section Authorization Concept [Seite 27].

Procedure
...
1. Ensure that you are in change mode in the alert category definition 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 identifies the alert
category. The standard namespace convention applies to the key, this means keys Z*
und Y* belong to the customer name space.
4. On the Properties tab page:
...
a. In the Description field, enter a description for the alert category. Choose a
description that is informative with respect to the content of the alert category.
The description is language-dependent.
b. If required, you can select a classification in the Classification field. If you do not
choose a specific classification, the category is stored in the classification folder
Unclassified. For more information on classifications, see Alert Classification
[Seite 11].
c. In the Max. No. of Dels field, specify a maximum number of times that an alert of
this category is to be delivered if it is not confirmed. This refers to delivery using
a communication channel other than to the recipients display program (UWL,
application-specific program, or alert inbox [Seite 9]).
d. Select Dynamic Text if the texts of the alert category cannot be defined 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.

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. field, you can enter a life span for alerts of this
category if the alerts will no longer be relevant after a specific 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 first to the
data provided by the triggering application, second to the BAdI
ALERT_EXP_DATE [Seite 28], and third to this field in the alert category
definition. If none is found in any of these sources, the default expiry of
31.12.2099 applies.
f. 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 confirmed the alert after this tolerance time. The escalation
recipient is also informed that he or she has received the alert because of an
escalation.

The escalation functionality is based on the administrator report
RSALERTPROC. This report has to be scheduled as a regular job. For
information on this report, see Administration Reports [Seite 25].
5. On the Container tab page, define any variables that you may want to use in the short
text or long text. You can also define other application-specific 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 [Seite 15].
6. On the Short and Long 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 defined in the alert container. The
entry in the text must be in the form &<ElementName>&.

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.
7. 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 [Seite 17].
8. Save your entries.

Result
The alert category has been defined. You can now implement the recipient determination for
this category.

Alert Container
Definition
The alert container is a container for the exchange of (application-specific) 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-specific variables in your container definition, 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.

When the container is filled, no check is performed as to whether the elements
entered and the data type of their values are in accordance with the container
definition. You must ensure that the element names and the data types that you
use are in accordance with the definition.

Due to technical restrictions between the Workflow Container and SAPscript,
only the first 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 [Extern] in the SAP Business Workflow documentation.
Internal Usage of the Container
The Alert Framework uses the alert container not only for the exchange of application-specific
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

If you define your own variables, ensure that no naming conflicts 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 fill an internal table of the structure SALRTSACTI and write the table into the
container with the element name _ALERT_ACTIVITIES.

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
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 customizing client in transaction SCC4, the detail setting Automatic recordings of
changes has to be selected in the group box Changes and Transports for Client-
Specific 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
Purpose
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 Workflow
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.)

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 configured in SAPconnect [Extern].

During SAPconnect configuration, the communication data, for example e-mail
address, has to be customized in the user settings of the recipient in transaction
SU01.

Process Flow
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 applications commit.
When triggering using the function module, it is also possible to define 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 filling 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 field ACTTEXT, and the URL that refers to the subsequent
activity in the field 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 defined 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.

If you need application-specific attributes, you must define appropriate attributes
for the object in the BOR. The receiver module determines all non-table
attributes that are defined for the triggering object in the BOR, and writes them
into the alert container, providing the attributes are also defined as elements of
the alert container in the definition 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.

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 define general conditions and initiate output,
such as printing, sending an Internet mail, or starting a workflow. 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).

You should only trigger alerts using PPF/MC if you already use PPF/MC in your
application.

Triggering from a Workflow
You can define the triggering of an alert as a step in a workflow definition, although you would
usually only do this as an extension to an existing workflow. Elements in the workflow
container can be used as attributes. For more information on workflows, see SAP Business
Workflow (BC-BMT-WFM) [Extern].

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) [Extern].

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.

*&---------------------------------------------------------------------*
*& Reporf RSALRT0Eh01 *
*& *
*&---------------------------------------------------------------------*
*& *
*& *
*&---------------------------------------------------------------------*

REP0RT RSALRT0Eh01 .

ThCLU0E <ChTh01>. "de1h1f1oh o cohfa1her makros

C0hSTAhTS. C_CATE00RY fype saTrfdcaf vALUE `ALRTFRhWRKTEST`,
* hame o appT1caf1oh spec11c affr1bufe 1 cohfa1her eTemehf
C_00ChUhER{10} TYPE C vALUE `00ChUhER`.

* decTaraf1oh o fhe aTerf-cohfa1her 1hcTud1hg appT1caf1oh dafa
SWC_C0hTAThER LT_ALERT_C0hTAThER.

* 1TT documehfhumber as eTemehf 1h fhe cohfa1her
SWC_SET_ELEhEhT LT_ALERT_C0hTAThER C_00ChUhER `0815`.

* creafe ah aTerf o cafegory `ALRTFRhWRKTEST`,
* aTerf-rec1p1ehfs are ouhd v1a subscr1pf1oh ohTy, ho exp1raf1oh f1me
CALL FUhCTT0h `SALRT_CREATE_APT`
EXP0RTTh0
TP_CATE00RY = C_CATE00RY
* TP_EXPTRATT0h_TThE =
* TP_EXPTRATT0h_0ATE =
* TP_WATT_0h_C0hhTT =
TALES
* TT_RECTPTEhTS =
* TT_ACTTvTTTES =
TT_C0hTAThER = LT_ALERT_C0hTAThER
EXCEPTT0hS
0ThERS = 1.
TF SY-SURC hE 0.
* message "error Wheh creaf1hg aTerf
Eh0TF.

comm1f Work.


Recipient Determination
Purpose
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 defined the alert category for which the recipients are to be determined. For more
information, see Defining Alert Categories [Seite 13]. In addition, the authorization activities
should be assigned to your SAP user as described in section Authorization Concept [Seite
27].

Process Flow
The various options for determining recipients are detailed below. They can be used in
combination.
User subscription
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
definition 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 [Seite 9].

Administrator Determines Recipients
A system administrator determines the recipients of a particular alert category in the definition
environment (transaction ALRTCATDEF). The administrator can define individual recipients
(using Fixed Recipients) or roles (using Recipients Via User Roles). If a role is specified, 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 specific 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 specific 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.

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-specific reasons.

Alert Confirmation
When an alert is confirmed, its status is changed and it will not be delivered, escalated, or
displayed.
There are two ways to confirm an alert:
Generally, alerts are confirmed by the recipient in his or her display program (UWL,
application-specific program, or alert inbox [Seite 9]). The users just have to select the
alerts to be confirmed, and to choose the alert confirmation option.
If an alert is sent by Internet mail or SMS message, it is also possible to confirm 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
Confirmation with Inbound Processing [Seite 22].


Alert Confirmation with Inbound Processing
Use
If an alert is sent by Internet mail or SMS message, it is also possible to confirm alerts by
sending an Internet mail or SMS message back to the SAP system. Alert Management uses
inbound processing for this.
Prerequisites
The following prerequisites have to be met in order to confirm alerts with inbound processing:
A user has been created to receive the mails confirming the alerts. An Internet mail
address has been assigned to this user. The user has been entered for inbound
processing in alert configuration [Seite 23].
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.

The incoming e-mails have to be processed via an SMTP plugin. You find
further information in the SAPconnect [Extern] documentation.
Activities
Confirming Alerts by Internet Mail
When an alert is sent by Internet mail, the Internet address of the alert user entered in alert
configuration 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
confirmed automatically. Inbound processing sends a status mail to the sender stating either
that the alert has been confirmed successfully, or that an error has occurred. The alert ID
must be included in the body of the reply mail.

Confirming Alerts by SMS Message
A service provider is required for confirming alerts by SMS. The alert system itself can only
work with incoming mails. The SMS message confirming 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.

Confirming Alerts by an Application
Besides the user-driven confirmation, it is possible to confirm within an application. Therefore,
the application uses the corresponding API-function module SALRT_CONFIRM_ALERT.

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 confirmation of the corresponding alerts.

Configuring Alert Processing
Use
There are several options that can be configured 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 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.
Prerequisites
The authorization activities as described in section Authorization Concept [Seite 27] are
assigned to your SAP user.
Procedure
...
1. From the alert category definition environment (transaction ALRTCATDEF), choose
Settings Configuration.
2. Ensure you are in change mode.
3. In the Processing section, you can choose if the alerts are to be processed internally or
using an external system:
Internal Processing
If you select this option, the alerts are created and processed on the central alert
server. However, you can also offer the users the possibility to choose if they want
alerts to be sent to an external system as XML documents, see point 4 below.
SMTP Forwarding as XML
If you select this option, all alerts are forwarded using SMTP to an external alert system
as XML documents. You must specify a forwarding e-mail address for the XML
documents (see also Appendix: External Alert Systems [Seite 30]).
HTTP Forwarding as XML
If you select this option, all alerts are forwarded using HTTP to an external alert system
as XML documents. You must specify a destination for the XML documents (see also
Appendix: External Alert Systems [Seite 30]).
4. In the Personalization section, you can offer the users the possibility to choose if they
want alerts to be sent to an external system as XML documents.
Select Offer XML in Personalization and enter an e-mail address or HTTP destination
for the external system. The users can then select XML in the personalization of their
alert inboxes [Seite 9].
5. If you have selected either of the external processing options above, you can select
certain options in the XML Formatting section.
Category Check
If you select this option, the current alert category is checked against customizing data
before the alert data is sent to the external alert server.
Add Recipients
If you select this option, the fixed and subscribed recipients of the current alert category
are passed to the external alert server.
Add Texts
If you select this option, the short text and the long text of the current alert category are
passed to the external alert server.
Add Subsequent Activities
If you select this option, the subsequent activities of the current alert category are
passed to the external alert server.
6. If you want to be able to confirm 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 Confirmation [Seite 21].
7. In the Status Handling for Mails section, you can specify which statuses are to be
reported. The first setting refers to the system being informed, and the second refers to
a status mail being sent to the sender.
8. 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 configured the alert processing.

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 configured in SAPconnect [Extern].


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 [Seite 27] 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 classifications and
categories have to be escalated. If the report is not executed, you
are able to activate the escalation option in transaction
ALRTCATDEF on the Properties tab, but the alert is not
escalated.
Reorganisation Deletes old protocols and confirmed alerts.
Multiple notification With multiple notification the recipients
receive several notifications for the same alert, if the alert is not
confirmed. The recipients are notified as often as is specified 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

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 fields, you can enter the classifications 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 confirmed 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 Define Jobs, and define the Job with the Escalation report
variant as ABAP program.

RSALERTDISP
You can display alerts by filtering them according to category, classification, 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 notification. The report then triggers a test alert for the category and returns
the ID of the created alert.


UWL Configuration for Viewing ALM alerts
Purpose
The Universal Worklist (UWL) of Enterprise Portal can poll for ALM alerts in the ALM system
and display the alerts.
Process Flow
The following describes the basic steps necessary to view ALM alerts in the UWL. You find
further information in the UWL configuration documentation [Extern]:
5. The ALM system has to be made known to the Portal (System Configuration Portal
Content alertsystems).
6. Then the system has to be determined as UWL system in the UWL administration with
the connector AlertConnector.
7. 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

For the interaction with the Alert Management the following scenarios are possible:
...
Starting from an application scenario, you edit some alert categories [Seite 12]. Editing
implies the creation, display, modification, deletion, and the transport of categories.
Additionally, you work with related recipient data, for example fixed recipients,
recipients through user roles, and subscription authorizations.
Independent of the application, you configure the landscape of the alert management
from a technical point of view. This includes the definition of the central alert server,
use and connection of external alert systems, and protocol functionality.
You schedule and set the parameters of the administration reports [Seite 25].
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 confirm, or to forward an
alert, and so on.

Predefined User Roles

Note that you do not need to give the end user any additional authorization.

The following predefined 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 confirm alerts for other
users. In addition, the administrator can execute report RSALRTPROC to delete,
escalate, and deliver alerts as well as to delete logs.
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 Specific 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 definitions and associated data (technical key 02)
Display alert definitions and associated data (technical key 03)
Transport alert definitions and associated data (technical key 21)
S_ALM_CONF Landscape Specific Configuration
The authorization object S_ALM_CONF is checked as soon as the landscape configuration is
invoked. This configuration can be accessed
in transaction ALRTCATDEF by choosing Settings Configuration.
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 Modification 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)
Display the alerts of other users (technical key 03)

The API function modules only perform the checks.


Appendix: Business Add-Ins
A number of Business Add-Ins (BAdIs) are available to enable you to make enhancements
without having to perform a modification.
BAdI ALERT_XML
Method ENHANCE_XML_DOCUMENT
If the central alert server is configured to send alerts to an external alert system, an XML
document is created and sent to the external system.
The BAdI method is called in the final stage of the creation of the XML document.
Parameter Meaning
II_DOCUMENT Reference to the XML document (as interface
reference to IF_IXML_DOCUMENT, see Package
DOM [Extern])
II_CONTAINER Container with parameters passed by the
application
IP_CAT Alert category
IP_LOGHANDLE Current log (you can add your own messages)
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 filter 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
RP_EXP_DATE Desired expiry date as time stamp

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 confirmed.
Parameter Meaning
IO_ALERT Alert that was confirmed
IP_UNAME User who confirmed 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


Appendix: External Alert Systems

The SAP Alert Management offers numerous options. Nevertheless, in some cases it might
be more appropriate to use an external alert system, for example a Unified Messaging
System.
Configuration for Alert Propagation to an External Alert
System
Instead of the internal processing for the alert delivery, alerts are converted into XML
documents. These XML documents are propagated to the external system in one of the
following ways:
using SMTP
An e-mail address of the external alert system must be configured in the settings of the
central alert server.
using HTTP
An HTTP destination to the external alert system must be configured in Display and
maintain RFC destinations (transaction SM59). This HTTP destination must be
configured in the settings of the central alert server.
In addition, you can offer the users the possibility to choose in their alert inbox if they want
alerts to be sent to an external system as XML documents
In order to enable the alert propagation to an external alert system, you have to make the
corresponding settings in transaction ALRTCATDEF under Settings Configuration. See
also section Configuring Alert Processing [Seite 23].
Editing of the Propagated Alerts
If an external alert system is used, the alert delivery process behaves as follows:
The XML document representing the alert is built in accordance with the corresponding
XML scheme.
The XML document is passed to the BAdI ALERT_XML. Using your own
implementation, it is possible to edit the XML documents accordingly.
Finally, the modified XML document is sent to the external alert system.

Alert Management

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Alert Management

Enviado por

Direitos autorais:

Formatos disponíveis

A| ert Hanagement (6-8RV-

Você também pode gostar