Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration. Manfred Sprenger
an alle Mitarbeiter des Supportteams, die mit dem SAP-Troubleshooting betraut sind. Aber auch Entwickler und technisch interessierte Key-User sollten genügend Hilfestellungen finden, um selbst in die Fehleranalyse einzusteigen. Mit den so gewonnenen Informationen sind Sie dann hoffentlich in der Lage, anhand von SAP-Hinweisen eigenständig Lösungen zu finden.
Über dieses Buch
In diesem Buch werden typische, in der täglichen SAP-Praxis auftretende Problemsituationen beschrieben. Zu Beginn eines jeden Kapitels erläutere ich zunächst die jeweils beteiligten technischen Komponenten. Dabei geht es mir nicht darum, jedes Detail und jede mögliche Variante einer Komponente zu schildern, schließlich liefert die SAP mit ihrer Onlinedokumentation praktisch zu allen Themen ausführliche Informationen. Ich beschränke mich jeweils auf die Vermittlung des aus meiner Sicht erforderlichen Wissens, um Fehlermeldungen zu verstehen und die für eine weitere Analyse zur Verfügung stehenden Werkzeuge einsetzen zu können. Die SAP-Basis-Profis unter den Lesern mögen mir die eine oder andere Vereinfachung der geschilderten Sachverhalte nachsehen.
Das für mich wichtigste Werkzeug, der ABAP-Debugger, wird mit der für die meisten Einsatzfälle notwendigen Tiefe in Kapitel 9 beschrieben. Der Debugger kommt eigentlich immer dann zum Einsatz, wenn es darum geht, ein Problem zu reproduzieren, um dabei detailliert den Ablauf einer Anwendung zu analysieren. Ist das Debugging aus technischen Gründen nicht möglich, weil z.B. die Berechtigungen dafür insbesondere in dem produktiven SAP-System nicht vorliegen oder das Problem nicht noch einmal erzeugt werden kann, bleibt oft nur noch die Auswertung von Log- und Tracedateien. Kapitel 11 zeigt Ihnen, welche Dateien hier helfen können und wie sie zu analysieren sind. Ergänzend zu den Log- und Tracedateien stehen u.U. auch ABAP-Dumps zur Verfügung, die Informationen zu Programmabbrüchen beinhalten. In Kapitel 6 erfahren Sie, wie Sie mithilfe der Transaktion ST22 die in den Dumps protokollierten Laufzeitfehler untersuchen können.
Immer wieder gilt es, zu klären, in welcher Tabelle eigentlich welche Daten abgelegt werden. Nur wer die Tabellennamen kennt, kann mit Werkzeugen wie den Transaktionen SE16 oder SM30 überprüfen, ob die erforderlichen Daten tatsächlich vorhanden sind. Kapitel 12 zeigt Ihnen, welche Tools zur Verfügung stehen, um Tabellennamen zu ermitteln.
Während die bisher genannten Kapitel eher universell Hilfestellungen für jedwede Art von Fehlern geben, befassen sich die im Folgenden aufgeführten Abschnitte mit speziellen Problemen:
Gleich das erste Kapitel habe ich den immer mal auftretenden Performanceproblemen gewidmet. Geklärt werden soll insbesondere die Frage, mit welchen Tools nachvollzogen werden kann, ob es sich dabei lediglich um den subjektiven Eindruck einzelner SAP-Anwender handelt oder ob die Probleme objektiv nachvollziehbar sind.
Kapitel 2 beschäftigt sich mit der SAP-Hintergrundverarbeitung und beschreibt, welche Ursachen für Jobabbrüche, Jobausfälle oder verzögerte Ausführungen verantwortlich sind.
In Kapitel 3 soll ein Verständnis dafür geweckt werden, warum das Monitoring des SAP-Verbuchers wichtig ist.
Die SAP-Sperrverwaltung ist Thema des Kapitels 4, während die eher selten auftretenden Probleme mit der Nummernkreisdefinition in Kapitel 5 geschildert werden.
Sind Sie an der Lösung von Problemen im Zusammenhang mit dem »Drucken« interessiert, sollten Sie Kapitel 7 konsultieren.
Eine Vielzahl der Meldungen, die ein Supportteam zu bearbeiten hat, betrifft das Thema »Berechtigungen«. Kapitel 8 zeigt Ihnen, wie Sie fehlende Berechtigungen ermitteln können, aber auch wie man zu viel vergebene Berechtigungen finden kann.
Da jedes SAP-System für gewöhnlich eine Vielzahl von Schnittstellen zu weiteren SAP-Systemen und auch Nicht-SAP-Systemen besitzt, ist es sicherlich hilfreich, sich mit Kapitel 10 zu befassen. Hier erfahren Sie, wie Sie Fehler im Zusammenhang mit der Kommunikation über RFC oder den Internet Communication Manager analysieren sollten.
In den Text sind Kästen eingefügt, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:
Hinweis
Beispiel
Achtung
Die Form der Anrede
Um den Lesefluss nicht zu beeinträchtigen, verwenden wir im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform, meinen aber gleichermaßen die weibliche.
Hinweis zum Urheberrecht
Zum Abschluss des Vorwortes noch ein Hinweis zum Urheberrecht: Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE sowie Adobe. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.
1 System langsam bzw. ohne Reaktion
Immer wieder kommt es vor, dass sich Anwender im Dialogbetrieb über lange Antwortzeiten beschweren oder gar Meldungen einreichen, dass systemseitig gar keine Reaktion mehr erfolgt. Im Folgenden sollen Werkzeuge vorgestellt werden, mit deren Hilfe Sie u.a. prüfen können, ob nur einzelne Benutzer oder alle Anwender vom Problem betroffen sind.
Wir wollen uns in diesem Kapitel auf die für Anwender besonders wichtige Dialogverarbeitung konzentrieren; Informationen zu Problemen mit der Hintergrundverarbeitung finden Sie in Kapitel 2, zu Verbuchungsproblemen in Kapitel 3.
1.1 Dialogworkprozesse und Dialogschritte
Eine Dialoganwendung (SAP-Transaktion) besteht prinzipiell aus einer Folge von Masken (Dynpros), die für die Bearbeitung einer bestimmten Aufgabe durchlaufen werden müssen. Gestartet wird eine Dialoganwendung im Normalfall über einen Transaktionscode. Mit dem Start wird das erste der Transaktion zugeordnete Dynpro geöffnet. Abhängig von den Eingaben des Anwenders und der Ablauflogik des Dynpros wird anschließend das Folgedynpro geladen. Eine mögliche Dynprofolge zeigt Abbildung 1.1.
Jedem Dynpro sind zwei Verarbeitungsblöcke zugeordnet:
1. Process before Output, PBO wird im Applikationsserver ausgeführt, bevor das Dynpro zur Anzeige z.B. an die SAP GUI gesendet wird, und
2. Process after Input, PAI wird verarbeitet, wenn der Anwender die Eingabe von