Erzeugung von Ereignissen über Funktionsbausteinaufruf
Erzeugung von Ereignissen über Funktionsbausteinaufruf
Verwendung
Sie müssen sicherstellen, daß das Ereignis beim Eintreten der Zustandsänderung ausgelöst wird. Dafür kann es notwendig sein, das Ereignis mit Hilfe eines Funktionsbausteins in Ihrem Programm auszulösen.
Voraussetzungen
Beachten Sie, daß die Ereignisse etwas über tatsächlich erfolgte Zustandsänderungen an Objekten aussagen. Stellen Sie deshalb sicher, daß das Ereignis erst erzeugt wird, wenn auch die entsprechende Zustandsänderung eingetreten ist. Dazu soll der Aufruf des Funktionsbausteins zum Erzeugen eines Ereignisses in derselben logical unit of work (LUW) erfolgen, in der auch die Zustandsänderung vorgenommen wird.
Funktionsumfang
Sie können jedes Ereignis aus einem beliebigen Anwendungs- oder Systemprogramm heraus durch den Aufruf von einem der Funktionsbausteine
SWE_EVENT_CREATE oder SAP_WAPI_CREATE_EVENT erzeugen.Für folgende Spezialfälle gibt weitere Funktionsbausteine, die sich intern allerdings wieder der Funktionalität des oben genannten Funktionsbausteins bedienen:
Dieser Funktionsbaustein ermöglicht die Ereigniserzeugung in der Verbuchung. Er kann, im Gegensatz zum Funktionsbaustein
SWE_EVENT_CREATE , mit dem Zusatz IN UPDATE TASK aufgerufen werden.Das Ereignis wird in der Verbuchung erzeugt. (Der Funktionsbaustein wird dazu nicht mit dem Zusatz
IN UPDATE TASK aufgerufen.)Wenn eine Aufgabe, in der ein Objekt angelegt wird, das Anlegen dieses Objektes als beendendes Ereignis verwenden soll, verwendet das Workflow-System den Workflow-Requester. Dadurch kann das Ereignis Objekt angelegt als beendendes Ereignis verwendet werden, obwohl beim Start der Aufgabe das Objekt noch nicht existiert. Damit der Workflow-Requester vom Workflow-System fehlerfrei genutzt werden kann, sollte der Funktionsbaustein als letzter Funktionsbaustein vor COMMIT WORK aufgerufen werden.
Beim Aufruf des Funktionsbausteins SWE_EVENT_CREATE laufen zunächst synchron die folgenden Abfragen ab:
Wenn das Ereignis von einer Anwendung erzeugt wird, die als asynchrone Objektmethode innerhalb eines Workflows ausgeführt wird, so kann über interne Abfragen das Workitem ermittelt werden, von dem diese Methode aufgerufen wurde.
Die Typkopplung wird nicht nur für den auslösenden Objekttyp selbst berücksichtigt, sondern auch für alle Supertypen dieses Objekttyps.
Eine Typkopplung ist für ein Ereignis des Objekttyps Person eingetragen.
Wenn dieses Ereignis von dem Subtyp Bewerber erzeugt wird, soll die Typkopplung der Person ebenfalls ausgewertet werden.
Daran schließt sich die Auswertung der Kopplungstabellen unter Berücksichtigung der Importparameter des Funktionsbausteins zur Bestimmung eines möglichen Verbrauchers an.
Es ist keine Aussage darüber möglich, ob der Aufruf des oder der Verbraucher erfolgreich war.
Weitere Informationen finden Sie unter Auswertung und Pflege der Typkopplungen.
Aktivitäten
Achten Sie darauf, daß Sie erst die Datenbankänderungen schreiben, dann den Funktionsbaustein aufrufen und anschließend ein
COMMIT WORK durchführen. Eine andere Reihenfolge kann dazu führen, daß Objektdaten im Container nicht vorhanden sind oder einen falschen Inhalt besitzen.Rufen Sie den Funktionsbaustein
SWE_EVENT_CREATE bzw. eine seiner oben genannten Modifikationsformen in einem Programm Ihrer Anwendung auf. Der Funktionsbaustein hat folgende Schnittstelle (Auswahl):Importparameter | ||
OBJTYPE |
SWETYPECOU-OBJTYPE |
Typ des auslösenden Objektes |
OBJKEY |
SWEINSTCOU-OBJKEY |
Zusammengesetzter, objekttypspezifischer Schlüssel des auslösenden Objektes Aus diesen Angaben wird intern die Referenz auf das auslösende Objekt erzeugt und unter dem Elementnamen _Evt_Object in den Ereigniscontainer geschrieben. |
EVENT |
SWETYPECOU-EVENT |
Name des Ereignisses Das Ereignis muß beim auslösenden Objekttyp definiert sein. |
Exportparameter | ||
EVENT_ID |
SWEDUMEVID-EVTID |
Die Ereignisnummer hat einen Wert ungleich Null, wenn der Ereignismanager einen oder mehrere Verbraucherfunktionsbausteine ermitteln konnte.
Es ist keine Aussage darüber möglich, ob der Aufruf des oder der Verbraucher erfolgreich war. Falls kein Verbraucher ermittelt werden konnte, wird als Ereignisnummer Null zurückgegeben. |
Tabellenparameter | ||
EVENT_CONTAINER |
SWCONT |
Persistenter Ereigniscontainer des Ereignisses. Den Ereigniscontainer übergeben Sie nur dann, wenn Sie zusätzlich zu den vorbelegten Elementen eigene Ereignisparameter definiert haben. Der Container, den Sie an den Funktionsbaustein übergeben, wird in der ereigniserzeugenden Anwendung mit den entsprechenden Daten gefüllt und enthält dann auch nur die von Ihnen definierten Ereignisparameter. Bei der Ausführung des Funktionsbausteins werden dem Ereigniscontainer zusätzlich die vorbelegten Elemente (Objektreferenz, Erzeugungszeit, Erzeuger, …) hinzugefügt. |
Da der asynchrone RFC für den Aufruf des Verbraucherfunktionsbausteins erst nach dem nächsten
COMMIT WORK ausgelöst wird, müssen Sie, damit die Ereignisse auch tatsächlich erzeugt werden, in Ihrer Anwendung nach dem Aufruf des Funktionsbausteins zum Erzeugen eines Ereignisses den Befehl COMMIT WORK absetzen.Der Datenbank-Commit, der beim Bildwechsel automatisch durchgeführt wird, führt nicht zum Auslösen des asynchronen RFCs.
Ereignisparameter
Wenn zu dem Ereignis, das Sie erzeugen wollen, zusätzlich zu den systemseitig vorbelegten Ereignisparametern weitere Ereignisparameter definiert sind, müssen Sie vor dem Aufruf des Funktionsbausteins:
Zur Durchführung dieser Schritte stehen Makrobefehle zur Verfügung. Weitere Informationen finden Sie unter
Makrobefehle zum Bearbeiten eines Containers.Der Container wird dann als Tabellenparameter an den Funktionsbaustein
SWE_EVENT_CREATE übergeben. Der Name, den Sie dem Ereigniscontainer in Ihrer Anwendung geben, kann völlig frei gewählt werden.