ABAP Tipp - Verarbeitung in neuem Task
In diesem Tipp geht es um die asynchrone Verarbeitung in einem neuen Prozess und auf was du dabei achten solltest.
Inhaltsverzeichnis
In manchen Fällen möchtest du einen rechenlastigen Prozess asynchron ausführen, es soll ein Zusatzprozess gestartet werden und das ganze soll keine Performanceauswirkung auf den aktuellen Prozess haben. Dazu verwendest du einen asynchronen Task der in seiner eigenen LUW läuft und sich im Gegensatz zum Hauptprozess dann auch Zeit lassen kann. In diesem Artikel gehen wir auf die Voraussetzungen ein und zeigen dir, wie man den Prozess startet.
Voraussetzungen
Damit wir einen Prozess asynchron ausführen können, brauchen wir im ersten Schritt einen Funktionsbaustein. Zusätzlich muss dieser auch RFC-fähig sein. Der Funktionsbaustein soll, ähnlich wie ein Verbuchungsbaustein, in einem eigenen Prozess laufen. Folgende weitere Anforderungen gibt es daher an den Funktionsbaustein:
- RFC-fähiger Funktionsbaustein
- Nur Parameter mit VALUE-Datenübergabe
- Keine Parameter mit Exporting oder Changing
Beispiel
So ein Funktionsbaustein könnte nun wie folgt aussehen, dabei verwenden wir drei Importing-Parameter, mit denen wir später arbeiten wollen.
FUNCTION Z_TEST_FOR_BACKGROUND_PROCESS
IMPORTING
VALUE(ID_USER) TYPE SYUNAME
VALUE(ID_NUMBER) TYPE I
VALUE(ID_TEXT) TYPE STRING.
" Implement some code
ENDFUNCTION.
Wenn du über Eclipse arbeitest, solltest du nicht vergessen den Funktionsbaustein als RFC-fähig zu kennzeichnen. Dazu findest du auf dem "Properties" View den Reiter "Specific". Hier kannst du den Processing Type auf RFC einstellen.
Start
Um den Funktionsbaustein in deiner Verarbeitung aufzurufen, reicht ein einfacher CALL FUNCTION, wie du es auch bei normalen Funktionsbausteinen tust. Zusätzlich musst du den den Zusatz IN BACKGROUND TASK angeben, damit der RFC Funktionsbaustein im Hintergrund gestartet wird und mit AS SEPERATE UNIT einer eigenen LUW zugewiesen wird. Die Verwendung des Zusatz DESTINATION ist optional, wird kein Wert angegeben, dann wird die Destination NONE verwendet.
CALL FUNCTION 'Z_TEST_FOR_BACKGROUND_PROCESS'
IN BACKGROUND TASK AS SEPARATE UNIT
EXPORTING
id_user = sy-uname
id_number = 23
id_text = `Some example text`.
Commit
Je nachdem wo du in deinem Prozess bist, kann es nötig sein, dass du einen COMMIT absetzt, um den Prozess zu starten. Wenn du den Funktionsbaustein wie oben aufrufst, wird dieser zunächst für die Verarbeitung registriert, aber es findet noch keine Verarbeitung statt. Mit dem nächsten COMMIT WORK startet dann die Verarbeitung und der Prozess.
Dazu ein paar Beispiele wie man es lösen könnte:
- BADI Implementierung - Hier wird nach der erfolgreicher Verarbeitung ein Commit gesetzt und im Fehlerfall ein Rollback prozessiert. Es muss kein zusätzlicher Commit implementiert werden bzw. kann ein Commit auch zu einem Fehler in der Verarbeitung des Standards führen.
- OData Service - Während der Ausführung einer Funktion soll zusätzlich ein asynchroner Prozess gestartet werden, dazu muss nach dem Aufruf ein Commit gesetzt werden.
Hinweis: Wenn du den OData über den SAP Gateway Client ohne Commit testest, dann wird die Verarbeitung funktionieren, beim Aufruf über eine Fiori Applikation dann nicht mehr. Also hier am besten immer einen COMMIT WORK implementieren.
Regeln
Da der Funktionsbaustein in einer eigenen LUW startet, kannst du nicht mehr auf die Daten der originallen Session zugreifen, du kannst aber alle Importing Parameter nutzen und eigene Daten lesen. Dein Commit oder Rollback hat nur Auswirkungen auf deine Daten, sodass du auch aus Standard Prozessen heraus normal arbeiten kannst. Hierbei solltest du allerdings beachten, wenn der Original-Prozess einen Rollback im Anschluss machen sollte, dann bekommt es dein Prozess nicht mit.
Fazit
Mit unserem kleinen Tipp solltest du nun auch eine asynchrone Verarbeitung aus deinen eigenen Programmen und aus dem Standard implementieren können. Damit die Verarbeitung sauber startet, denke immer an einen Commit Work und ob dieser an dieser Stelle Sinn macht.
