Dialogprogrammierung

Die Anzahl der Benutzer, die sich an einem ABAP-Applikationsserver anmelden, ist häufig um ein Vielfaches größer als die Anzahl der zur Verfügung stehenden Workprozesse und nicht durch die Architektur des SAP NetWeaver Application Server für ABAP begrenzt. Jeder Benutzer kann wiederum mehrere parallele Anwendungen ausführen. Der Dispatcher hat dabei die wichtige Aufgabe alle anfallenden Dialogschritte auf die Workprozesse des ABAP-Applikationsservers zu verteilen.

Das folgende Beispiel demonstriert, wie der zeitliche Ablauf des Dispatching aussehen kann:

1. Der Dispatcher empfängt von Benutzer 1 die Anforderung zur Ausführung eines Dialogsschritts und leitet diese an den gerade freien Workprozess 1 weiter. Der Workprozess adressiert den Kontext des entsprechenden Anwendungsprogramms im Shared Memory und führt den Dialogschritt aus. Danach ist der Workprozess wieder frei.
2. Der Dispatcher empfängt von Benutzer 2 die Anforderung zur Ausführung eines anderen Dialogschritts und leitet diese an den wieder freien Workprozess 1 weiter. Der Workprozess bearbeitet den Dialogschritt analog zu Schritt 1.
3. Während Workprozess 1 noch mit Schritt 2 beschäftigt ist, empfängt der Dispatcher von Benutzer 1 die Anforderung zur Ausführung eines weiteren Dialogschritts und leitet diese an den gerade freien Workprozess 2 weiter.
4. Nachdem Workprozess 1 und 2 ihre Verarbeitung beendet haben, empfängt der Dispatcher wieder von Benutzer 1 eine Anforderung und leitet diese an den wieder freien Workprozess 1 weiter.
5. Während Workprozess 1 noch mit Schritt 4 beschäftigt ist, empfängt der Dispatcher von Benutzer 2 eine Anforderung zur Ausführung und leitet diese an den wieder freien Workprozess 2 weiter.

Dem Beispiel entnehmen wir, dass

• ein Dialogschritt eines Programms während seiner Ausführung genau einem Workprozess zugeordnet ist.
• die einzelnen Dialogschritte eines Programms während dessen Laufzeit auf verschiedenen Workprozessen ausgeführt werden können und der Kontext des Programms für jeden neuen Workprozess neu adressiert werden muss.
• ein Workprozess aufeinander folgend die Dialogschritte verschiedener Programme und verschiedener Benutzer ausführt.

Aus dem Beispiel geht nicht hervor, dass der Dispatcher die Aufträge so auf die Workprozesse zu verteilen versucht, dass möglichst oft der gleiche Workprozess für aufeinander folgende Dialogschritte einer Anwendung verwendet wird. Dadurch kann die Neuadressierung des Programmkontexts im Shared Memory eingespart werden.

Wie bereits erwähnt (siehe Abschnitt Datenbankanbindung), kann ein Workprozess Datenbankänderungen immer nur im Rahmen genau einer Datenbank-LUW (Logical Unit of Work) ausführen, an deren Anfang und Ende ein konsistenter Datenbestand auf der Datenbank stehen muss. Das Ende einer solchen unteilbaren Folge von Datenbankoperationen wird durch einen Commit-Befehl an das Datenbanksystem definiert (Datenbank-Commit). Während einer Datenbank-LUW, also zwischen zwei Datenbank-Commits, sorgt das Datenbanksystem selbst für die Konsistenz (Widerspruchsfreiheit) des Datenbestands. Das heißt, es übernimmt selbständig Aufgaben wie Datenbankeinträge während ihrer Bearbeitung zu sperren oder den alten Zustand nach einem fehlerhaften Abbruch wiederherzustellen (Rollback).

Typische SAP-Anwendungsprogramme erstrecken sich über einige Bildschirmbilder und die zugehörigen Dialogschritte. Der Benutzer fordert auf den einzelnen Bildschirmen Datenbankänderungen an, die nach Ablauf einer Bildschirmfolge zu einem konsistenten Datenbestand auf der Datenbank führen sollen. Die einzelnen Dialogschritte laufen auf unterschiedlichen Workprozessen und ein einzelner Workprozess bearbeitet nacheinander Dialogschritte unabhängiger Anwendungen. Es ist klar, dass voneinander unabhängige Anwendungen, deren Dialogschritte nacheinander auf einem Workprozess ausgeführt werden, nicht mit der gleichen Datenbank-LUW arbeiten dürfen.

Daraus folgt, dass ein Workprozess für jeden Dialogschritt eine eigene Datenbank-LUW öffnen muss. Der Workprozess sendet also am Ende jedes Dialogschritts, bei dem Datenbankänderungen ausgeführt werden, einen Commit-Befehl (Datenbank-Commit) an die Datenbank. Diese Commit-Befehle sind nicht explizit in der Anwendung programmiert und wir nennen sie deshalb implizite Datenbank-Commits.

Durch diesen impliziten Datenbank-Commit wird die Zeit, in der ein Benutzer eine Datenbank-LUW aufrechterhalten kann auf maximal einen Dialogschritt beschränkt. Dies bedeutet eine erhebliche Entlastung der Datenbank, verringert die Häufigkeit von Serialisierungen und Deadlocks und ermöglicht daher eine sehr große Zahl von Benutzern an einem System.

Es stellt sich jetzt die Frage, wie sich die Verknüpfung jedes einzelnen Dialogschritts mit einer Datenbank-LUW mit der Anforderung in Einklang bringen lässt, dass das Festschreiben (Commit) oder Zurücknehmen von Datenbankänderungen (Rollback) vom logischen Ablauf der Anwendungsprogramme abhängen sollte und nicht von der technischen Verteilung auf Dialogschritte. Wenn Aktualisierungsanforderungen voneinander abhängen, bilden sie logische Einheiten im Programmverlauf, die sich über mehrere Dialogschritte erstrecken können. Die Datenbankänderungen solcher logischer Einheiten müssen zusammen ausgeführt und entsprechend auch zusammen zurückgesetzt werden.

Das SAP-Programmiermodell bietet für diese Anforderung eine Reihe von Bündelungstechniken an, die es ermöglichen, dass Datenbankaktualisierungen in solchen logischen Einheiten ablaufen können. Die Teile des ABAP-Anwendungsprogramms, die eine logisch zusammengehörende Menge von Datenbank-Operationen bündeln, bezeichnen wir als SAP-LUW. Im Gegensatz zur Datenbank-LUW umfasst eine SAP-LUW die Gesamtheit der Dialogschritte einer logischen Einheit inklusive der Fortschreibung auf der Datenbank (Verbuchung).