Manfred Sprenger - Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration

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.

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 Daten durch Auslösen der gewünschten Folgeaktion abschließt.

Abbildung 1.1: Dynprofolge und Dialogschritt

Ein Dialogschritt umfasst sowohl den PAI-Block des aktuell bearbeiteten Dynpros als auch den PBO-Block des Folgedynpros. Für die Ausführung genau eines solchen Dialogschritts wird dem Anwender ein Dialogworkprozess zugeordnet. Ist der Dialogschritt beendet, gibt der Anwender den Workprozess wieder frei, und dieser kann von einem anderen Anwender für die Ausführung eines Dialogschritts eingesetzt werden. Prinzipiell spielt es dabei keine Rolle, wie lange ein Dialogschritt dauert. Wenn ein Anwender z.B. eine umfangreiche Liste erstellt, kann es durchaus vorkommen, dass die Bearbeitung des entsprechenden Dialogschritts mehrere Minuten (wenn nicht sogar Stunden) in Anspruch nimmt. Entsprechend lange ist dann der zugeordnete Dialogworkprozess für andere Anwender blockiert.

Da Workprozesse mitunter erhebliche Systemressourcen, insbesondere Hauptspeicher, binden können, steht nicht jedem angemeldeten Benutzer ein eigener Dialogworkprozess zur Bearbeitung zur Verfügung. Vielmehr verteilt der Dispatcher einer SAP-Instanz die zu verarbeitenden Dialogschritte nacheinander auf die vorhandenen Dialogworkprozesse.

Verhältnis von Anwender zu Dialogworkprozess

Typisch ist ein Verhältnis zwischen Anzahl angemeldeter Anwender und verfügbarer Dialogworkprozesse von etwa 10:1. Geht man z.B. davon aus, dass ein Anwender für die Eingabe der Daten in ein Dynpro zehn Sekunden benötigt, der Dialogschritt selbst etwa eine Sekunde läuft, kann man also im Mittel annehmen, dass, sofern nicht alle Anfragen gleichzeitig erfolgen, immer ein Dialogworkprozess zur Verfügung steht.

Probleme entstehen eigentlich immer dann, wenn im Dialogbetrieb Anwendungen gestartet werden, deren Dialogschritte weit über das übliche Maß hinaus Zeit und damit Dialogworkprozesse beanspruchen. Die Folge ist, dass die noch verfügbaren freien Workprozesse nicht mehr ausreichen, um die anstehenden Dialogschritte der übrigen Anwender mit angemessener Wartezeit zu bearbeiten. Im Extremfall kann das System, wenn gar keine freien Dialogprozesse mehr vorhanden sind, temporär zum Stillstand kommen.

In den folgenden Abschnitten wollen wir die Werkzeuge näher betrachten, die eine Überwachung der Workprozesse ermöglichen, um das Beschriebene zu verhindern.

Eine Übersicht über die Workprozesse einer Instanz liefert die Transaktion SM50 , während SM66 die Workprozesse aller Instanzen eines SAP-Systems zeigt. Wir beschränken uns in diesem Abschnitt auf die Transaktion SM50 , weil diese umfangreichere Informationen und Verwaltungsfunktionen anbietet als SM66 (siehe Abbildung 1.2).

Abbildung 1.2: Workprozess – Übersicht

Es werden u.a. folgende Informationen ausgegeben:

Fortlaufende Nummer des Workprozesses (Nr): Die Nummer kann verwendet werden, um die für den Workprozess relevanten Tracedateien zu ermitteln (Details siehe Abschnitt 11.3)

Workprozess-Typ:

DIA = Dialogworkprozess

BTC = Batchworkprozess (siehe Abschnitt 2.1)

UPD/UPD2 = Verbuchungsworkprozess (siehe Abschnitt 3.3)

SPO = Spoolworkprozess (siehe Abschnitt 7.1)

Workprozess-Status (WP-Status) (siehe Tabelle 1.1)

Zusatzinformation zum Status »hält« (Info Hält)

Aktuelle Bearbeitungsdauer (B.-Dauer)

Programm, welches gerade vom WP ausgeführt wird

Benutzer-ID, dessen Auftrag ausgeführt wird

Aktuell im Workprozess ausgeführte Aktion

Die wohl wichtigste Angabe ist diejenige des »Status«. Tabelle 1.1 zeigt Ihnen mögliche Ausprägungen.

Tabelle 1.1: Die häufigsten Workprozess-Status

Es sollte schnell klar sein, dass die Dialogantwortzeiten des Systems ungünstig ausfallen können, wenn, wie in Abbildung 1.2 gezeigt, nur wenige Dialogprozesse im Status »wartet« zur Verfügung stehen und für die laufenden Prozesse eine Bearbeitungszeit von mehreren Sekunden angezeigt wird. Lediglich wenn ein Dialogworkprozess mit Status »wartet« vorhanden ist, kann ein Dialogschritt ohne Wartezeit vom Anwender bearbeitet werden. Andernfalls beginnt die Bearbeitung des Schritts erst mit dem Freiwerden eines Dialogworkprozesses.

Die Transaktion SM50 gibt Ihnen Auskunft über die Auslastung der Workprozesse aktuell und in den zurückliegenden 15 Minuten (siehe Abbildung 1.3).