Sie müssen sicherstellen, dass 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.
Beachten Sie, dass die Ereignisse etwas über tatsächlich erfolgte Zustandsänderungen an Objekten aussagen. Stellen Sie deshalb sicher, dass 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.
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:
SWE_EVENT_CREATE_IN_UPD_TASK
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.
SWE_EVENT_CREATE_FOR_UPD_TASK
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:
Auslöser ( Requester ) finden
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.
Bestimmung aller Supertypen des auslösenden Objekttyps
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 .
Achten Sie darauf, dass 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, dass 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 muss 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. Hinweis
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:
den Ereigniscontainer deklarieren
den Ereigniscontainer initialisieren
den Ereigniscontainer mit Werten füllen
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.