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.
You can find further example reports in the package SALERT_DEMO.
*&---------------------------------------------------------------------*
*& Report RSALRTDEMO1 *
*& *
*&---------------------------------------------------------------------*
*& *
*& *
*&---------------------------------------------------------------------*
REPORT rsalrtdemo1 .
* Here, you find almost all constants, which are relevant for
* the Alert Framework.
TYPE-POOLS:
salrt.
CONSTANTS:
* Name of your alert category
c_category TYPE salrtdcat VALUE 'ALRTFRMWRKTST',
* Name of application specific attribute / container element
c_docnumber TYPE swfdname VALUE 'DOCNUMBER'.
* Declaration of the alert-container including application data
DATA: li_container TYPE REF TO if_swf_cnt_container.
TRY.
li_container = cl_swf_cnt_factory=>create( ).
CATCH cx_swf_utl_no_instance_found
cx_swf_utl_obj_create_failed .
ENDTRY.
* Fill in the document number as an element of the container
TRY.
li_container->element_set(
name = c_docnumber
value = '0815' ).
CATCH cx_swf_cnt_cont_access_denied
cx_swf_cnt_elem_not_found
cx_swf_cnt_elem_access_denied
cx_swf_cnt_elem_type_conflict
cx_swf_cnt_unit_type_conflict
cx_swf_cnt_elem_def_invalid
cx_swf_cnt_invalid_qname
cx_swf_cnt_container .
ENDTRY.
* Create an alert of category 'ALRTFRMWRKTEST'.
* Recipient, texts and other attributes are added from
* the definition of the alert category, i.e. the document
* number is the only dynamic element of this API call.
CALL FUNCTION 'SALRT_CREATE_API'
EXPORTING
ip_category = c_category
ii_container = li_container
ip_wait_on_commit = salrt_true "An explicite COMMIT WORK statement
"within the application is mandatory for
"the alert delivery.
EXCEPTIONS
OTHERS = 1.
IF sy-subrc NE 0.
* message "error when creating alert
ENDIF.
* Here is our COMMIT WORK
COMMIT WORK.
