Dialogprogrammierung 

Klassische Programmiertechnik, die auf   Dynpros und Dialogtransaktionen beruht.

Klassische Anwendungsprogrammierung

Die Trennung von Anwendungs- und Präsentationsschicht hat zur Folge, dass bei der Ausführung eines ABAP-Anwendungsprogramms, das mehrere Benutzeraktionen am Bildschirm erfordert, die Kontrolle über das Anwendungsprogramm ständig zwischen diesen Schichten wechselt. Während ein Bildschirm eingabebereit ist, ist der entsprechende SAP GUI der Präsentationsschicht aktiv. Die Applikationsschicht ist in dieser Zeit nicht für das Anwendungsprogramm aktiv. Die ABAP-Applikationsserver sind dadurch für andere Aufgaben frei. Nach einer Benutzereingabe am Bildschirm ist die Applikationsschicht wieder für das Anwendungsprogramm aktiv. In dieser Zeit ist die Präsentationsschicht inaktiv. Der SAP GUI ist zwar für den Benutzer aktiv und zeigt das Bildschirmbild noch an, ist in dieser Zeit aber nicht eingabebereit. Erst wenn das Anwendungsprogramm einen weiteren Bildschirm vorbereitet und an den SAP GUI geschickt hat, wird dieser wieder aktiv, wechselt die Bildschirmanzeige und wartet auf Eingaben.

Als Konsequenz dieser Technik ist es notwendig Dialogprogramme in einzelne Dialogschritte zu unterteilen, die jeweils die Programmlogik zwischen zwei aufeinander folgenden Bildschirmbildern zusammenfassen.

Dispatching von Dialogschritten

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 NW AS 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.

Dispatching und Programmiermodell

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).