Beschreiben von AS ABAP

Die SAP-Hilfedokumentation bietet Ihnen wertvolle Unterstützung beim Kennenlernen von Systemfunktionen. Außerdem werden die Konzepte der Systemarchitektur erläutert, Beispiele für die Konfiguration verschiedener Prozesse angeführt und mögliche Benutzerfehler und ihre Folgen erklärt. Die Online-Dokumentation enthält auch viele Tipps und Tricks, die die alltägliche Arbeit mit dem SAP-System erleichtern und beschleunigen.

Im SAP Help Portal können Sie auf die Dokumentation von SAP-Produkten zugreifen. Es gibt viele Anleitungen und Dokumentationen, z.B.:

• Installationsleitfäden,
• Sicherheitsleitfäden,
• Erste Schritte,
• und vieles mehr.

Sie können die Suchleiste oder die Produkthierarchie verwenden, um die gewünschte Product Assistance zu öffnen.

Sie haben die Möglichkeit, die Suchleiste für die Suche nach Produkten oder die Suche nach Schlüsselwörtern über das gesamte SAP Help Portal und alle Produkte zu verwenden. Darüber hinaus haben Sie die Möglichkeit, auf etwa 250 Learning Journeys für mehrere Produkte zuzugreifen und diese anzuzeigen. Diese Learning Journeys umfassen Tutorials, openSAP-Kurse, Referentenschulungen aus dem Schulungsshop.

Wenn Sie das SAP Help Portal öffnen möchten, müssen Sie zu https://help.sap.com

Die Benutzer können sich über den (ABAP-)Message-Server (Lastverteilung) oder direkt am ABAP-Dispatcher anmelden. Die Benutzereingaben werden durch die Workprozesse ausgeführt.

Die Bildschirmeingaben eines Benutzers werden von einer Frontend-Software, z.B. dem SAP GUI (Graphical User Interface), akzeptiert, in ein internes Format konvertiert und an den Dispatcher weitergeleitet.

Ein zentraler Prozess des AS ABAP ist der (ABAP-)Dispatcher. Er verwaltet in Abstimmung mit dem jeweiligen Betriebssystem die Ressourcen für die in ABAP geschriebenen Anwendungen. Zu den Hauptaufgaben des ABAP-Dispatcher gehört die Verteilung der Anfragen (Requests) auf seine Workprozesse, die Anbindung der Präsentationsebene und die Organisation von Kommunikationsaktivitäten.

Die Verarbeitungsanfragen werden vom Dispatcher zunächst in sogenannten Request-Queues (Warteschlangen für Anfragen) gesichert, die anschließend nach dem Prinzip „first in, first out" abgearbeitet werden.

Der ABAP-Dispatcher verteilt die Anfragen (Requests) nacheinander auf freie Workprozesse. Im Workprozess findet die eigentliche Verarbeitung statt, wobei der Benutzer, der die Anfrage über das SAP GUI angelegt hat, nicht immer denselben Workprozess zugewiesen bekommt. Es gibt also keine feste Zuordnung von Workprozessen zu Benutzern. Zur Verarbeitung von Benutzeranfragen ist es oft notwendig, Daten aus dem ABAP-Schema der Datenbank zu lesen oder in dieses zu schreiben. Hierzu ist jeder Workprozess direkt mit dem ABAP-Schema der Datenbank verbunden.

Am Ende der Verarbeitung gelangt das Verarbeitungsergebnis des Workprozesses über den Dispatcher an das SAP GUI zurück. Das SAP GUI interpretiert die empfangenen Daten und erzeugt das Ausgabebild für den Benutzer.

Die Puffer dienen zur schnelleren Bearbeitung der Benutzeranfragen. Daten, die gelesen, aber nur selten geändert werden (z.B. Programme oder Daten des Customizing wie Währungen oder Buchungskreise), können als Kopie des Datenbankinhalts im Shared Memory des Applikationsservers aufbewahrt werden. Auf diese Weise müssen die Daten nicht immer wieder aus der Datenbank gelesen werden, sondern können schnell aus den Puffern abgerufen werden. Jede Instanz hat eigene Puffer.

Workprozesse führen die Ablauflogik von Anwendungsprogrammen aus. Ein Workprozess hat neben internem Speicherplatz einen Task-Handler, der die Aktivitäten innerhalb eines Workprozesses koordiniert, Softwareprozessoren sowie eine Datenbankschnittstelle. Der Dynpro-Prozessor führt die Bildschirmablauflogik des Anwendungsprogramms aus, ruft Programmteile der Verarbeitungslogik auf und sorgt für die Weitergabe von Feldinhalten an die Verarbeitungslogik. Die eigentliche Verarbeitungslogik von ABAP-Anwendungsprogrammen wird vom ABAP-Interpreter ausgeführt. Der ABAP-Prozessor wird vom Dynpro-Prozessor informiert, welcher Programmteil entsprechend dem Fortgang der Bildschirmablauflogik abzuarbeiten ist.

Der vom Dispatcher ausgewählte Dialog-Workprozess führt zunächst einen Roll-in des Benutzerkontexts durch. Das heißt, die Daten, die den aktuellen Bearbeitungsstand eines laufenden Programms enthalten sowie Daten, die den Benutzer charakterisieren, werden dem Workprozess mitgeteilt. Dann arbeitet der Workprozess die Benutzeranfrage ab, wobei er sich gegebenenfalls an die Datenbank oder die Puffer im Shared Memory wendet, um beispielsweise Daten anzufordern. Nach der Bearbeitung des Dialogschritts gibt der Workprozess das Ergebnis zurück, rollt den Benutzerkontext wieder heraus ins Shared Memory und ist damit wieder frei für eine neue Benutzeranfrage aus der Request-Queue. Das Ergebnis wird dem SAP GUI übergeben, und der Benutzer sieht das neue Bildschirmbild.

Relationale Datenbankmanagementsysteme (RDBMS) werden generell zur Verwaltung großer Datenmengen verwendet. Ein RDBMS sichert Daten und Beziehungen zwischen Daten in Form von zweidimensionalen Tabellen. Diese zeichnen sich durch ihre logische Einfachheit aus. Auf Datenbankebene erfolgt die Definition von Daten, Tabellen und Tabellenbeziehungen im Datenbankkatalog (Data Dictionary) des RDBMS.

Innerhalb der SAP-Programmiersprache ABAP kann mittels ABAP SQL (SQL = Structured Query Language, Datenbankabfragesprache) unabhängig vom jeweiligen RDBMS auf die Anwendungsdaten der Datenbank zugegriffen werden. Die Datenbankschnittstelle, die Bestandteil eines jeden Workprozesses von AS ABAP ist, sorgt für die Umsetzung der ABAP-SQL-Anweisungen aus ABAP in entsprechende SQL-Anweisungen speziell für die verwendete Datenbank (Native SQL). Somit können ABAP-Programme datenbankunabhängig programmiert werden.

ABAP SQL wurde bis AS ABAP 7.52 als „Open SQL" bezeichnet.

Die Ausführung von Dialoganfragen wird wie folgt charakterisiert:

In SAP-Anwendungsprogrammen wird zwischen Benutzerinteraktionen und Verarbeitungslogik unterschieden. Programmtechnisch werden die Benutzerinteraktionen durch Dynpros (dynamische Programme), bestehend aus einer Bildschirmmaske und der zugehörigen Bildschirmablauflogik, realisiert. Der Dynpro-Prozessor des Workprozesses führt die Bildschirmablauflogik des Anwendungsprogramms aus, ruft Programmteile der Verarbeitungslogik auf und sorgt für die Weitergabe von Feldinhalten an die Verarbeitungslogik. Die Bildschirmablauflogik ist selbst wieder unterteilt in den PBO (Process Before Output), der vor dem Senden des Bildschirmbildes verarbeitet wird, und den PAI (Process After Input), der nach einer Benutzerinteraktion auf dem Bildschirmbild verarbeitet wird. Der PAI-Teil eines Dialogschritts gehört logisch zum vorherigen Bildschirmbild, der PBO-Teil logisch zum nachfolgenden Bildschirmbild. Die eigentliche Verarbeitungslogik von ABAP-Programmen wird vom ABAP-Interpreter ausgeführt. Dieser wird vom Dynpro-Prozessor darüber informiert, welcher Programmteil entsprechend dem Fortgang der Bildschirmablauflogik abzuarbeiten ist.

Wenn im Laufe eines Dialogschrittes Daten mit der Datenbank oder den Puffern ausgetauscht werden müssen, geschieht dies über die Datenbankschnittstelle, die unter anderem den Zugang zu Datenbanktabellen, ABAP-Programmen oder dem ABAP-Dictionary ermöglicht.

Aus Gründen der Datenkonsistenz in SAP-Systemen muss sichergestellt sein, dass ein- und derselbe Datensatz nicht gleichzeitig von verschiedenen Benutzern aufgerufen und geändert werden kann. Hierfür existiert im SAP-System ein eigenes Sperrverwaltungskonzept.

Aus Datenbanksicht bildet jeder Dialogschritt eine physische und logische Einheit: die Datenbanktransaktion. Die Sperrverwaltung der Datenbank kann nur solche Datenbanktransaktionen koordinieren. Aus SAP-Sicht genügt dies jedoch nicht, da SAP-Transaktionen, die aus einer Folge betriebswirtschaftlich konsistenter und logisch zusammenhängender Arbeitsschritte gebildet werden, zumeist aus mehreren Dialogschritten bestehen. Daher ist es notwendig, dass SAP-Systeme eine eigene Sperrverwaltung verwenden. Diese wird mithilfe des Enqueue-Prozesses realisiert. Hierdurch wird auch die Plattformunabhängigkeit der Sperrverwaltung gewährleistet.

Das SAP-Sperrkonzept sieht vor, dass ein SAP-Programm für die zu bearbeitenden Datensätze Sperreinträge in einer Sperrtabelle einträgt. Das Eintragen eines Sperreintrags gelingt nur, wenn für die betreffenden Tabelleneinträge bisher noch keine Sperreinträge vorhanden sind.

Die Sperrtabelle befindet sich im Hauptspeicher des Applikationsservers mit dem Enqueue-Workprozess. Der Enqueue-Workprozess verwaltet die logischen Sperren der SAP-Transaktionen in der Sperrtabelle.

Der Enqueue-Prozess kann auf zwei Arten implementiert werden:

• als Workprozess

• Als Teil der ABAP-Zentralserviceinstanz (ASCS, Standardinstallationsoption für alle Neuinstallationen und obligatorisch ab AS ABAP 7.50/7.51)

Seit AS ABAP 7.00 kann zwischen diesen beiden Optionen gewählt werden. Die Option ASCS wird z.B. aus Gründen der Hochverfügbarkeit bevorzugt. Ab AS ABAP 7.50 ist das ASCS-Setup obligatorisch, wenn das SAP-System mehr als einen Anwendungsserver hat. Seit AS ABAP 7.51 ist das ASCS-Setup in jedem Fall obligatorisch. Das ASCS-Setup ist obligatorisch, wenn ein Enqueue-Replikationsserver (ERS) installiert werden soll.

Will ein Benutzer auf Daten zugreifen und diese ändern, fordert der ausführende Dialog-Workprozess eine Sperre an (dazu muss der Anwendungsentwickler diese Anforderung explizit programmieren).

Bei der Sperranforderung wird überprüft, ob die angeforderte Sperre nicht mit bereits vorhandenen Einträgen in der Sperrtabelle Konflikte verursachen. Falls bereits entsprechende Einträge in der Sperrtabelle vorhanden sind, wird die Sperranforderung zurückgewiesen. So kann das Anwendungsprogramm den Benutzer frühzeitig darauf hinweisen, dass die von ihm gewünschte Operation derzeit nicht möglich ist.

Der Anwendungsentwickler kann zwischen verschiedenen Sperrmodi wählen:

• Schreibsperren (Sperrmodus Exklusiv): Die Sperrdaten können nur von einem Benutzer bearbeitet werden. Sowohl die Anforderung einer weiteren Schreibsperre als auch einer Lesesperre werden abgewiesen. Eine Schreibsperre schützt das gesperrte Objekt gegen Sperren aller Art anderer Transaktionen. Nur derselbe Sperreigentümer kann die Sperre erneut setzen (kumulieren).

• Lesesperren (Sperrmodus Shared): Mehrere Benutzer können gleichzeitig Lesezugriff auf die gesperrten Daten haben. Die Anforderungen weiterer Lesesperren werden akzeptiert, auch wenn diese von anderen Benutzern kommen. Eine Schreibsperre wird abgewiesen.

• Erweiterte Schreibsperren (Sperrmodus Exklusiv nicht kumulativ): Während Schreibsperren sukzessive von derselben Transaktion angefordert und freigegeben werden können, kann eine erweiterte Schreibsperre auch von derselben Transaktion nur einmal angefordert werden. Jede weitere Anforderung einer Sperre wird abgewiesen.

• Optimistische Sperren (Sperrmodus Optimistisch): Optimistische Sperren reagieren zunächst wie Lesesperren und können in Schreibsperren geändert werden. Eine optimistische Sperre wird gesetzt, wenn der Benutzer die Daten im Änderungsmodus anzeigt. Optimistische Sperren für dasselbe Objekt kollidieren nicht. Will der Benutzer die (geänderten) Daten sichern, muss die optimistische Sperre in eine Schreibsperre (Modus E) umgewandelt werden. (Dies schlägt fehl, wenn jemand zuvor eine nicht optimistische Sperre für das Objekt gesetzt hat.) Andere optimistische Sperren auf das Objekt werden dabei gelöscht.

Von einem Anwendungsprogramm gesetzte Sperren werden entweder vom Anwendungsprogramm selbst oder vom Verbuchungsprogramm nach erfolgter Datenbankänderung zurückgesetzt. Sperren, die an einen Verbuchungs-Workprozess weitergegeben wurden, werden auch auf Betriebssystemebene in eine Datei geschrieben und können somit bei einem Systemausfall des Enqueue-Servers wiederhergestellt werden.

In der Transaktion SM12/SMENQ werden die aktuell gehaltenen Sperren angezeigt. Wenn eine Sperre bereits an den Verbuchungsprozess vererbt wurde, wurde auch das Backup-Flag gesetzt. Eine solche Sperre wird auch nach einem Neustart des Enqueue-Servers wieder in die Sperrtabelle aufgenommen.

Um auf die Sperrtabelle zuzugreifen, verwenden Sie die Transaktion SM12 in SAP-Systemen mit SAP_BASIS 7.52 und älteren Versionen. Verwenden Sie die Transaktion SMENQ in SAP-Systemen mit SAP_BASIS 7.53 und neueren Versionen. In SAP-Systemen mit SAP_BASIS 7.55 und höher ist SM12 die neue SMENQ.

Es gibt zwei Möglichkeiten, Sperreinträge, die von Benutzern gehalten werden, zu löschen:

• Beenden der Benutzersitzung in der Benutzerübersicht (Transaktion SM04)

• Manuelles Löschen der Sperreinträge in Transaktion SM12/SMENQ

Die erste Methode (Beenden der Benutzersitzung) führt auch dazu, dass der ursprüngliche Sperreigentümer die Transaktion verlässt und alle Sperren freigibt. Bei der zweiten Methode (manuelles Löschen mit SM12/SMENQ) wird lediglich der Sperreintrag aus der Sperrtabelle entfernt. Damit können theoretisch mehrere Benutzer gleichzeitig dieselben Datensätze ändern.

Das Verbuchungssystem dient zur Entlastung der SAP-Transaktionen bei zeitaufwendigen Datenbankänderungen. Diese werden asynchron in speziellen Verbuchungs-Workprozessen durchgeführt. Zudem umgeht das Verbuchungssystem Rollback-Probleme, die durch die unterschiedliche Auffassung von Logical Units of Work (LUWs) in einer SAP-Transaktion und in der Datenbank verursacht werden.

Wenn während eines Dialog-Workprozesses die zur Verarbeitung zwischengespeicherten Daten zur weiteren Verarbeitung an einen Verbuchungs-Workprozess übergeben werden, wartet der Dialog-Workprozess nicht auf den Abschluss des Verbuchungsauftrags: Die Verbuchung erfolgt asynchron (nicht gleichzeitig). Der Ablauf der asynchronen Verbuchung ist in der Abbildung „Prinzip der asynchronen Verbuchung" dargestellt.

Der Dialogteil wird mit der ABAP-Anweisung COMMIT WORK abgeschlossen; es beginnt der Verbuchungsteil der Transaktion. Der Verbuchungsserver übergibt den Verbuchungsauftrag an einen Verbuchungs-Workprozess. Hierbei entspricht jeder Dialogschritt einer Datenbank-Transaktion (die auf der Datenbank entweder vollständig oder überhaupt nicht ausgeführt und dort mit einem COMMIT abgeschlossen wird). Der Verbuchungsteil der SAP-Transaktion wird in einer Datenbank-Transaktion durchgeführt. Erst in dieser werden die Daten tatsächlich in die Anwendungstabellen übernommen.

Will ein Benutzer im Rahmen einer SAP-Transaktion einen Datensatz ändern, ruft er die entsprechende Transaktion im Dialog auf, nimmt auf den Bildern die notwendigen Eingaben vor und initiiert schließlich den Verbuchungsvorgang, indem er die Daten sichert. Dabei werden folgende Schritte ausgelöst:

1. Das Programm sperrt den Datensatz für andere Benutzer. Hierzu wird der Enqueue-Workprozess (gegebenenfalls über den Message Server) angesprochen. Der Enqueue-Workprozess sorgt für den entsprechenden Eintrag in die Sperrtabelle bzw. (falls schon ein Benutzer die Daten gesperrt hat) informiert den Benutzer, dass der Datensatz nicht geändert werden kann.

2. Konnte der Sperreintrag in die Sperrtabelle geschrieben werden, so wird der vom Enqueue-Workprozess erzeugte Sperrschlüssel an den Benutzer weitergereicht, das Programm liest den zu ändernden Satz von der Datenbank und der Benutzer kann ihn auf dem Bildschirmbild der SAP-Transaktion ändern.

3. Das Programm ruft im aktuellen Dialog-Workprozess einen Funktionsbaustein mittels CALL FUNCTION ... IN UPDATE TASK auf und schreibt die Verbuchungsanforderung in Verbuchungstabellen in die Datenbank. Diese werden auch als VB*-Tabellen bezeichnet, da ihre Namen mit „VB" beginnen. Sie fungieren als Zwischenspeicher und halten die zu ändernden Daten so lange, bis diese (in einer einzigen Datenbanktransaktion) gesammelt in die Anwendungstabellen in der Datenbank geschrieben werden.

4. Wenn das Ende des Dialogteils der Transaktion erreicht ist (zum Beispiel wenn der Benutzer die Daten – gegebenenfalls nach weiteren Dialogschritten – sichert), leitet das Programm mit der Anweisung COMMIT WORK den Abschluss der Transaktion ein. Der Workprozess, der gerade den aktuellen Dialogschritt bearbeitet, vervollständigt den Verbuchungskopf und stößt einen Verbuchungs-Workprozess an.

5. Aufgrund der vom Dialog-Workprozess übermittelten Informationen (Schlüssel des Verbuchungsauftrags, Sperrschlüssel) liest der Verbuchungs-Workprozess die zu dieser SAP-Transaktion gehörigen Protokollsätze aus den VB*-Tabellen.

6. Der Verbuchungs-Workprozess gibt die in den VB*-Tabellen gesammelten Änderungsvormerkungen als Verbuchungsanforderung an die Datenbank und wertet deren Rückmeldung aus. Im Erfolgsfall löst der Verbuchungs-Workprozess nach der letzten Datenbank-Änderung ein Datenbank-Commit aus und löscht die Einträge aus den VB*-Tabellen. Im Fehlerfall löst der Verbuchungs-Workprozess einen Datenbank-Rollback aus, lässt die Protokollsätze in den VB*-Tabellen stehen und kennzeichnet sie als fehlerhaft.

7. Die Sperreinträge in der Sperrtabelle werden zurückgesetzt.

Bei Fehlersituationen während der Verbuchung wird die Verarbeitung der aktuellen Verbuchungskomponente abgebrochen. Der Benutzer kann bei Verbuchungsabbrüchen vom System automatisch über eine Express-Mail benachrichtigt werden.

Wenn ein Dialog-Workprozess beim Schreiben in die VB*-Tabellen abbricht, enthalten die Tabellen Daten, die nicht verbucht werden. Diese Einträge können automatisch beim nächsten Start des SAP-Systems oder manuell gelöscht werden. Die eigentlichen Anwendungstabellen bleiben unverändert.

Eine asynchrone Verbuchung kann aus verschiedenen Gründen abbrechen. Wird zum Beispiel versucht, einen Datensatz (per Insert) mehrfach in eine Tabelle einzutragen, wird im Coding die Ausnahmebedingung „Duplicate Key" ausgelöst, weil unter diesem Schlüssel bereits ein Eintrag in der Tabelle existiert. Der entsprechende Datensatz kann deshalb nicht mehrfach in die Datenbanktabelle geschrieben werden.

Bei abgebrochenen Verbuchungen wird der die Verbuchungen auslösende Endanwender in Form einer Express-Mail benachrichtigt. Über die SAP-Systemadministration müssen dann weitere Schritte eingeleitet werden. Ihr stehen in der Transaktion SM13 (Verbuchungsaufträge) Analysewerkzeuge zur Behandlung abgebrochener Verbuchungen zur Verfügung. Nach der Behebung des den Abbruch verursachenden Fehlers (zum Beispiel nach Beseitigung des Hardwareschadens) sollte die Bearbeitung durch den Endanwender wiederholt werden.

Für eine optimale Druckabwicklung empfiehlt sich die frühzeitige Übergabe von zu druckenden Daten an das Betriebssystem. Dies wird durch die lokale Kopplung erreicht. Das Betriebssystem übernimmt dann alle weiteren druckrelevanten Aufgaben wie Queueing und die Datenübermittlung an den gewählten Drucker.

Sie können Ihre eigenen Spool- und Ausgabeaufträge anzeigen, indem Sie die Transaktion SP02 wählen.

Auf der Registerkarte Festwerte im Abschnitt Spool-Steuerung können Sie unter System → Benutzervorgaben → Benutzerdaten (Transaktionscode SU3) persönliche Einstellungen für den Druck festlegen.

Die SAP-Hintergrundverarbeitung dient der Automatisierung von Routineaufgaben und der Optimierung des Einsatzes der SAP-Rechenressourcen Ihres Unternehmens. Bei der Hintergrundverarbeitung weisen Sie das SAP-System an, Programme für Sie auszuführen. Über die Hintergrundverarbeitung können Sie langlaufende oder ressourcenintensive Programme in Zeiten mit geringer Systemlast ausführen. Damit können Sie dem SAP-System die Aufgabe zuweisen, Programme auszuführen. Ihre Dialogressourcen werden nicht belastet, Programme, die im Hintergrund laufen, unterliegen nicht den Laufzeitbeschränkungen der Dialogverarbeitung (Abbruch des Programms nach einer Laufzeit von z.B. zehn Minuten).

Der Endbenutzer kann in der Regel aus der Anwendungstransaktion heraus das zu startende Programm im Hintergrund als Job einplanen. Der Job wartet dann in der Jobeinplanungstabelle auf den geplanten Ausführungszeitpunkt. Wenn der Zeitpunkt gekommen ist und freie Hintergrund-Workprozesse zu Verfügung stehen, wird der Job vom Background Scheduler auf einen Hintergrund-Workprozess verteilt und ausgeführt. Benutzer können das Ergebnis in der Anwendungstransaktion anzeigen oder bei listenerzeugenden Programmen den zum Job gehörenden Spool-Auftrag ansehen (siehe Abschnitt Drucken). Zum Anzeigen der eigenen Jobs wählen Sie in der Menüleiste System → Eigene Jobs (Transaktionscode SMX).

Die SAP-Systemadministration und die Arbeitsvorbereitung haben über Transaktion SM36 Zugriff auf ein Werkzeug zum Einplanen verschiedener Hintergrundaufgaben. Die systemweite Überwachung der Jobs erfolgt mit der Transaktion SM37.

Für die systemübergreifende Einplanung und Überwachung von Hintergrundaufgaben können SAP Central Process Scheduling und andere lizenzierte Partnerprodukte eingesetzt werden.

Bei der Kommunikation zwischen Applikationsservern eines SAP-Systems oder zwischen SAP-Systemen per Remote Function Call (RFC) oder CPIC (Common Program Interface Communication) wird stets das Gateway involviert. Muss ein Dialog-Workprozess im Rahmen einer Anfrage eine RFC-Verbindung zu einem entfernten SAP-System herstellen, zum Beispiel um Kundendaten abzurufen, so wendet er sich an das Gateway, das die Kommunikation mit dem entfernten SAP-System übernimmt. Das Gateway leitet die Anfrage an das Gateway des entfernten SAP-Systems weiter. Das entfernte Gateway übergibt die Anfrage dann an den Dispatcher. Dieser wiederum leitet die Anfrage an einen seiner Workprozesse weiter, der schließlich direkt mit seinem lokalen Gateway kommuniziert.

Eingehende RFC-Verbindungen werden also stets vom Gateway entgegengenommen. Ausgehende Verbindungen werden vom Workprozess initiiert.

Der ICM diese Anfrage an den ABAP-Dispatcher weiter, der diese Anfrage wie eine Anfrage des SAP GUIs behandelt (siehe voriger Abschnitt). Der Workprozess, der die Anfrage verarbeitet, kommuniziert nun direkt mit dem ICM. Der ICM schickt die Antwort dann an den anfragenden Benutzer zurück.

Die Workprozesse können direkt webfähige Inhalte erzeugen, die dann über den ICM an die anfragenden Browser-Frontends übergeben werden können.

Der ICM ermöglicht die Verwendung verschiedener UI-Technologien, wie SAPUI5, Web Dynpro ABAP oder Business Server Pages (BSP). In dieser Aufzählung stehen neuere Technologien weiter vorne.

Die unten aufgeführten Transaktionen helfen bei der Bewältigung der täglichen Arbeit der SAP-Systemadministration. Als SAP-Systemadministrator sollten Sie mit der Verwendung und Interpretation dieser Transaktionen vertraut sein.

Über Transaktion SM51 können Sie die Applikationsserver anzeigen, die beim SAP Message Server angemeldet sind. Diese bilden die Applikationsserver des SAP-Systems. An ihrem Status können Sie erkennen, welche Applikationsserver im SAP-System aktiv sind.

Folgende Funktionen stehen Ihnen als Menüpunkte zur Verfügung; wichtige Menüpunkte sind zusätzlich als Drucktasten auf dem Bildschirm zu sehen. Von hier aus kann man in andere Transaktionen navigieren:

• Workprozesse anzeigen und steuern (Transaktion SM50)

  Benutzermodi anzeigen und verwalten (Transaktion SM04)

• Systemprotokolle (Transaktion SM21)

Auch die folgenden Transaktionen sind verfügbar:

• Gateway-Monitor (Transaktion SMGW)

• ICM Monitor (Transaktion SMICM)

• Den Betriebssystemmonitor (ST06), um nur einige zu nennen

Transaktion SM50 zeigt eine Momentaufnahme des Zustands der Workprozesse auf dem Applikationsserver, auf dem Sie angemeldet sind. Sie erhalten aktuelle Informationen, wenn Sie die Anzeige aktualisieren. Die Prozessübersicht dient hauptsächlich dazu, Informationen zusammenzutragen. Sie können z.B. Prozesse überwachen, um festzustellen, ob die Zahl der Workprozesse im System angemessen ist und wie ausgelastet der Applikationsserver ist, oder um Informationen zur Fehlerbehebung oder zum Tuning zu sammeln.

Mithilfe der Transaktion SM04 können Sie alle Benutzer anzeigen, die im SAP-System auf diesem Applikationsserver angemeldet sind. Ab AS ABAP 7.40 können mithilfe der Transaktion SM04 auch die angemeldeten Benutzer systemweit angezeigt werden.

Mithilfe der Transaktion zur Benutzerpflege (SU01) können einzelne Benutzerstammsätze gepflegt werden. Der Benutzeradministrator kann damit neue Benutzerstammsätze anlegen oder bestehende Benutzerstammsätze ändern und z.B. neue Rollen und Berechtigungsprofile zuordnen.

Für die Massenpflege von Benutzern gibt es die Transaktion SU10.

Mithilfe der Transaktion SM36 können Sie Hintergrundjobs im SAP-System anlegen.

Über die Transaktion SM37 können Sie eine Übersicht über die Hintergrundjobs im SAP-System anzeigen.

Die Transaktion SM21 dient zur Analyse des Systemprotokolls.

Sperreinträge in der Sperrtabelle des Enqueue-Workprozesses lassen sich über die Transaktion SM12/SMENQ verwalten. Die Sperrverwaltung dient dazu, die Sperrlogik im SAP-System zu überwachen. Sie können ermitteln, welche Sperren momentan gehalten werden.

Mithilfe der Verbuchungsverwaltung (Transaktion SM13) können Sie folgende Aufgaben durchführen:

• Verbuchungsaufträge anzeigen

• Probleme im Zusammenhang mit der Verbuchung analysieren

• abgebrochene Verbuchungsaufträge testen und bereinigen

• den Status von Verbuchungsaufträgen anzeigen und zurücksetzen

• Verbuchungsaufträge löschen

• Statistiken über die Verbuchung anzeigen

Diese Funktion dient dazu, sich einen Überblick über die Verbuchungsaufträge zu verschaffen und aufgetretene Probleme zu untersuchen. Ordnungsgemäß verbuchte Aufträge werden hier nicht angezeigt.

Zusätzlich zu den Alerts weist das SAP-System jeden Benutzer, dessen Verbuchung abgebrochen wurde, mit einer Express-Mail auf den Verbuchungsfehler hin. Die Mail wird in dem SAP-System gesendet, in dem das Problem auftrat.

Wenn Sie allen Benutzern des SAP-Systems eine Nachricht zukommen lassen möchten, können Sie mithilfe der Transaktion SM02 eine Systemnachricht verschicken. Es ist auch möglich, den Empfängerkreis auf Benutzer eines Mandanten oder auf Benutzer, die an einem bestimmten Applikationsserver angemeldet sind, zu beschränken. Eine Nachricht wird dem Empfänger nur einmal täglich angezeigt. Das SAP-System zeigt Nachrichten an:

• wenn ein Benutzer sich am SAP-System anmeldet

• (bei bereits angemeldeten Benutzern) sobald der Benutzer den nächsten Dialog-Schritt ausführt