ABAP-Applikationsserver 

ABAP-Applikationsserver stellen wichtige Software-Komponenten des NetWeaver AS ABAP dar, da alle ABAP-Programme auf ihnen ablaufen. In den folgenden Abschnitten werden der Aufbau und die Funktionsweise dieser Applikationsserver genauer beschrieben.

Aufbau eines ABAP-Applikationsservers

Alle ABAP-Applikationsserver unter Einbeziehung des Message Servers bilden die Applikationsschicht der mehrstufigen Architektur eines ABAP-basierten SAP-Systems. Diese Applikationsserver führen ABAP-Anwendungen aus und kommunizieren dabei mit den Präsentationskomponenten, mit der Datenbank und über den Message Server auch untereinander.

Das folgende Bild zeigt den Aufbau eines ABAP-Applikationsservers:

 

Jeder ABAP-Applikationsserver enthält mehrere Workprozesse, deren Anzahl und Typ beim Start des NetWeaver AS ABAP festgelegt werden, einen Dispatcher, einen Gateway sowie das Shared Memory. Die Aufgaben dieser Komponenten werden im Folgenden kurz zusammnegefasst:

Workprozesse

Workprozesse sind Komponenten, die in der Lage sind, eine Anwendung (bzw. jeweils einen Dialogschritt) auszuführen. Jeder Workprozess hat Verbindung zu einem Speicherbereich, in dem sich der Kontext der gerade ausgeführten Anwendung befindet. Der Kontext beinhaltet die aktuellen Daten des laufenden Programms und muss für jeden Dialogschritt dieses Programms verfügbar sein.

Dispatcher

Der Dispatcher ist das Bindeglied zwischen den Workprozessen und den an dem ABAP-Applikationsserver angemeldeten Benutzern (bzw. deren SAP GUIs). Seine Aufgabe besteht darin, jedes Mal, wenn eine Benutzerinteraktion dazu führt, dass ein Dialogschritt ausgeführt werden soll, diesen Auftrag vom SAP GUI entgegenzunehmen und ihn an einen freien Workprozess weiterzuleiten. Auf gleichem Wege gelangen die Bildschirmausgaben, die aus der Ausführung des Dialogschritts resultieren, wieder zum Benutzer zurück.

Gateway

Das Gateway ist die Vermittlungsinstanz für die Kommunikationsprotokolle des NetWeaver AS ABAP (RFC, CPI/C) und kann mit anderen ABAP-Applikationsservern des gleichen NW AS, mit anderen SAP-Systemen oder mit externen (nicht-SAP) Anwendungen kommunizieren.

Shared Memory

Alle Workprozesse eines ABAP-Applikationsservers verwenden einen gemeinsamen Hauptspeicher, das Shared Memory, um Kontexte zu speichern oder um selten geänderte Daten lokal zu puffern.

Im Shared Memory stehen die von allen Workprozessen genutzten Ressourcen (wie Programme oder Tabelleninhalte) zur Verfügung. Die Speicherverwaltung des NetWeaver AS ABAP sorgt dafür, dass die Workprozesse immer den aktuellen Kontext, d.h. die Datenmengen, die den aktuellen Bearbeitungszustand eines laufenden Programms enthalten, adressieren. Über ein Mapping-Verfahren wird zu diesem Zweck der für die Ausführung eines Dialogschritts erforderliche Kontext aus dem gemeinsamen Hauptspeicher in den Adressraum des bearbeitenden Workprozesses projiziert. Dadurch sind die tatsächlichen Kopiervorgänge auf ein Minimum reduziert.

Vorteile einer solchen Architektur

Der hier beschriebene Aufbau der ABAP-Applikationsserver unterstützt die Performance und Skalierbarkeit des NetWeaver AS ABAP. Die feste Anzahl von Workprozessen und das Dispatching von Dialogschritten auf die Workprozesse sorgen für eine gute Ausnutzung des Hauptspeichers im verwendeten Rechner, da manche Komponenten und Speicherbereiche eines Workprozesses unabhängig von den Anwendungen sind und wieder verwendet werden. Da die einzelnen Workprozesse unabhängig voneinander arbeiten, bieten sie eine optimale Vorraussetzung für Mehrprozessor-Architekturen.

Die lokale Pufferung von Daten im Shared Memory des ABAP-Applikationsservers entlastet die Datenbank, da mehrfaches Lesen vermieden wird. Dadurch verkürzen sich die Zugriffszeiten für die ABAP-Anwendungsprogramme erheblich. Durch die Konzentration einzelner Anwendungen (Finanzwirtschaft, Logistik, Personalwirtschaft) auf getrennte ABAP-Applikationsservergruppen kann eine optimale Ausnutzung der Puffer erreicht werden.

Datenbankanbindung

Während des Starts eines NetWeaver AS ABAP meldet jeder ABAP-Applikationsserver seine Workprozesse an die Datenbankschicht an und erhält dadurch für jeden Workprozess genau einen fest definierten Kanal. Jeder Workprozess ist für die gesamte Laufzeit des NW AS ein Benutzer (Client) des Datenbanksystems (Server). Während der Laufzeit des Systems erfolgen keine Ummeldungen und ein Datenbank-Kanal kann nicht von einem Workprozess zum anderen weitergereicht werden. Aus diesem Grund kann ein Workprozess Datenbankänderungen immer nur im Rahmen genau einer Datenbank-LUW (Logical Unit of Work), d.h. einer nicht teilbaren Folge von Datenbankoperationen, ausführen.