Funktionsweise der Ereignissteuerung

Das Funktionieren der Kundenakte setzt voraus, dass für die AddOns eine sichere Möglichkeit besteht, Einträge an die Kundenakte zu melden. Da aus Sicht der AddOns die Existenz der Kundenakte jedoch nicht vorausgesetzt werden kann, darf das Funktionieren der AddOns bei Nichtvorhandensein der Kundenakte nicht beeinträchtigt werden. Basierend auf dieser Überlegung wird darum die Anforderung gestellt, nur eine indirekte Kommunikation zwischen den AddOns und der Kundenakte zuzulassen, welche einen im SAP-Standard vorhandenen Vermittler einsetzt, der die Sicherheit der Kommunikation gewährleistet.

Im Kontext von verteilten Systemen schlägt [TANE03] (S. 122-127 sowie S. 132-135) vor, dass diese Ziele durch den Austausch von Nachrichten erreicht werden können. Denn im Gegensatz zu andersartigen Kommunikationstechnologien, wie dem direkten Aufruf einer entfernten Prozedur oder Methode, kommt dabei immer ein Kommunikationssystem zum Einsatz, das die übermittelten Nachrichten sowohl asynchron als auch persistent behandelt. Das heißt, der Sender wird während der Übermittlung seiner Nachrichten nicht blockiert oder andersartig beeinträchtigt, während das Kommunikationssystem autonom versucht, die Nachrichten zuzustellen. Sollte dies vorübergehend nicht möglich sein, werden die Nachrichten zwischengespeichert und verschiedene Heuristiken angewandt, um die Zustellung dennoch zu erreichen. Somit hat der Sender zwar nicht Gewissheit, dass seine Nachrichten tatsächlich empfangen werden, das System garantiert aber, dass die Nachrichten empfangen werden können. [ANGE03] (S. 126-127) fasst dies unter dem Begriff Guaranteed Delivery zusammen.

Abbildung 1: Direkte und Indirekte Kommunikation

BILD HIER

An diesem Punkt setzt die Ereignisbehandlung von SAP an, welche einen systeminternen Nachrichtendienst nachbildet und auch verwendet wird, um Workflows auf Basis von Ereignissen anzustoßen. Sie stellt einen anwendungsübergreifenden Ereignismanager bereit, der es Anwendungen ermöglicht, Ereignisse zu triggern, ohne dass diese von derselben Anwendung bearbeitet werden. Die Behandlung der Ereignisse erfolgt immer in einem eigenen Programmkontext durch so genannte Ereignisverbraucher, wobei es sich konkret um Funktionsbausteine, Methoden von Business Objekten und Methoden von ABAP-Objekten handeln kann.

Nach der Beschreibung von [MEND00] (S. 225) handelt der Ereignismanager nach einer strikten Event-Condition-Action-Taktik. Das heißt, für jedes auftretende Ereignis werden zunächst alle in Frage kommenden Verbraucher ermittelt. Anschließend wird für jeden Verbraucher durch spezielle Funktionsbausteine geprüft, ob die Verarbeitung tatsächlich angestoßen werden soll und im letzten Schritt werden alle Verbraucher aktiviert, deren Prüfung positiv ausfiel. Wenn kein Verbraucher gefunden wird, der bereit ist, das Ereignis zu behandeln, wird es verworfen.

Anwendungsbeispiel zur Ereigniserzeugung

Das folgende Beispiel zeigt, wie ein anwendungsübergreifendes Ereignis ausgelöst werden kann. Hierfür wird ein zu if_swf_evt_event typkompatibles Objekt verwendet, das von der statischen Methode get_instance der Klasse cl_swf_evt_event generiert wird, wobei die Methode in Form dreier Parameter wissen muss, um welches Ereignis es sich handelt. Hierfür müssen der Ereignistyp1, die definierende Klasse² und der Ereignisname benannt werden. Daraufhin können Informationen über das Ereignis und seine Behandler erfragt, Parameter an das Ereignis übergeben und das Ereignis mit der Methode raise ausgelöst werden. Nennenswert dabei ist, dass die Erzeugung des Objekts in jedem Fall funktioniert, selbst wenn die definierende Klasse des Ereignisses nicht existiert oder kein Ereignisverbraucher mit dem Ereignis registriert ist. In diesem Fall wirft die Methode raise eine Ausnahme, welche vom aufrufenden Programm abgefangen und behandelt werden kann.

Abbildung 2: Auslösen eines Ereignisses

* Referenz auf das Event-Objekt
DATA: event TYPE REF TO if_swf_evt_event.

* Ereignisobjekt erzeugen
CALL METHOD cl_swf_evt_event=>get_instance
  EXPORTING
    im_objcateg        = 'CL'
    im_objtype         = 'ZDES_CL_KAKTE?'
    im_event           = 'NEW_MESSAGE'
    im_objkey          = 'J6M'
*   IM_EVENT_CONTAINER? =
  RECEIVING
    re_event           = event.

* Ereignis auslösen und Fehler behandeln
TRY.
    event->raise( ).
  CATCH cx_swf_evt_invalid_objtype .
    MESSAGE i000(43) WITH 'Ungültiges Objekt.'.
  CATCH cx_swf_evt_invalid_event .
    MESSAGE i000(43) WITH 'Ungültiges Ereignis.'.
ENDTRY.

* Speicher wieder freigeben
FREE event.

Eine Besonderheit, die aus dem Beispiel nicht hervor geht, ist die Übergabe von Parametern an das aufgerufene Ereignis. In der Tat sind Ereignisse mit regulären Methoden sehr verwand, weshalb sowohl in der ABAP-Notation als auch im Class Builder beide beinahe identisch definiert werden³. Demgemäß können Ereignisse Aufrufparameter besitzen, welche jedem Ereignisverbraucher bei seiner Ausführung mitgegeben werden. Lediglich die Rückgabe von Werten ist aufgrund des asynchronen Aufrufs der Verbraucher nicht möglich.

Wünscht das rufende Programm, ein Ereignis bei seiner Initiierung mit Parametern zu versorgen, muss es sich hierzu eines Parametercontainers bedienen, da die Methode raise keine Möglichkeit der direkten Übergabe vorsieht. Dabei handelt es sich um ein besonderes Objekt, welches von der Methode get_event_container des Eventobjekts erzeugt wird und einfach eine Liste der zu übergebenen Parameter und ihrer Werte darstellt. Als solche stellt es Methoden wie set, get oder clear zur Manipulation seiner Inhalte zur Verfügung. (...)

Quellenangaben

ANGE03: Axel Angeli (2003), Technische Integration von SAP-Systemen, 1. Auflage, SAP PRESS / Galileo Press GmbH, Bonn

GAMM04: Erich Gamma et al. (2004), Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software, 1. Auflage, Addison- Wesley Verlag, München

MEND00: Ulrich Mende et al. (2000), SAP Business Workflow: Konzept, Entwicklung, Anwendung, 2. aktualisierte Auflage, Addison-Wesley Verlag, München

TANE03: Andrew Tanenbaum et al. (2003), Verteilte Systeme: Grundlagen und Paradigmen, 1. Auflage, Pearson Studium / Prentice Hall, München

WOLF07: Frank Wolf (2007), ABAP Objects, 1. Auflage, dpunkt.verlag GmbH, Heidelberg