alert management

��

Release 650

HE

LP

.BC

SR

VG

BT

AL

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 user’s 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 recipient’s 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

SAPComponent

External System

(Providing Alerts)

InternetMail Cellular

Phone,SMS, Pager,

WAP, ...

Alert Inbox (Portal)

SAP Component

External AlertServer

(DeliveringAlerts)

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 recipient’s 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 application’s 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.

��



�� ! �!��"�!# !��$#%�&��'��(��)��*�+��&#,�"#�-� ��.� ��/��0�1��.2��!#$��#��, "# �!�&��" � "�# 34��5�"�!# !��,�$�!��(��6��7��8��*��-� ��.��6��.��",## �!��9��#,��"�!# !�� !",4� !:�#��, "# �!��##��0�(�� (� ��(�� ,,��"4$�!!4$3��#&��,�$�!� !�9��"�!# !��0�(��(� �� (� ��(��(��6��.�;�<.��"�#��#!�#,��"#�:�+�.� ��/��0�1��.2��#,��" � �!&�#��4!��= #�&43&" � �!��!,+2�!��>� # �!� $�� /��.�� (��(��.��?��)��(��)��*��@��(��)��*��(�?��(��@��(�?��(��@��(0��(��(��@��6 ��(��@��(��-��@��(��@� �(� ��(��?��A��@��/��*��6��$�&&#:��B9�!�"�# !:�#,��/��"�$$ �B�%��

Alert Management [Seite 1] �

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

Documents