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.

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).

 

Triggering from CCMS with autoreaction

CCMS offers the autoreaction method CCMS_Send_Alert_to_ALM. If this method is assigned to a monitoring node, the monitoring architecture sends the alerts of this node to ALM. For more information about using this autoreaction, see Forwarding Alerts to Alert Management (ALM).

 

 

Example

The following example report RSALERTDEMO1 shows how an alert can be called directly by a function module, and is available in the package SALERT_LOCAL.

 

*&---------------------------------------------------------------------*

*& Report  RSALRTDEMO1                                                 *

*&                                                                     *

*&---------------------------------------------------------------------*

*&                                                                     *

*&                                                                     *

*&---------------------------------------------------------------------*

 

REPORT  RSALRTDEMO1                                                 .

 

  INCLUDE <CNTN01>.                 "definition of container makros

 

  CONSTANTS: C_CATEGORY type salrtdcat VALUE 'ALRTFRMWRKTEST',

*   name of application specific attribute / container element

             C_DOCNUMBER(10) TYPE C VALUE 'DOCNUMBER'.

 

* declaration of the alert-container including application data

  SWC_CONTAINER LT_ALERT_CONTAINER.

 

* fill documentnumber as element in the container

  SWC_SET_ELEMENT LT_ALERT_CONTAINER C_DOCNUMBER '0815'.

 

* create an alert of category 'ALRTFRMWRKTEST',

* alert-recipients are found via subscription only, no expiration time

  CALL FUNCTION 'SALRT_CREATE_API'

       EXPORTING

            IP_CATEGORY        = C_CATEGORY

*           IP_EXPIRATION_TIME =

*           IP_EXPIRATION_DATE =

*           IP_WAIT_ON_COMMIT  =

       TABLES

*           IT_RECIPIENTS      =

*           IT_ACTIVITIES      =

            IT_CONTAINER       = LT_ALERT_CONTAINER

        EXCEPTIONS

             OTHERS             = 1.

  IF SY-SUBRC NE 0.

*   message                         "error when creating alert

  ENDIF.

 

 

  commit work.

 

 Alert Management