Workprozesse 
Workprozesse führen die einzelnen Dialogschritte der R/3-Anwendungen aus. In den nächsten beiden Abschnitten zeigen wir einerseits den Aufbau eines Workprozesses und gehen andererseits auf die verschiedenen Typen von Workprozessen im R/3-System ein.
Workprozesse führen als Komponenten von Applikationsservern die Dialogschritte von Anwendungsprogrammen aus. Das folgende Bild zeigt Ihnen, welche Komponenten jeder Workprozess enthält, damit er R/3-Anwendungsprogramme ausführen kann:
Ein Workprozess enthält zwei Softwareprozessoren und eine Datenbankschnittstelle:
Dynpro-Prozessor
In R/3-Anwendungsprogrammen unterscheiden wir zwischen Benutzerinteraktionen und Verarbeitungslogik. Programmtechnisch wird die Benutzerinteraktion durch Dynpros (dynamische Programme) realisiert. Ein Dynpro besteht aus einer Bildschirmmaske und der zugehörigen Dynproablauflogik. Die Dynproablauflogik kontrolliert einen Großteil der Benutzerinteraktionen. Das R/3-Basis-System enthält für die Erstellung von Dynpros eine eigene Sprache mit Sprachelementen für die Programmierung der Dynproablauflogik. Der Dynpro-Prozessor führt die Dynproablauflogik des Anwendungsprogramms aus. Er übernimmt dabei die Kommunikation zwischen Workprozess und SAP GUI (über den Dispatcher), ruft Module der Verarbeitungslogik auf und sorgt für die Weitergabe von Feldinhalten an die Verarbeitungslogik.
ABAP-Prozessor
Die eigentliche Verarbeitungslogik von Anwendungsprogrammen ist in der SAP-eigenen Programmiersprache ABAP geschrieben. Der ABAP-Prozessor führt die Verarbeitungslogik des Anwendungsprogramms aus und kommuniziert mit der Datenbankschnittstelle. Der ABAP-Prozessor wird vom Dynpro-Prozessor informiert, welcher Programmteil (Modul) entsprechend des Fortgangs der Dynproablauflogik abzuarbeiten ist. Das folgende Bild verdeutlicht die Zusammenarbeit zwischen Dynpro- und ABAP-Prozessor bei der Ausführung von Anwendungsprogrammen.
Die Datenbankschnittstelle stellt folgende Dienste zur Verfügung:
Die folgende Abbildung zeigt die einzelnen Komponenten der Datenbankschnittstelle:
Die Abbildung zeigt, daß es zwei unterschiedliche Möglichkeiten gibt aus ABAP-Programmen auf Datenbanken zuzugreifen, nämlich Open SQL und Native SQL.
Die Anweisungen von Open SQL sind eine vollständig in ABAP integrierte Untermenge von Standard SQL. Sie erlauben dem ABAP-Programmierer einen einheitlichen Zugriff auf Daten, unabhängig vom installierten Datenbanksystem. Open SQL umfaßt den DML-Anteil (Data Manipulation Language) des Standards, erlaubt es also Daten zu lesen (SELECT) und zu verändern (INSERT, UPDATE, DELETE). Die im Standard definierten bereiche der DDL (Data Definition Language) und DCL (Data Control Language) werden im R/3-System vom ABAP Dictionary bzw. der Berechtigungsverwaltung übernommen, die jeweils die Funktionalität der Datenbanken vereinheitlichen bzw, stark erweitern.
Open SQL geht aber auch über den Standard hinaus, indem es einige Anweisungen anbietet, die im Zusammenhang mit den übrigen ABAP-Konstrukten, bestimmte Zugriffe vereinfachen oder beschleunigen können. Zusätzlich bietet Open SQL die Möglichkeit, bestimmte Tabellen auf dem Applikationsserver zu puffern und dadurch Datenbankzugriffe einzusparen. Dabei übernimmt die Datenbankschnittstelle die Kontrolle über die Abgleichung der Puffer mit der Datenbank. Die Puffer sind teilweise im Arbeitsspeicher des aktuellen Workprozesses und teilweise im gemeinsamen Speicher aller Workprozesse eines Anwendungsservers abgelegt. Bei R/3-Systemen die auf mehrere Anwendungsserver verteilt sind, werden die Daten in den verschiedenen Puffern durch das Puffer-Management in festgelegten Zeitabschnitten synchronisiert. Bei der Datenbankpufferung muß man also in Kauf nehmen, daß die Daten in den Puffern nicht immer aktuell sind. Deshalb wendet man Datenbankpufferung eher bei wenig veränderlichen Daten an.
Native SQL ist nur sehr lose in ABAP eingebunden und erlaubt Zugriff auf den gesamten Umfang der Funktionalität, der von der Programmierschnittstelle des Datenbanksystems zur Verfügung gestellt wird. Native SQL Anweisungen werden im Gegensatz zu Open SQL nicht geprüft und übersetzt, sondern direkt an das Datanbanksystem gereicht. Ein Programm, das Native SQL verwendet, ist abhängig vom installierten Datenbanksystem. Bei der Entwicklungen der R/3-Anwendungen wird auf den Einsatz von Native SQL weitestgehend verzichtet. Nur in einigen Basis-Komponenten wird Native SQL verwendet (z.B.: im ABAP Dictionary zum Anlegen oder Ändern von Tabellen).
Die im Bild gezeigte datenbankabhängige Schicht verbirgt die Unterschiede zwischen den Datenbanksystemen vor dem Rest der Datenbankschnittstelle. Sie wird bei der Installation des Basis-Systems entsprechend der verwendeten Datenbank ausgewählt. Dank der Standardisierung von SQL sind die Unterschiede im Hinblick auf die Syntax der Anweisungen gering, Semantik und Verhalten unterliegen jedoch nicht ganz dem Standard und weisen daher größere Unterschiede auf. Im Falle von Native SQL ist die Funktionalität der datenbankabhängigen Schicht nur minimal.
Mögliche Typen von Workprozessen
Obwohl alle Workprozesse die im vorhergehenden Abschnitt beschriebenen Komponenten enthalten, können wir einzelnen Workprozessen verschiedene Typen zuordnen. Der Typ bestimmt, welche Arten von Aufgaben ein Workprozess im Applikationsserver erledigen soll. Der Typ bestimmt nicht die technischen Eigenschaften eines Workprozesses, sondern dient der Aufgabenverteilung auf dem Applikationsserver. Die Verteilung der Aufgaben auf die verschiedenen Workprozesse nimmt der Dispatcher vor.
Für jeden Applikationsserver wird vor dem Start des R/3-Systems festgelegt, wieviele Workprozesse er enthält und von welchem Typ diese sind. Der Dispatcher startet die Workprozesse und verteilt an jeden Workprozess nur die Aufträge, die mit seinem Typ korrespondieren. Das erlaubt die optimierte Verteilung von Workprozesstypen hinsichtlich der Ressourcenausnutzung von Applikationsservern.
Das folgende Bild zeigt nochmals den Aufbau eines Applikationsservers, wobei jetzt auch die verschiedenen möglichen Workprozesstypen dargestellt werden:
Im folgenden beschreiben wir die einzelnen Workprozesstypen nur kurz, da im weiteren Verlauf dieser Dokumentation näher auf einzelne Komponenten des Applikationsservers bzw. R/3-Systems eingegangen wird.
Dialog-Workprozesse
Dialog-Workprozesse erledigen alle Aufträge zum Ausführen von Dialogschritten, die durch einen aktiven Benutzer ausgelöst werden.
Verbuchungs-Workprozesse
Verbuchungs-Workprozesse führen Verbuchungsaufträge aus. Verbuchungsaufträge sind die Teile einer SAP-LUW, die sämtliche aus dem Dialog resultierenden Datenbankoperationen in einer Datenbank-LUW bündeln und im Hintergrund ausführen.
Hintergrund-Workprozesse
Hintergrund-Workprozesse verarbeiten Programme, die ohne Benutzerinteraktion ausgeführt werden sollen (Hintergrundprogramme).
Enqueue-Workprozess
Der Enqueue-Workprozess verwaltet eine Sperrtabelle im Shared Memory. Die Sperrtabelle enthält die logischen Datenbanksperren des R/3-Systems und spielt eine wichtige Rolle im Zusammenhang mit SAP-LUWs. Es darf für ein R/3-System nur eine einzige Sperrtabelle und somit nur einen einzigen Applikationsserver mit Enqueue-Workprozessen geben.
Spool-Workprozess
Der Spool-Workprozess gibt sequentielle Datenströme an einen Drucker oder an die optische Archivierung aus. Jeder Applikationsserver kann mehrere Spool-Workprozesse enthalten.
Die Dienste, die ein Applikationsserver zur Verfügung stellen kann, werden durch den Typ seiner Workprozesse bestimmt. Ein Applikationsserver kann dann entsprechend mehrere Rollen annehmen, z.B. als Dialog-Server und gleichzeitig als Enqueue-Server, wenn er aus mehreren Dialog-Workprozessen und einem Enqueue-Workprozess besteht.
Die Systemadministration kann während des laufenden Workprozesse zwischen den Typen Dialog und Hintergrund umhängen. Damit kann ein R/3-System beispielsweise von Tag- auf Nachtbetrieb umgestellt werden, wobei es tagsüber mehr Dialog- als Hintergrund-Workprozesse gibt und umgekehrt.