SAP-LUW 

Mit den Open SQL-Anweisungen INSERT, UPDATE, MODIFY und DELETE können Datenbankänderungen über mehrere Dialogschritte verteilt programmiert werden. Selbst wenn kein expliziter Datenbank-Commit programmiert wird, sorgt der implizite Datenbank-Commit bei jedem Bildwechsel für den Abschluss einer Datenbank-LUW. Das folgende Bild zeigt die einzelnen Datenbank-LUWs einer typischen Bildschirmfolge.

Bei diesem Verfahren ist ein Rollback von Datenbankänderungen vorangegangener Dialogschritte allerdings nicht möglich. Daher eignet es sich nur für Programme bei denen kein logischer Zusammenhang zwischen den einzelnen Dialogschritten besteht.

Datenbankänderungen einzelner Dialogschritte sind normalerweise voneinander abhängig und müssen deshalb zusammen ausgeführt und im Fehlerfall auch zusammen zurückgesetzt werden. Die voneinander abhängigen Datenbankänderungen verschiedener Dialogschritte bilden logische Einheiten und können mit den unten aufgeführten Bündelungstechniken in einer Datenbank-LUW zusammengefasst werden.

Eine logisch zusammenhängende Einheit von Dialogschritten, deren Änderungen innerhalb einer einzigen Datenbank-LUW ausgeführt werden, nennen wir SAP-LUW. Im Unterschied zur Datenbank-LUW kann eine SAP-LUW mehrere Dialogschritte umfassen und mit Hilfe verschiedener Workprozesse ausgeführt werden. Werden im Verlauf einer SAP-LUW Datenbankänderungen vorgenommen, so sollen in der Regel entweder alle Datenbankänderungen vollständig oder überhaupt nicht durchgeführt werden. Um dies zu gewährleisten, muss bei erfolgreichem Ende einer Transaktion ein Datenbank-Commit und beim Erkennen eines Fehlers ein Datenbank-Rollback ausgelöst werden. Da aber Datenbankänderungen, die in einer Datenbank-LUW gemacht worden sind, nicht mehr durch einen Datenbank-Rollback in einer der folgenden Datenbank-LUWs rückgängig gemacht werden können, müssen alle Datenbankänderungen einer SAP-LUW in einer Datenbank-LUW durchgeführt werden. Zur Erhaltung der Datenintegrität ist es notwendig, alle Datenbankänderungen in der letzten Datenbank-LUW einer SAP-LUW zu bündeln. Die folgende Abbildung verdeutlicht diese Bündelung von Datenbankänderungen in der letzten SAP-LUW.

 

Durch die Technik der Bündelung von Datenbankänderungen im Rahmen einer SAP-LUW wird die Rücksetzbarkeit von Daten gewährleistet. Die Ausführung einer Transaktion kann dadurch auf mehrere Workprozesse und sogar auf verschiedene SAP-Systeme verteilt werden. Im folgenden sind die Möglichkeiten der Bündelung von Datenbankänderungen im Rahmen einer SAP-LUW dargestellt.

Die einfachste Form der Bündelung wäre die Abarbeitung eines Anwendungsprogramms innerhalb eines einzigen Dialogschritts, in dem alle Benutzereingaben geprüft und in der Datenbank verbucht werden, ohne dass ein Datenbank-Commit während des Dialogschritts erzeugt wird. Dies reicht für komplexe betriebswirtschaftliche Abläufe natürlich nicht aus und deshalb stellt ABAP die im Folgenden beschriebenen Bündelungstechniken zur Verfügung.

Bündeln über Funktionsbausteine (Verbuchung)

Die Anweisung CALL FUNCTION ... IN UPDATE TASK bewirkt, dass der aufgerufene Funktionsbaustein zur Ausführung über einen speziellen Verbuchungs-Workprozess vorgemerkt wird. Die Open SQL-Anweisungen für Datenbankänderungen können also statt direkt ins Programm in Funktionsbausteine geschrieben werden und der Aufruf der Funktionsbausteine an die Stelle der Anweisungen gesetzt werden. Beim Aufruf der Funktionsbausteine mit dem Zusatz IN UPDATE TASK werden diese inklusive der übergebenen Schnittstellenparameter als Protokollsatz in einer speziellen Datenbanktabelle namens VBLOG zwischengespeichert.

Die Ausführung des Funktionsbausteins im Verbuchungs-Workprozess wird über die ABAP-Anweisung COMMIT WORK ausgelöst. Der Dialog-Workprozess ist nach der Ausführung der Anweisung COMMIT WORKfrei für weitere Benutzereingaben. Der Verbuchungs-Workprozess übernimmt somit die Ausführung des Verbuchungsteils der SAP-LUW. Für den Dialogteil des Programms schließt die Anweisung COMMIT WORKdie SAP-LUW ab und leitet die Verbuchung ein. Vollständig beendet ist die SAP-LUW nachdem der Verbuchungs-Workprozess alle Datenbankänderungen durchgeführt oder im Fehlerfall zurückgenommen hat. Die Bündelung über Funktionsbausteine nennen wir Verbuchung.

Näheres zum Anlegen von Verbuchungsfunktionsbausteinen erfahren Sie im Abschnitt Verbuchungsfunktionsbausteine anlegen.

Fehlersituationen treten während der Verbuchung nur in Ausnahmefällen auf, da alle erforderlichen Prüfungen auf logische Fehler wie unverträgliche Eingaben schon in der Dialogphase vorgenommen und bearbeitet werden. Bei logischen Fehlern kann das Programm die Verbuchung über die ABAP-Anweisung ROLLBACK WORK abbrechen. Dann werden die gespeicherten Funktionsbausteine nicht ausgeführt, sondern der Protokollsatz aus der Tabelle VBLOG gelöscht. Fehler während der Verbuchung sind meist technischer Natur, wie z.B: Speicherplatzprobleme. Bei solchen Fehlern führt der Verbucher einen Datenbank-Rollback aus, und stellt den Protokollsatz mit einem Vermerk in die VBLOG zurück. Der Benutzer, dessen Dialog den Protokollsatz erzeugt hat, wird per SAPMail automatisch vom Abbruch der Verbuchung unterrichtet. Solche Fehler müssen vom Systemadministrator behoben werden. Die zurückgestellten Protokollsätze können nach Beseitigung der Fehlerursache, erneut bearbeitet werden.  

Nähere Informationen zur Verwaltung von Verbuchungen finden Sie in Die Verbuchungsverwaltung.

Durch diese Technik der Bündelung von Datenbankänderungen in der letzten Datenbank-LUW der SAP-LUW können Datenbankaktualisierungen asynchron durchgeführt werden. Damit werden die Antwortzeiten im Dialogprozess verkürzt. Die Verbuchung kann vollständig vom Dialog-Workprozess entkoppelt und z.B. über einen zentralen Verbuchungs-Workprozess auf einem entfernten Datenbank-Server abgewickelt werden.

Bündeln über Unterprogramme

Die Anweisung PERFORM ON COMMIT ruft ein Unterprogramm im Dialog-Workprozess auf. Die Ausführung des Unterprogramms wird zurückgehalten, bis das System auf die nächste COMMIT WORK-Anweisung trifft. Die Open SQL-Anweisungen für Datenbankänderungen können also statt in Funktionsbausteine auch in Unterprogramme geschrieben werden. Die ABAP-Anweisung COMMIT WORK definiert auch hier das Ende der SAP-LUW, da alle Änderungsanweisungen, die in einem Unterprogramm mit PERFORM ON COMMIT aufgerufen werden, in der Datenbank-LUW des betreffenden Dialogschritts ablaufen.

Der Vorteil dieser Bündelungstechnik besteht darin, dass zum Beispiel im Vergleich zu der oben beschriebenen Verbuchung mit CALL FUNCTION ... IN UPDATE TASK eine bessere Performance erzielt werden kann, da die zu verbuchenden Daten nicht in eine zusätzliche Tabelle geschrieben werden müssen und somit die Anzahl der Datenbank-Zugriffe reduziert wird. Der Nachteil dieser Bündelungstechnik ist darin zu sehen, dass bei PERFORM ON COMMITkeine Parameter übergeben werden können. Die Datenübergabe findet über globale Variablen bzw. über das ABAP-Memory statt. Die Gefahr der Inkonsistenz von Daten ist bei dieser Art der Datenübergabe recht hoch.

Bündeln über Funktionsbausteine in anderen SAP-Systemen

Die Funktionsbausteine, die mit CALL FUNCTION ... IN BACKGROUND TASK DESTINATION aufgerufen werden, werden registriert, um bei Erreichen des nächsten ABAP-Befehls COMMIT WORK im Hintergrund in einem anderen SAP-System ausgeführt zu werden (Remote Function Call). Der Dialogprozess wartet nach einem COMMIT WORK nicht auf das Ende der Ausführung dieser Funktionsbausteine (asynchrone Verarbeitung). Alle so registrierten Funktionsbausteine einer Destination werden gemeinsam in einer Datenbank-LUW ausgeführt. Solche Aktualisierungen sind u.a. dann nützlich, wenn identische Daten auf verschiedenen Datenbanken gepflegt werden sollen.

Beachten Sie hierzu bitte auch die Ausführungen in der Schlüsselwortdokumentation.

Nähere Informationen zur RFC-Verarbeitung finden Sie in der Dokumentation BC - Basis-Services → Remote Communication.