Alerts auslösen
Alerts einer bestimmten Kategorie müssen zur Laufzeit von einer Anwendung ausgelöst werden. Dafür gibt es verschiedene Möglichkeiten. Sie können einen Funktionsbaustein direkt oder über Middlewarekomponenten, die Alerts auslösen, aufrufen, wie z. B.:
Business Object Repository (BOR) löst Ereignisse aus, wenn bestimmte Änderungen in einem BOR-Objekt auftreten (Ereigniskopplung). Es wird beispielsweise ein Alert ausgelöst, wenn eine Bestellung geändert wurde.
Das Post Processing Framework (PPF) überprüft bestimmte Bedingungen und löst Alerts aus, wenn diese Bedingungen eintreffen.
SAP-Workflow
CCMS löst Alerts aus, wenn in CCMS die entsprechende Autoreaktion zugeordnet wurde.
Es gelten folgende Voraussetzungen für das Auslösen von Alerts:
Der zentrale Alert-Server muss im lokalen System in Transaktion SM59 als RFC-Destination angegeben werden. Er muss auch als RFC-Destination in der Transaktion SALRT1 oder in (Dies ist der eindeutige Eintrag in der Tabelle TALRTDST).
Hinweis
Wenn der zentrale Alert-Server auf dem lokalen System im gleichen Mandanten läuft, müssen Sie die RFC-Destination nicht angeben. In diesem Fall geben Sie in Transaktion SALRT1 einfach KEINE ein.
Wenn die Alerts vom zentralen Alertsystem mit einer externen Kommunikationsart (E-Mail, SMS oder Fax) gesendet werden sollen, muss die gewählte externe Kommunikationsart in SAPconnect ordnungsgemäß konfiguriert sein.
Hinweis
Bei der SAPconnect-Konfiguration müssen die Kommunikationsdaten (z. B. die E-Mailadresse) über die Transaktion SU01 in den Benutzereinstellungen des Empfängers angepasst werden.
Die verschiedenen Möglichkeiten zum Auslösen eines Alerts sind im Folgenden ausführlich beschrieben.
Das Funktionsmodul SALRT_CREATE_API wird direkt durch die Anwendung im lokalen System aufgerufen und übergibt die Daten per RFC an den zentralen Alert-Server.
Der einzige obligatorische Importparameter ist die Alert-Kategorie (IP_CATEGORY). Die Parameter IP_EXPIRATION_TIME und IP_EXPIRATION_DATE sind optionale Importparameter für Verfallszeit und -datum. Der optionale Importparameter IP_WAIT_ON_COMMIT steuert, ob ein Alert sofort oder erst beim nächsten Commit ausgelöst wird. Standardmäßig wird auf das Commit der Anwendung gewartet.
Beim Auslösen über den Funktionsbaustein können Sie auch dynamische Folgeaktivitäten definieren. Diese können beispielsweise verwendet werden, wenn eine Folgeaktivität einen Beleg referenzieren soll, der erst zur Laufzeit zum Alert hinzugefügt wird. Sie übergeben diese Aktivitäten an den Funktionsbaustein, indem sie eine interne Tabelle der Struktur SALRTSACT füllen und diese Tabelle als Tabellenparameter IT_ACTIVITIES an den Baustein übergeben. Die Struktur SALRTSACT enthält einen Namen für die Aktivität im Feld ACTTEXT und die URL, die die Folgeaktivität im Feld ACTURL referenziert.
Über die Parametertabellen IT_EXT_RECIPIENTS, IT_EXT_ADDR und IT_ROLES können Sie Nicht-SAP-Benutzeradressen, SAP-Benutzer (Eintrag in der zentralen Adressverwaltung) und SAP-Rollen als zusätzliche Alert-Empfänger hinzufügen.
Mithilfe des SAP Workplace Plug-Ins können Sie das Alert-Management SAP Web AS 6.10 oder ältere SAP-Basis-Releases verwenden. Der Name des Funktionsbausteins zum Auslösen eines Alerts lautet SALERT_CREATE_API. Dieser Funktionsbaustein enthält eine Schnittstelle analog zur zuvor beschriebenen Schnittstelle SALRT_CREATE_API.
Für das zentrale Alert-Management ist SAP Web AS 6.20 oder höher erforderlich. Die Alertfunktion erweitert lediglich das lokale Alert-System. So kann beispielsweise eine Anwendung, die auf SAP Web AS 6.10 oder einem älteren SAP-Basis-Release basiert, über den oben genannten Funktionsbaustein Alerts in einem Customer-Exit auslösen.
Ein Alert kann auch durch ein im Business Object Repository (BOR) definiertes Ereignis ausgelöst werden. In der Transaktion SWE2 im lokalen System geben Sie die Alert-Kategorie als Verbrauchertypen und den Funktionsbaustein SALRT_CREATE_VIA_EVENT als Verbraucherfunktionsbaustein für das Ereignis ein. Das Alert Framework empfängt Ihre Alert-Kategorie aus Ihrem Eintrag in der Ereigniskopplungstabelle.
Hinweis
Wenn Sie anwendungsspezifische Attribute benötigen, müssen Sie entsprechende Attribute für das Objekt im BOR definieren. Der Verbraucherbaustein bestimmt alle Nicht-Tabellen-Attribute, die für das auslösende Objekt im BOR definiert sind, und schreibt Sie in den Alert-Container, vorausgesetzt, die Attribute sind in der Definition der Alert-Kategorie auch als Elemente des Alert-Containers definiert.
Alternativ können Sie einen Check-Funktionsbaustein oder einen Verbraucherbaustein implementieren. Dadurch können Sie den Container Ihren Anforderungen entsprechend füllen.
Hinweis
Sie sollten nur Alerts mit Ereigniskopplung auslösen, wenn Sie bereits ein BOR-Objekt für Ihre Anwendung implementiert haben.
Wenn Sie das PPF oder die NAST zum Auslösen von Alerts verwenden, können Sie allgemeine Bedingungen definieren und eine Ausgabe (z. B. einen Ausdruck, eine Internet-Mail oder einen Workflow) initiieren. Das Auslösen eines Alerts kann als Methodenaufruf (PPF) oder durch das Schreiben eines Verarbeitungsprogramms für das Medium "Sonderfunktion" (NAST) modelliert werden.
Achtung
Sie sollten nur Alerts mit PPF/NAST auslösen, wenn Sie PPF/MC in Ihrer Anwendung bereits verwenden.
Sie können das Auslösen eines Alerts als Schritt in einer Workflow-Definition hinterlegen, auch wenn Sie dazu normalerweise einen vorhandenen Workflow erweitern würden. Elemente des Workflow-Containers können als Attribute verwendet werden. Weitere Informationen zu Workflows finden Sie unter SAP Business Workflow (BC-BMT-WFM).
CCMS bietet die Autoreaktionsmethode CCMS_Send_Alert_to_ALM. Wenn diese Methode einem Monitorknoten zugeordnet ist, sendet die Monitoring-Architektur die Alerts dieses Knotens ans Alert-Management. Weitere Informationen zum Verwenden dieser Autoreaktion finden Sie in Alerts an das Alert Management (ALM) weiterleiten.
Der folgende Beispielreport RSALERTDEMO1 zeigt, wie ein Alert direkt von einem Funktionsbaustein aufgerufen werden kann. Er ist im Paket SALERT_LOCAL enthalten.
Hinweis
Weitere Beispielreports finden Sie im Paket SALERT_DEMO.
Syntax
*&---------------------------------------------------------------------*
*& 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.