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

Abbildung 2.11 zeigt das Job-Log zu einem regelmäßig abbrechenden Job.

Abbildung 2.11: Jobabbruch aufgrund fehlender Variante

Wie in Abschnitt 2.1.1 geschildert, muss jedem Job-Step, der durch ein ABAP-Programm mit Selektionsdynpro realisiert wird, eine Variante zugeordnet werden. Fehlt diese zum Zeitpunkt der Jobausführung, bricht der Job sofort ab. Varianten zu Reports, die Bestandteile eines Job-Steps sind, können von einem Anwender nicht einfach gelöscht werden. Doch manchmal verschwinden sie unvermutet und ganz ohne manuelles Zutun. Dazu ein Beispiel: Wird ein Job mit der Transaktion SA38 und der Funktion »Im Hintergrund ausführen« eingeplant, ist die Angabe einer explizit definierten Variante nicht erforderlich. Vielmehr generiert das System in diesem Fall automatisch eine Variante, die den aktuellen Inhalt des Selektionsbildes enthält. Sie erkennen solche Varianten an dem Und-Zeichen (»&«) zu Beginn des Namens. Sie sind nicht über die Transaktion SE38 änderbar und eigentlich nur zur einmaligen Nutzung für einen Job vorgesehen. Aber sie können eben verlorengehen, und zwar z.B. durch Mandantenkopien. Nähere Hinweise zu Problemen mit den Und-Varianten finden Sie im SAP-Supportsystem unter dem Stichwort »Variant does not exist«.

Um das Problem zu beseitigen, müssen Sie eine geeignete neue Variante definieren und diese in den Job-Step eintragen.

Wenn die Variante noch nicht gelöscht wurde, können Sie die Werte, die Sie in die neue Variante eintragen müssen, bestimmen, indem Sie sich zunächst die Step-Liste zum Job ( ) und anschließend die Variante zum Step ( ) anzeigen lassen. Die Werte für die Selektionskriterien finden Sie dann in der Variantendefinition ( ) (siehe Abbildung 2.12).

Abbildung 2.12: Variante zu einem Step anzeigen

Jobs können auch abbrechen, weil eine Variante nicht mehr gültig ist. Dies kann z.B. dadurch passieren, dass das Selektionsdynpro des ABAP-Programms grundlegend geändert wurde, so etwa durch Hinzufügen weiterer obligatorischer Selektionsparameter. Werden daraufhin die bereits existierenden Varianten nicht angepasst, fehlen ihnen die notwendigen Informationen für die Pflichtparameter. Ein Job mit einer nicht aktualisierten Variante bricht daher ab. Abbildung 2.13 zeigt die im Jobfehler eingetragene Fehlermeldung.

Abbildung 2.13: Jobabbruch bei ungültiger Variante

Bei der Definition eines Jobs müssen Sie für jeden Step die Kennung des Benutzers angeben, in dessen Kontext der Step ausgeführt werden soll.

Benutzerkontext

Im Benutzerkontext sind beispielsweise Informationen zu den Berechtigungen eines Benutzers wie auch Werte für »Benutzerparameter« und »Defaultdrucker« abgelegt (siehe Transaktion SU3 ).

Bei der Realisierung des Steps erfolgt ein implizites Login des Benutzers, d.h., der Step wird z.B. mit den Berechtigungen des Benutzers ausgeführt. Ist dessen Anmeldung nicht möglich, weil der Benutzer gesperrt ist oder zwischenzeitlich gelöscht wurde, ist der Step nicht ausführbar und der Job bricht ab. Dies trifft auch zu, wenn im Benutzerstammsatz ein abgelaufener Gültigkeitszeitraum vermerkt ist. Im Job-Log wird eine passende Meldung eingetragen (siehe Abbildung 2.14).

Abbildung 2.14: Jobabbruch bei gesperrtem/gelöschtem Benutzer

Jobs mit gelöschten Benutzern identifizieren

Mithilfe des Reports BTCAUX09 können Sie die Jobs bestimmen, die als Step-User einen gelöschten oder gesperrten Benutzer verwenden. Der Report erlaubt es Ihnen, für die gefundenen Jobs bei Bedarf die Einplanung zurückzunehmen. Dieser Report findet jedoch in der aktuellen Version keine Jobs, die einen ungesperrten Benutzer verwenden, für den der Gültigkeitszeitraum abgelaufen ist.

Benutzer vom Typ »System«

Verwenden Sie für die Ausführung von Job-Steps nach Möglichkeit Benutzer vom Typ »System«. Für sie gelten beispielsweise nicht die Regeln hinsichtlich der Gültigkeitsdauer eines Kennworts. Da mit einem solchen Benutzer eine Anmeldung im Dialog nicht möglich ist, besteht auch keine Gefahr, dass er z.B. durch wiederholte Falschanmeldungen gesperrt wird.

Einem Job kann zusätzlich zum geplanten Starttermin auch ein Spätester Starttermin zugeordnet werden. Auf diese Weise können Sie z.B. erreichen, dass ein Job – aufgrund von zum geplanten Startzeitpunkt nicht ausreichend verfügbaren Hintergrundprozessen – erst am Folgetag gestartet wird und dann u.U. auf die Daten des falschen Tages zugreift, weil etwa in der verwendeten Variante ein Selektionskriterium wie »Buchungsdatum = Aktuelles Datum« hinterlegt ist. Abbildung 2.15 zeigt das Beispiel eines Jobs mit einer Angabe im Feld Spätester Starttermin.

Abbildung 2.15: Job mit »Spätester Starttermin«

Im konkreten Fall sollte der Job um 05:00 Uhr gestartet werden. Aufgrund von Wartungsarbeiten wurde das System jedoch noch vor dem Starttermin gestoppt und erst nach dem spätesten Starttermin wieder gestartet. Das Überschreiten des spätesten Starttermins führte dazu, dass der Job vom Job-Scheduler nicht ausgeführt, sondern sein Status sofort auf »abgebrochen« gesetzt wurde. Abbildung 2.16 zeigt das zum Job gehörige Log.

Abbildung 2.16: Spätester Starttermin überschritten