Workprozesse 

Workprozesse führen als Komponenten von ABAP-Applikationsservern die einzelnen Dialogschritte der ABAP-Anwendungen aus. In den nächsten beiden Abschnitten zeigen wir zunächst den Aufbau eines Workprozesses und gehen dann auf die verschiedenen Typen von Workprozessen im NetWeaver AS ABAP ein.

Aufbau eines Workprozesses

Das folgende Bild zeigt Ihnen, welche Komponenten jeder Workprozess enthält, damit er ABAP-Anwendungsprogramme ausführen kann:

Dynpro-Prozessor

In ABAP-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 Dynpro-Ablauflogik, die einen Großteil der Benutzerinteraktionen kontrolliert. Das NetWeaver AS ABAP enthält für die Erstellung von Dynpros eine eigene Sprache mit Sprachelementen für die Programmierung der Dynpro-Ablauflogik. Der Dynpro-Prozessor führt die Dynpro-Ablauflogik 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 Dynpro-Ablauflogik abzuarbeiten ist. Das folgende Bild verdeutlicht die Zusammenarbeit zwischen Dynpro- und ABAP-Prozessor bei der Ausführung von Anwendungsprogrammen.

Datenbankschnittstelle

Die Datenbankschnittstelle stellt folgende Dienste zur Verfügung:

·        Verbindungsauf- und -abbau eines Workprozesses zur Datenbank

·        Zugang zu Datenbanktabellen

·        Zugang zu Repository-Objekten (ABAP-Programme, Dynpros etc.)

·        Zugang zu Kataloginformationen (ABAP Dictionary)

·        Transaktionskontrolle (Commit- und Rollback-Behandlung)

·        Verwaltung von Tabellenpuffern auf dem ABAP-Applikationsserver

 

Die folgende Abbildung zeigt die einzelnen Komponenten der Datenbankschnittstelle:

 

Die Abbildung zeigt, dass 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 umfasst 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 NetWeaver AS ABAP 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 ABAP-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 (Shared Memory) aller Workprozesse eines ABAP-Applikationsservers abgelegt. Bei NetWeaver AS ABAP, die auf mehrere ABAP-Applikationsserver verteilt sind, werden die Daten in den verschiedenen Puffern durch das Puffer-Management in festgelegten Zeitabschnitten synchronisiert. Bei der Datenbankpufferung muss man also in Kauf nehmen, dass 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. In Native SQL können im Wesentlichen datenbankspezifische SQL-Anweisungen verwendet werden, die von der Native-SQL-Schnittstelle unverändert an das Datenbanksystem weitergegeben und dort ausgeführt werden. Hierfür kann der volle SQL-Sprachumfang der jeweiligen Datenbank verwendet, wodurch jedes Programm, das Native SQL verwendet, abhängig vom installierten Datenbanksystem ist. Zusätzlich gibt es einen kleinen Satz SAP-spezifischer Native-SQL-Anweisungen, die von der Native-SQL-Schnittstelle besonders behandelt werden. Bei den Entwicklungen der ABAP-Anwendungen wird auf den Einsatz von Native SQL weitestgehend verzichtet. Nur in einigen 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 NetWeaver AS ABAP 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

Für jeden ABAP-Applikationsserver wird vor dem Start des NetWeaver AS ABAP festgelegt, wie viele Workprozesse er enthält und von welchem Typ diese sind. Da alle Workprozesse denselben Aufbau haben (siehe vorhergehender Abschnitt), bestimmt der Workprozesstyp nicht die technischen Eigenschaften, sondern die Art der Aufgaben, die auf dem ABAP-Applikationsserver erledigt werden sollen. 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 ABAP-Applikationsservern.

Das folgende Bild zeigt nochmals den Aufbau eines ABAP-Applikationsservers, wobei jetzt auch die verschiedenen möglichen Workprozesstypen berücksichtigt werden:

 

Dialog-Workprozesse

Dialog-Workprozesse erledigen alle Aufträge zum Ausführen von Dialogschritten (siehe auch Dialogprogrammierung), 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 die logischen Datenbanksperren des NetWeaver AS ABAP enthält und somit eine wichtige Rolle im Zusammenhang mit SAP-LUWs spielt. Für einen NW AS darf es nur eine einzige Sperrtabelle und somit nur einen einzigen ABAP-Applikationsserver mit Enqueue-Workprozessen geben. Im Normalfall reicht sogar nur ein Enqueue-Workprozess aus, um die anstehenden Aufgaben zu bewältigen.

Spool-Workprozess

Der Spool-Workprozess gibt sequentielle Datenströme an einen Drucker oder an die optische Archivierung aus. Jeder ABAP-Applikationsserver kann maximal einen Spool-Workprozess enthalten.

Rolle der Workprozesse

Durch den Typ seiner Workprozesse werden die Dienste bestimmt, die ein ABAP-Applikationsserver zur Verfügung stellen kann. Der 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 Workprozesses zwischen den Typen Dialog und Hintergrund umhängen. Damit kann ein SAP-System beispielsweise von Tag- auf Nachtbetrieb umgestellt werden, wobei es tagsüber mehr Dialog- als Hintergrund-Workprozesse gibt und umgekehrt.