(Last Updated On: 23. Juni 2015)

SAP Basis war oder ist ein Begriff der die allgemeinen Administrationstätigkeiten in einer SAP-Produktumgebung beschreibt. BASIS ist eigentlich eine softwarekomponente, auf der andere Technologien von SAP aufsetzen, um letztendlich die SAP-produkte, die in der Wirtschaft so heiß begehrt sind, darauf zu betreiben. Basis war lange Zeit das Synonym für diejenigen Tätigkeiten, die sich nicht nur um die softwarekomponente BASIS, sondern um das umfassende Fundament von SAP-Software kümmern.

SAP hat den Begriff BASIS für die Disziplin der SAP-Systemadministration abgelöst und nennt es heutzutage SAP NetWeaver Sytsem ADministration.

Was ist SAP NetWeaver?

SAP NetWeaver ist sozusagen die Plattform, welche alle Komponenten mit sich bringt, die notwendig sind, um SAP-Produkte zu betreiben. Dazu gehören beispielsweise der SAP Kernel, die SAP Basis-Softwarekomponenten, die grafische Benutzeroberfläche SAPGui usw.

Die Idee hinter SAP NetWeaver ist, dass die SAP-Produkte, also beispielsweise SAP SRM, CRM, SCM, PLM, oder SAP ERP, die wir allesamt in meinem post SAP – Geschichte und einführung kennengelernt haben, auf Basis von einem Web Application Server laufen und dabei plattformunabhängige Programmiersprachen wie ABAP oder JAVA nutzen. Der Vorteil bei diesen beiden Technologien ist, dass  sie auf allen Betriebssystemen laufen – da der Code von einem Interpreter erst während der Laufzeit des Programms in Maschinencode übersetzt wird – das bedeutet: dem ABAP- oder Java-Code ist es grundsätzlich egal, ob er gerade auf einem Windows-, Linux- oder Unix-System ausgeführt wird. Der interpreter weiß, wie er für die jeweilige Plattform den Code interpretieren muss, damit die Befehle ausgeführt werden. Das einzige Plattform, welches betriebssystemabhängig kompiliert, heruntergfeladen und installiert werden muss, ist also der SAP NetWeaver selbst, aber nicht mehr die wirklichen SAP Produkte. Das verringert den administrativen Aufwand sowie Hürden bei der Umsetzung.

Das ist aber noch nicht alles, was hinter SAP NetWeaver steckt.Der NetWeaver versteht sich als serviceorientierte Integrationsplattform für alle SAP applikationen und für Drittanbieteranwenudngen, die mit den SAP Produkten in SYmbiose eingesetzt werden sollen. Deswegen hat der NetWeaver beispielsweise sogenannte N etWeaver Applikationen im Gepäck, die bestimmte Dienste bereitstellen, um innerhalb der SAP-produktlandscahft gewisse Aufgaben zu erfüllen (die wir weiter unten noch kennenlernen werden).

Desweiteren kann der SAP NetWeaver auch mit anderen Sprachen erweitert werden, beispielswiese microsoft .NET oder IBM Websphere. Das bedeutet: der pool an Entwicklern, die ein SAP-System von nun an mit ihren PRodukten bereichern können, ist ziemlich groß, da viele technologien unterstützt werden.

die NetWeaver applikationen

Das, was den SAP NetWeaver ausmacht, sind die applikationen, die er mitbringt. Auch diese dienen dazu, um SAP-Produkten die Grundlage bietet, um neue Funktionalitäten anzubieten.

Zu den NetWeaver-applikationen gehören:

• Web Application Server (WAS) / Application Server (NW AS)
• Business intelligence / Business warehouse (BI / BW)
• Process integration (PI), früher Exchange infrastrucutre (XI). Grundlage zur Integration von Drittanbieterlösungen in SAP-Landschaften.
• Enterprise Portal (EP). Der sinn von Enterprise Portal ist, dass User sich über Single Sign On
• NBetWEaver Composition Environemnt (CE)
• NetWeaver identity Management (IdM)
• NetWeaver mobile
• Master Data Manager (MDM). Kümmert sich um die Master Data, die transaktions- und produktübergreifend für die Anwender von SAP-Produkten zur Verfügung steht. Eine genauere erklärung von Master Data habe ich in meinem Blog-Post SAP ERP: Die Anwenderseite erklärt gegeben.
• MII: Manufacturing integration & Intelligence

Alle diese applikationen stellen also einen bestimmten Service zur Verfügung, der eine Aufgabe zu bewältigen hat. Alle Dienste zusammen stellen also die Produktivität einer netWeaver systemlandschaft dar.

Der NetWeaver Application Server

Der NetWeaver Application Server ist die Hauptapplikation des SAP NetWeaver. Denn: der Application Server ist quasi der Bereitsteller der SAP-Produkte an seine Anwender.Auf Basis des Application server wird die anwendungsschicht sämtlicher SAP-Produkte, also beispielsweise SAP ERP, SAP BI, SAP CRM, PLM, SLR usw. bereitgestellt. Nur mit einem Application Server im Hintergrund können Anwender eine Adresse des Application Servers eingeben und sich dann mit SAP Logon auf den Server connecten, wie in meinem Post SAP ERP: Die Anwenderseite erklärt. Auch andere Applikationen des SAP NetWeaver basieren auf dem NetWeaver Application Server, beispielsweise SAP BI, SAP PI, Enterprise portal usw. Alles basiert auf Basis eines Application Servers.

die Bezeichnung Netweaver Application Server bezeichnet die Weiterentwicklung des SAP Web Application Server. Der NetWeaver Application Server ist immer noch ein auf webtechnologien basierender Anwendungsserver mit neuem Namen.

ein SAP Application Server kann in drei Grundkonfigurationen installiert werden: mit einem ABAP Stack, Java Stack oder einem sogeannnten Dual Stack. Wie wir oben bereits gelernt haben, unterstützt SAP NetWeaver Applikationen, die auf Basis der Programmiersprachen aBAP oder Java entwickelt wurden. Diese applikationen liefert der application Server dann betriebssystem- und datenbankunabhängig an seine Anwender aus. Die Applikationen können entweder von SAP entwickelte Applikationen sein oder von Drittanbietern hergestellte applikationen, die dann von den Anwendern als Dienst in Anspruch genommen werden können. Die meisten SAP-Produkte sind auf ABAP-Basis geschaffen worden, das ABAP die SAP-eigene Technologie zum Entwickeln von Anwendungen ist. Deswegen braucht man beispielsweise für SAP ERP einen ABAP-Stack. Einige SAP-Technologien, die darauf ausgelegt wurden, dass Sie auch bei fremden ERP-Systemen der Konkurrenz eingesetzt werden können, sowie einige Anwendungen, die vom Einsatz von Java grundsätzlich profitieren, wurden mit Java realisiert – beispielsweise das SLD, welches ich in meinem Post SAP: Begriffe LMDB und SLD erklärt habe.

Man sieht also: für einige SAP-Produkte braucht man einen aBAP-Stack, für einige einen Java-Stack. Entweder man installiert zwei getrennte SAP NetWeaver-Instanzen mit zwei verschiedenen Stack-Konfigurationen und liefert auf diesen beiden instanzen die jeweiligen kompatiblen Produkte aus, oder man installiert einen sogeannnten Dual Stack: das ist ein NetWeaver Application Server ABAP Stack mit einer Java-Umgebung als Add-In, sodass auf diesem Application server auch java-Applikationen angeboten werden können. Der Umfang und die Performance eines Dual-Stacks ist allerdings nicht vergleichbar mit einem Standalone NW AS Java stack, weshalb in einigen Szenarien die Installation eines Dual Stacks nicht in Frage kommt oder mit einigen Nachteilen verbunden ist.

Der netWeaver Application Server wird auch Web Application Server genannt. Die beiden Programmiersprachen ABAP und Java sind dazu in der Lage, HTTP-Anfragen aus dem Intranet oder Internet zu bearbeiten und HTTP-Antworten zu liefern, die beispielsweise im HTML-format ausgegeben werden, sprich als normale Webpage, die man mit einem Webbrowser betrachten kann.

ABAP-Programme, die durch den netweaver Application Server ausgeführt werden, liegen mesitesn nicht als Binärdatei vor, sondern sie liegen als Quellcode in der datenbank. Wenn der Benutzer eine Transaktion aufruft, die ein bestimmtes ABAP-programm ausführen will, dann wird aus der Datenbank der Quellcode des ABAP-programms gehol tund im Anschluss live kompiliert und interpretiert. Bereits übersetzte ABAP-programme werden im ABAP-puffer gecached.

Dabei kann der Application Server sowohl als Webserver, als auch als Webcleinta uftreten. in seiner serverrolle akzeptiert er HTTP-Anfragen von anderen Webclients, etwa einem Browser oder von einem fremden NetWeaver Application Server, verarbeitet diese und liefert eine Rückantwort. In seiner Clientrolle schickt der Application Server Anfragen an fremde Webserver. Das kann beispielsweise ein fremder NetWeaver Application Server sein, mit dem man kommunizieren möchte – oder ein Drittanbieterprodukt, von welchem man bestimmte Daten abfragen möchte.

Instanzen und die Technischen Komponenten des Application Servers

Je nachdem, ob man einen Application Server mit ABAP, Java oder dual Stack-Konfiguration installiert hat, besteht der Application Server aus verschiedenen Komponenten.

Die meisten dieser Komponenten werden jeweils einmal in jeder SAP-Dialoginstanz bereitgestellt. Installiert man einen NetWeaver Application Serverauf einem System, kann man damit mehrere Dialoginstanzen des Application servers auf einem einzigen physikalischen Host anbieten. Das wäre etwa so, als würde man einen Gameserver auf einem computer anbieten und diesen in zwei instanzen starten – auf einer Instanz mit dem Port 27019 kann man Capture the Flag spielen, auf einer anderen instanz mit dem Port 27020 kann man Deathmatch spielen. So in etwa kann man sich die Idee der Instanzen vorstellen. Jede Instanz hat dabei ihre eigenen technischen Komponenten.

Andere komponenten wiederum werden in einer sogenannten Zentralinstanz vorgehalten. Eine Zentralinstanz ist eine Instanz, welche die technischen Komponenten Message Server und Enqueue Server bereitstellt, die wir weiter unten noch vorstellen werden. Diese Komponenten werden instanzübergreifend bereitgestellt.

Jetzt kommt der Clou: Dialoginstanzen können über mehrere physikalische Rechner verteilt werden, es kann aber auf Wunsch nur auf einem dieser physikalischen Hosts eine Zentralinstanz geben. Der sinn davon ist, dass beispielsweise Dialoginstnazen auf mehreren Hosts im Clusterverbund zusammenarbeiten, damit sie die Last auf mehrere Server verteilen. Wie wir später noch lernen werden, kümmert sich dann auf einem dieser Hosts eine Zentralinstanz um die Verteilung der Serverlast auf die Dialoginstanzen auf den verschiedenen Hosts. Die Dialoginstanz ist dann nicht nur für die Dialoginstanzen auf dem eigenen, sondern auch für die Dialoginstanzen auf den anderen Hosts zuständig und verwaltet diese.

die Zentralinstanz bei einem ABAP stack ist die Instanz ASCS (ABAP System Central Services), die Zentralinstanz bei einbem Java Stack ist die SCS (System Central Services). Auf eine Zentralinstanz kann man als Anwender nicht die selben Anfragen stellen wie bei einer sogenannten Dialoginstanz. Eine Dialoginstanz ist dafür zuständig, mit dem anwender eines SAP-Systems zu interagieren, ihma lso beispielsweise Bildschirmausgaben als Antwort auf seine Anfragen, die er über SAP Logon stellt, zu liefern. Ein Anwender kann per se mit einer Zentralinstanz alleine also noch nichts anfangen.

Der (Web) Dispatcher

Eine wichtige Komponente ist der web Dispatcher. Der Web Dispatcher ist dafür zuständig, dass der NetWeaver Application Server HTTP-Anfragen aus dem Intranet oder Internet bearebeiten und beantworten kann. Somit ist es beispielsweise möglich, einen NetWeaver Application Server mit einem Webbrowser mittels Web-Administrationspanel zu administrieren oder zu überwachen, oder beispielsweise kann man bestimmte SAP-dienste als Anwender mit dem Webbrowser in Anspruch nehmen. Der Web Dispatcher öffnet für jede Anfrage eines Clients einen sogeannnten Workprozess (WP) für ABAP oder einen Server Prozess (SP) üfr Java. Ein Workprozess / Serverprozess besteht aus einer ABAP oder Java Virtual Machine (ABAPVM / JVM), in welcher dann ABAP- oder Java Code ausgeführt wird, um die Anfrage zu bearbeiten. Die Workprozesse sind voneinander abgeschottet, das heißt jeder Workprozess hat seine eigene kleine VM, in welcher der code ausgeführt wird. So können sich die Workprozesse nicht gegenseitig in die Umgebung pfuschen, indem sie sich beispielsweise ihre Umgebungsvariablen gegenseitig abändern. In idesem Workprozess wird also die Anfrage eines Nutzers letztendlich bearbeitet – als Ergebnis kommt eine Antwort heraus.

Alle Anfragen von Anwendern und Administratoren an das SAP-System gehen an diesen Dispatcher. Der Dispatcher entscheidet dann, an welche Teilkomponente des Application Servers die Anfrage weitergeleitet werden soll.

Anfragen, die von einem Webbrowser aus gestellt werden, gehen zuerst an den sogenanten Internet Communication Manager, den wir weiter unten noch vorstellen, und werden von diesem dann an den Dispatcher weitergeleitet. Anfragen von SAP Logon / SAPGUI gehen direkt an den Dispatcher. Umgekehrt gehen Antworten an SAP Logon Nutzer direkt vom Dispatcher aus, Browser-Antworten werden vorher den den Internet communication Manager weitergeleitet, der die Antwort dann meistens als HTML-Seite an den Browser des Nutzers ausliefert.

Dialoganfragen beispielsweise, die gestellt werden, wenn ein User mit SAP Logon eine Transaktion, eine Ansicht etc. aufruft, werden dann an die Dialogkomponenten weitergeleitet.

Background-Jobs, die meistens von Administratoren angestoßen werden und die im Hintergrund ohne Darstellung eines Dialogs ablaufen, werden an die Background-komponenten weitergelitet.

einen Dispatcher gibt es genau einmal pro Instanz.

Dialogworkprozesse

Dialogworkprozesse führen die zu einer vom User angeforderen Transaktion gehörenden ABAp-programme aus und greift dabei auf das Datenbanksystem zu. Ein Dialogworkprozesss besthaus verschiedenen Teilen.

Der Dynpro prozessor nciht die vom Dispatcher zugeteilten Transaktionsschritte, extrahiert daraus die vom Benutzer eingegebenen Daten., schreibt diese in in Teile des Speichers und leitet sie an den ABAP-prozessor weiter. Vor der Ausgabe bereitet der Dynpro-Prozessor das Ergebnsi der Transaktion vor, um es dann an die GUI zu schicken. Häufig benötigte Daten schreibt oder holt sich der Dynpro-Prozesor aus dem Roll-Puffer.

Der ABAP-Prozessor ruft ABAP-Programme auf, die für den aktuellen Transaktionsschritt nötig sind. Befindet sich das benötigte ABAB-Programm noch nicht im ABAP-puffer, wird es dorthin geladen. ist das programm noch nicht kompiliert worden, wird es erst übersetzt und dann in den Puffer und im kompilierten Zustand neu in die Datenbank geschrieben.

Die Datenbankschnittstelle übernimmt die Datenoperationen, die ihr durch den ABAP-Prozessor zugeteilt werden, etwa das Einfügen in oder das Änder von Datensätzen, oder das Abholen von ABAP-programmen oder das Auslesen von Daten aus der Datenbank. Sie verwaltet außerdem den Tabellenpuffer, der einen schnelleren Zugrif auf Daten ermöglicht. Sie übersetzt außerdem die Anfragen, die der ABAP-Prozessor in Open SQL stellt, in das native SQL des jeweiligen verwendeten Datenbankmanagementsystems.

Der Task Handler kümmert sich um das managemnt der Zusammenarbeit zwischen diesen Bestandteilen.Jedem Dialog-Workprozess wird dazu genau ein Datenbank-Serverprozess zugeordnet. SAP nennt dies einen Schattenprozess.

Batchworkprozesse

Batchworkprozesse sind für länger laufende Transkationen gedacht, die ohne ständige Interaktion mit dem Nutzer in der Stapelverarbeitung abgearbeitet werden können, gedacht.

Spoolprozesse

Sie dienen der Asugabe auf Druckern, PDF-Druckern und ähnlichen Geräten

Verbucherprozess (UPD).

– to be continued –

Der internet Communication Manager (ICM)

Der internet communication Manager ist dafür zustöndig, die Verbindung mit dem Application Server per Browser herzustellen und aufrecht zu erhalten, so dass der Application Server ABAP über das Internet per Browser erreichbar ist. Er empfängt einerseits HTTP-Anfragen über das Internet und leitet sie beispielsweise an den oben schon vorgestellten WEb Dispatcher weiter. Liefert der Web Dispatcher die Antwort auf eine solche Browser-HTTP-Anfrage, leitet er diese zum ICM weiter, so dass dieser die Antwort dann anschließend wieder zum Absender der Anfrage – meist als HTML-Seite an den Browser des Nutzers –  übermitteln kann.

Der ICm kümmert sich nicht um Anfragen, die per SAP Logon an den Server gestellt werden. Diese gehen direkt an den Dispatcher und werden auch direkt von diesem beantwortet.

SAP Gateway Prozess

Der SAP Gateway Prozessist ausschließlich im NetWeaver Application Server ABAP Stack vorhanden. Er darf nicht verwechselt werden mit dem Produkt SAP NEtWeaver Gateway. dieses Produkt ist nämlich eine andere Technologie, die zum Datenaustausch von Daten und funktionalitäten eines SAP-Systems mit Geräten zuständig ist. Der SAP Gateway Prozess, über den wir hier reden, ist zuständig für die Kommunikation mit anderen externen SAP-Systemen oder mit anderen SAP-Produkten oder Drittanbieterprodukten auf fremden Hostsystemen. Der Gateway-Prozess sit für die externe kommunikation nach außen zuständig, der unten noch vorgestellte message-Server für die interne kommunikation zwischen den SAP-Applikationsservern. Mit dem Gateway-prozess Diese Kommunikation erfolgt über Remote Function Calls (RFC). Das bedeutet: Über das Netzwerk werden auf dem NetWeaver Application Server ABAP Funktionen, Routinen und Methoden aufgerufen, die eine Antwort auf die anfrage des Absenders des RFC generieren. So kann man beispielsweise von einem anderen SAP-System aus einen User auf dem fremden Application Server ABAP erzeugen, indem man mit einem RFC die Funktion zum Erzeugen eines Users aufruft. das geht natürlich nur, wenn zuvor eine Art Vertrauensstellung zwischen den beiden Servern erzeugt wurde und de rUser auf dem Absender-Server die Berechtigung für diesen RFC hat.

Der Messageserver

Der Messageserver ist immer nur auf der Zentralinstanz eines Application Server verfügbar. Der Messageserver ist für die Clusterverwaltung, also das Load-Balancing, zuständig. Er verteilt die Last von Anfragen wenn möglich auf verschiedene Instanzen, die im Cluster-Verbund zusammenarbeiten. Damit das geht, wird der Messageserver eben in der Zentralinstanz zur Verfügung gestellt. Desweiteren msus er dazu in der Lage sein, Benutzernameldungen entgegenzunehmen und die Benutzer auf die verschiedenen Applikatiosnserver verteilen zu können. Desweiteren verwaltet er, wie der Name schon seagt, den anchrichtenaustausch zwischen den Appkikationsservern, um beispielsweise Sperren über das ganze SAP-System hinweg zu setzen doer batch-Aufträge auf die verschiedenen Applikationsserver zu verteilen. Neue Applikationsserver, die dem SAP-System hinzugeügt werden, melden sich beim Messageserver an.

Der Enqueue-Server

Der Enqueue-Server ist zuständig für das sogenannte Lock-Management. Er ist zuständig für die Verwaltung von Sperren, wenn bestimmte Trnaskationen ausgeführt werden. Wenn beispielsweise gerade die Daten über einen Kunden bearbeitet werden, kann nicht gleichzeitig ein anderer anwender ebenfalls die Daten ändern, weil sonst der eine die Änderungen des anderen überschreiben würde. Darum kümmert sich das Lock Management und somit auch der Enqueue-Server. Damit das funktioniert, wird der Enqueue-Server auf der Zentralinstanz bereitgestellt.

Der instanzcontroller

Der instanzcontroller existiert nur auf einem Application Server Java Stack. Er kontrolliert den LEbenszyklus der AS JAva Instanz.

Software Deployment Manager (SDM) und JSPM ( Java Support package Stack)

Der Software Deployment Manager ist Java-Stack-exklusiv. Er kommt in einem Java Stack in jeder Dialoginstanz einmal vor. Der SDM wurde in früheren Java Relases genutzt, um Support Package Stacks in einem Java AS einzuspielen. Heutzutage wird der Java Support Package Stack (JSPM) genutzt. Bei sind pro DI einmal vorhanden.

Der Java Connector (JCo)

Der JCo ermöglicht es, dass in Java geschriebene Programme mit dem SAP-System kommunizieren können und umgekehrt. Er verbindet sozusagen die applikationen in einem Java-Stack mit dem eigentlichen System. Der JCo erlaubt dabei Kommunikation in beide Richtungen: inbound (Java ruft ABAP) und outbound (ABAP ruft Java). Zum DAtenaustausch werden objektorientierte Java BAPIs eingesetzt. Als Behälter für den Datenaustausch zwischen java- und SAP-porgiorammen dienen sogenannte IDocs.

 

Wir halten fest: Eine Instanz eines SAP-Systems ist zusammengesetzt aus

• einem Dispatcher
• den zu diesem Dispatcher gehörenden Workprozessen
• gegebennfalls einem Internet communication Manager
• den zugeordneten Hauptspeicherbereichen (Puffer etc.)

instanz eines SAP-Systems sind nicht gleichbedeutend mit einer instanz eines Datenbanksystems. Dei mit einer SAP-instanz angebotenen Dienste werden gemeinsam mit dieser instanz gestartet bzw. gestoppt. Alle Komponenten einer Instanz werden über ein gemeinsames instanzprofil konfiguriert.

Der Start einer instanz beginnt mit dem Start des dispatchers. Ein Dispatcher bracuht gleichzeitig immer Minimum zwei Workprozesse, um zu starten. Es können auf eniem Rechner mehrere Dispatcher konfiguriert werden, die jedoch in verschiedenen instanzen sein müssen. Jeder dispatcher hat dabei einen eigenen Port. Die erste instanz / der erste Dispatcher haben dabei den Port 3200, alle weiteren werden hochgezählt.

Eine instanz ist dabei immer Applikationsserver mit den Applikationen, die ihr dispatcher über seien Workrpozesse zur Verfügung stellt. die Clients verbinden sich dazu auf die gewünschte Instanz und können dann mit den angebotenen Applikationen arbeiten.

Verbindungsaufbau zwischen Frontend / Client und Backend / Applikationsserver

Wenn sich nun ein Nutzer mit seinem SAPGUI-Frontend oder mit einem Webbrowser auf eine SAP-Instanz als Applikationsserver verbindet, gibt es einen bestimmten Ablauf, der durchwandert wird, bis eine Verbindung zsutande kommt. Damit eine Vebridnung afugebaut werden aknn, braucht SAPGUI bestimmte Angaben wi etwa Hostname / IP, Instanznummer usw. Diese APrameter trägt der Anwender in das Programm SAPLogon ein.

SAPGUI nimmt die Parameter, die es von SAP Logon bekommen hat, und startet eine Anfrage beim Message Server der Central Services Instanz eines SAP-Systems, dass man sich mit einer bestimmten Instanz dieses Systems verbinden möchte. Der messageserver sagt dann der SAPGUI des Benuzters, auf welchem Host die gewünschte Instanz zu finden ist. Daraufhin baut SAPGUI eine neue Verbindung auf – diesmal direkt mit der ausgewählten instanz. Die Instanz reagiert und schickt SAP GUI den Anmeldebildschirm zum Login eines Benutzers. Dazu schickt der Dispatcher zunächst einfach einen anmeldebildschirm an das sAPGUi des nutzers. Dieser trägt seine Anmeldedaten ein und schickt diese wieder an die instanz. Der Disaptcher bekommt die anmeldedaten, fndet einen freine Workprozess zur Abarbeitung der Anmeldung und übergibt diese Daten an den Workprozess. Der Wrokprozess wiederum prüft durhc eine Anfrage an die Datnebank, ob die Anemldedaten korrekt sind. Wenn das der fall ist, baut der Workprozess das Menü SAP Easy Access auf, welches der Dispatcher an das SAPGUI des Nutzers sendet, damit dieser arbeiten kann.

 Transaktionsablauf

Grundsätzlich läuft die Abarbeitung einer Transaktion zwischen SAPGUI und einer SAP-Instanz sehr ähnlcih ab wie der Anmeldeprozess. Wenn eine Transaktion aus mehreren Bildschirmbildern bestehen sollte, wird die ababreitung in der Regel auf mehrere Workprozesse verteilt. Diese Verteilung nennt man „Workprozess-Multiplexing“.  Bei jeder dieser Bildschirmteile spriht man wiederum von einer Transaktion.

Das heißt aber auch, dass eigentlich zusammengehörende Transaktionen, die nur zusammen ein betriebswirtschaftlich verwertbares Ergebnsi erzielen können, voneiannder abhängig sind. Wenn einer der workprozesse ausfällt, gehen die Bearbeitungsschritte der anderen Workprozesse ins Leere. Daher ist in SAP-Systemen das Verfahren der asynchronen Verbuchung gang und gäbe.

Shared memory

Die kommunikation zwischen den weiter oben angesprochenen Workprozessen erfolgt über gemeinsame Speichebrereiche (shared memory). Damti diese Workprozesse effizient arbeiten können, müssen diese Puffer sauber dimensioniert und befüllt werden. im sogenannten R/3-Tabellenpfufer werden die Daten genutzter Tabellen gecached. Braucht ein Workprozess nun Daten aus der Datenbank, wird zuerst geprüft, obn diese schon im Tabellenpuffer vorrätig sind. Wenn nämlich vorher schon ein anderer prozess die daten aus der DB geholt hat, können die Daten wiedervrwendet werden.

Wie wir bereits wissen, liegen die übersetzten und kompilierten ABAP-programme ebenfalls in einem Puffer vor. Je länger ein SAP-System läuft, desto optimaler sind die Puffer befüllt Die Pfufer gehen leider verloren, sobald ein SAPM system neu druchgestartet wird.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!