In diesem Kapitel werden die unterschiedlichen Prozesstypen, die der SAP NetWeaver AS ABAP zur Verfügung stellt, behandelt. Die Eigenschaften der Prozesstypen werden erläu- tert, und es werden die Konzepte vorgestellt, nach denen die einzelnen Prozesse arbeiten. 2 Prozesskonzept des SAP NetWeaver Application Servers ABAP Im Folgenden werden Ihnen die grundlegenden Prozesstypen eines SAP Netweaver AS ABAP und ihre Architektur vorgestellt. Es wird erläutert, weshalb es die unterschiedlichen Prozesstypen gibt und welche Aufgaben sie im Einzelnen übernehmen. Jeder Unterab- schnitt dieses Kapitels beschreibt einen speziellen Prozesstyp. Am Ende jedes Abschnitts finden Sie Tipps und häufig gestellte Fragen. Als Abschluss dieses umfangreichen Kapitels finden Sie außerdem einen kurzen Einblick in die Funktionsweise des Virtual Machine Containers (VMC), der selbst jedoch keinen eigenständigen Pro- zesstyp darstellt. 2.1 Dialogverarbeitung Die Dialogverarbeitung findet hauptsächlich innerhalb der Dialog- Workprozesse statt. Diese stellen in einem OLTP-System normaler- weise den größten Anteil an Workprozessen. Für eine eigenständige Instanz sind neben dem Dispatcher-Prozess mindestens zwei Dialog- Workprozesse notwendig. Während alle in den folgenden Abschnitten beschriebenen Prozesse Spezialaufgaben, wie zum Beispiel Hintergrundverarbeitung, Dru- cken oder Verbuchen übernehmen, wird durch Dialog-Workpro- zesse die Grundlast aller anstehenden Aufgaben bewältigt. Alle Anfragen, die durch einen Benutzer online an SAP NetWeaver 65 2 Prozesskonzept des SAP NetWeaver Application Servers ABAP gestellt werden, werden durch einen Dialog-Workprozess abgearbei- tet. Eventuell wird, abhängig von der Anfrage, ein geeigneter Spezi- alprozess, zum Beispiel der Verbuchungsprozess, im Bedarfsfall mit eingebunden. Die folgenden Komponenten sind an der Abarbeitung einer Dialoganfrage beteiligt (siehe Abbildung 2.1): An Dialogabfrage (cid:1) der Dispatcher-Workprozess (zentraler Steuerungsprozess) beteiligte (cid:1) gegebenenfalls die Dispatcher-Queue (Warteschlange des Dispat- Komponenten cher-Prozesses) (cid:1) ein Dialog-Workprozess (cid:1) Komponenten im Shared Memory des Applikationsservers (zum Beispiel Puffer) Frontend: SAP GUI Dispatcher- Dispatcher Request- Queue Dialogworkprozess 1 Dialogworkprozess 2 Dialogworkprozess n Dynpro- Dynpro- Dynpro- in Prozessor in Prozessor in Prozessor te te te rn rn rn er Sp PrAoBzeAsPs-or HTaansdkler er Sp PrAoBzeAsPs-or HTaansdkler er Sp PrAoBzeAsPs-or HTaansdkler e e e iche Datenbank- iche Datenbank- iche Datenbank- r schnittstelle r Schnittstelle r schnittstelle Pufferzugriffe Roll-in Roll-out Shared Memory Applikationspuffer Roll-Bereich (cid:127)Fabrikkalender User--Kontext (cid:127)Dynpros User-Kontext (cid:127)ABAP-Programme Roll-Datei (cid:127)Tabellen User-Kontext (cid:127)…. Abbildung 2.1 Beteiligte Komponenten an einem Dialogschritt Wird eine Dialoganfrage durch den Dispatcher an einen Dialog- Workprozess weitergeleitet, so übernimmt im Dialogprozess der Task Handler die Anfrage. Er entscheidet, ob der Dynpro- oder ABAP-Prozessor aktiviert werden soll und ob gegebenenfalls eine Datenbankabfrage über die Datenbankschnittstelle auszuführen ist. Außerdem übernimmt der Task Handler Roll-in und Roll-out des 66 Hintergrundverarbeitung 2.2 Benutzerkontextes. Im Benutzerkontext befinden sich zum Beispiel Berechtigungen und Variablenwerte. Überdies hat der Workprozess Zugriff auf unterschiedliche Speicher- Prozesslokaler und prozessübergrei- bereiche. Man unterscheidet Speicherbereiche, die dem Dialog- fender Speicher Workprozess exklusiv zur Verfügung stehen (prozesslokaler Speicher) und Speicherbereiche, die von allen Workprozessen gemeinsam genutzt werden können (prozessübergreifender Speicher). Im exklusiv genutzten Speicher werden modusspezifische Daten, die länger als für die Dauer eines Arbeitsschrittes aufbewahrt werden, abgelegt. Diese Daten werden dem Prozess zu Beginn eines Dialogschrittes automatisch verfügbar gemacht (hineingerollt) und am Ende des Dia- logschrittes für den Prozess gesichert (herausgerollt). Es handelt sich hierbei um Daten, die den Benutzer charakterisieren (User-Kontext), wie zum Beispiel Berechtigungen, Verwaltungsinformationen und weitere Daten für den ABAP- und Dialogprozessor, die in den bereits durchgeführten Dialogschritten der laufenden Transaktion gesam- melt wurden. Im gemeinsam genutzten Speicherbereich liegen diverse SAP-Puffer, wie zum Beispiel Fabrikkalender, Dynpro-, Programm- und Tabel- lenpuffer. 2.2 Hintergrundverarbeitung Neben dem Dialogbetrieb können Reports in einem SAP-System auch im Hintergrund verarbeitet werden. Dies ist insbesondere für lang laufende Programme interessant, die keine interaktiven Einga- ben erfordern. In diesem Kapitel steht das Management der Hinter- grundjobs im Mittelpunkt. Es wird gezeigt, wie man Hintergrund- jobs zeit- und ereignisgesteuert einplant und die Ablaufprotokolle auswertet. 2.2.1 Konzepte Grundsätzlich können alle Programme, die keinen expliziten Benut- zerdialog erfordern, auch im Hintergrund ausgeführt werden. Sinn- voll ist dies besonders dann, wenn der abzuwickelnde Vorgang zeit- und ressourcenintensiv ist und daher in eine lastarme Zeit verlegt werden soll. Eine Online-Ausführung würde über den gesamten 67 2 Prozesskonzept des SAP NetWeaver Application Servers ABAP Zeitraum einen Dialogprozess blockieren und so andere Dialogbe- nutzer indirekt behindern. Um zu verhindern, dass Benutzer lang laufende Reports interaktiv ausführen, kann für die Dialogschritte eine Laufzeitbegrenzung fest- gelegt werden. Standardmäßig liegt diese Grenze bei 600 Sekunden. Nach Ablauf dieser Zeitspanne bricht die Verarbeitung ab. Im Sys- temprofil ist diese Grenze über den Parameter rdisp/max_wprun_ time einstellbar. Die Verarbeitung im Hintergrund ist nicht in dieser Form eingeschränkt. Die Automatisierung periodisch zu erledigender Routinearbeiten ist eine weitere, offensichtliche Anwendungsmöglichkeit. Für die Hin- tergrundverarbeitung stellt das SAP-System den Hintergrundservice mit seinen Hintergrund-Workprozessen (auch einfach nur Back- ground- oder Batch-Prozesse genannt) zur Verfügung. Im Gegensatz zur Dialogverarbeitung, bei der jeder LUW (Logical Unit of Work – siehe Abschnitt 1.5, »Applikationsebene«) der nächste freie Dialog- prozess vom Dispatcher zugeordnet wird, besteht bei der Hinter- grundverarbeitung während der gesamten Ausführung eine feste Verbindung mit genau einem Background-Prozess. Den Startzeit- punkt des Hintergrundjobs plant der Systemadministrator bezie- hungsweise der Benutzer selbst. Er kann dabei zwischen Zeit- und Ereignissteuerung wählen. Zeitgesteuerter Bei der zeitgesteuerten Vorgehensweise wird bei der Einplanung des Job-Scheduler Jobs ein Startzeitpunkt definiert. Für jede Instanz des SAP-Systems, auf der Hintergrund-Workprozesse konfiguriert sind, ist ein zeitge- steuerter Job-Scheduler aktiv, der in definierten Zeitintervallen über- prüft, ob Hintergrundjobs zur Verarbeitung anstehen. Die Beschrei- bungen der anstehenden Jobs werden in zentralen Datenbanktabel- len gehalten. Beim zeitgesteuerten Job-Scheduler handelt es sich um ein ABAP-Programm, das innerhalb eines ausgewählten Dialogpro- zesses interpretiert und abgearbeitet wird. Die Auswahl des speziel- len Dialogprozesses wird beim Start des SAP-Systems automatisch vom Scheduler vorgenommen. Standardmäßig ist das Zeitintervall, nach dem der zeitgesteuerte Job-Scheduler aktiv wird, auf 60 Sekun- den konfiguriert. Der Administrator kann dieses Zeitintervall mit- hilfe des Parameters rdisp/btctime im Instanzprofil beliebig anpas- sen. Aufgrund des Zeitabstandes zwischen zwei Job-Scheduler-Läu- 68 Hintergrundverarbeitung 2.2 fen kann es daher Verzögerungen beim Start eines Jobs geben. Man würde das Zeitintervall also verkleinern, wenn die Verzögerungen zu groß für die eigenen Bedürfnisse sind. Ist umgekehrt die mögliche Verzögerung beim Start eines Jobs nicht ausschlaggebend, so kann man das Zeitintervall vergrößern. Die damit verbundene Verringe- rung der Häufigkeit von Läufen des zeitgesteuerten Job-Schedulers hat allerdings kaum Einfluss auf die Systemlast. Im Gegensatz zum zeitgesteuerten Job-Scheduler reagiert der ereig- Ereignis- gesteuerter Job- nisgesteuerte Job-Scheduler auf Events. Nach dem Auslösen eines Scheduler Events (siehe weiter unten) veranlasst er den Start von Hintergrund- jobs, die mit dem Eintreten des Ereignisses anlaufen sollen. Der ereignisgesteuerte Job-Scheduler wird ebenfalls durch einen Dialog- Workprozess abgearbeitet; die zu verwendende Instanz legen Sie über den Parameter rdisp/btcname = <Rechnername> im Standard- profil des SAP-Systems (DEFAULT.PFL) fest. Parameter zur Dialog- bzw. Hintergrundverarbeitung (cid:1) rdisp/max_wprun_time: Zeit in Sekunden, nach der ein Dialogschritt wegen Laufzeitüberschreitung angebrochen wird. (cid:1) rdisp/btctime: Zeitintervall des Batch-Schedulers (cid:1) rdisp/btcnam: Instanz für Batch-Verarbeitung Die Ereignisse, auf die reagiert werden soll, müssen zunächst im Systemereignisse SAP-System als sogenannte Events definiert sein. Standardmäßig werden mit dem SAP-System bereits eine Reihe von Ereignissen aus- geliefert. Eine Übersicht erhalten Sie über die Eventpflege (SM62). Die bereits zum Lieferumfang gehörenden Ereignisse nennt man auch Systemereignisse. Sie werden häufig für die interne SAP-Steue- rung benutzt, können jedoch auch von den Benutzern für eigene Zwecke verwendet werden. Darüber hinaus können die Benutzer über den gleichen Menüpfad Benutzerereignisse neue eigene Ereignisse, sogenannte Benutzerereignisse, definieren. Die Ereignisdefinition ist zunächst nicht mehr als ein Eintrag in eine Tabelle. Ein Ereignis kann auf verschiedene Weise ausgelöst werden: Auslösen (cid:1) zu Testzwecken manuell über das Kontextmenü zu einem Event in der Eventpflege (SM62) (rechte Maustaste (cid:1) Event (cid:1) auslösen) 69 2 Prozesskonzept des SAP NetWeaver Application Servers ABAP (cid:1) durch Benutzung des Funktionsbausteins BP_EVENT_RAISE aus einem ABAP-Programm innerhalb des SAP-Systems (cid:1) mithilfe des externen Programms sapevt sapevt Aus einem externen Programm heraus kann mittels sapevt ein Ereignis in einem SAP-System ausgelöst werden. sapevt ist im SAP- Standard-Verzeichnis für ausführbare Programme (siehe Kapitel 1, »Die Architektur des SAP NetWeaver Application Servers ABAP«) verfügbar. Es wird wie folgt verwendet: sapevt <EventID> [-p <Parameter>] [-t] pf=<Profil>|name=<R/3-Systemname> nr=<R/3-Systemnummer> Die Option -t veranlasst das Schreiben einer Protokolldatei dev_evt im Aufrufverzeichnis von sapevt. Mithilfe der Option -p kann ein Parameter, der ein SAP-Modul bestimmt (zum Beispiel Financials, FI), übergeben werden. Damit wird eine Zuordnung der Ereignisse zu den Arbeitsgebieten erreicht. Diese Zuordnung hat lediglich beschreibenden Charakter. Beispielsweise löst der Aufruf sapevt SAP_TRIGGER_RDDIMPDP name=QO1 nr=00 im SAP-System QO1 das Ereignis SAP_TRIGGER_RDDIMPDP aus. tp Innerhalb des SAP-Systems wird die Ereignissteuerung zum Beispiel beim Transport von Objekten zwischen SAP-Systemen angewendet. Die mithilfe des Transportsteuerungsprogramms tp durchgeführten Transporte verlaufen in mehreren Phasen. Über den eigentlichen Datenimport hinaus müssen die einzelnen Objekte häufig auch gene- riert beziehungsweise aktiviert werden. Daher löst das Programm tp nach Abschluss des Datenimports das Ereignis SAP_TRIGGER_ RDDIMPDP aus. In einem SAP-System ist stets der Job RDDIMPDP in Abhängigkeit von diesem Ereignis eingeplant. Tritt das Ereignis SAP_TRIGGER_RDDIMPDP ein, so wird automatisch der Job RDDIMPDP im Hintergrund ausgeführt. Die Verwendung dieser Technik erlaubt eine größere Flexibilität. Nicht immer ist es zeitlich vorhersehbar, wann Aktionen abgeschlos- sen sind, und eine Abhängigkeit zwischen Hintergrundjobs ist damit kaum herstellbar. Die Ereignissteuerung eröffnet dabei neue Mög- lichkeiten. 70 Hintergrundverarbeitung 2.2 2.2.2 Definition von Hintergrundjobs Für das Einrichten von Hintergrundjobs nutzen Sie die Jobdefinition (SM36) (siehe Abbildung 2.2). Abbildung 2.2 Jobdefinition Häufig ist die Planung von Hintergrundjobs auch direkt in die Anwen- dungen integriert, zum Beispiel beim Kopieren von Mandanten oder beim Benutzerstammabgleich. Je nach Anwendung kann das Erschei- nungsbild der Bildschirmmasken zur Erfassung der Jobdaten differie- ren; oder bestimmte Jobeigenschaften werden bereits von der Anwen- dung vorbelegt. Die in diesem Kapitel beschriebenen Grundsätze und Möglichkeiten der Hintergrundverarbeitung bleiben jedoch erhalten und können auf diese Spezialfälle übertragen werden. Die Definition von Hintergrundjobs setzt sich aus drei wesentlichen Aspekten zusammen: (cid:1) allgemeine Angaben wie Jobname, Jobklasse und Zielrechner (cid:1) Angaben zum Startzeitpunkt beziehungsweise zur Zuordnung eines auslösenden Ereignisses (cid:1) Auflistung der Verarbeitungsschritte 71 2 Prozesskonzept des SAP NetWeaver Application Servers ABAP Allgemeine Den Ausgangspunkt für die Definition eines Hintergrundjobs bilden Angaben die allgemeinen Angaben (siehe Abbildung 2.2). Der Jobname sollte möglichst aussagekräftig sein. wählen; denn alle Protokolle und Übersichten, die später ausgewertet werden müssen, basieren auf diesem Jobnamen. Aus technischer Sicht ist der Name unerheblich; er braucht auch nicht eindeutig zu sein. Jobklasse Die Priorität bei der Ausführung eines Jobs wird zunächst über die Zuordnung des Jobs zu einer Jobklasse gesteuert. Man unterscheidet die Jobklassen: (cid:1) A höchste Priorität Jobs, die die Funktionstüchtigkeit des SAP NetWeaver-Systems gewährleisten und zeitkritisch sind. (cid:1) B mittlere Priorität periodische Jobs, die die Funktionstüchtigkeit des SAP Netwea- ver-Systems gewährleisten. (cid:1) C normale Priorität die für SAP-Anwender übliche Jobklasse. Die Vergabe der Systemressourcen erfolgt anhand dieser Jobklassen. Stehen häufig sehr viele Jobs der Klasse C zur Verarbeitung an, sodass auch Jobs der Klassen A und B auf die Freigabe von Back- ground-Prozessen warten müssen, kann der Systemadministrator für die Verarbeitung von Jobs der Klasse A mittels der Betriebsarten- pflege (RZ04) eine Anzahl n an Background-Prozessen freihalten. Durch diese Konfiguration wird sichergestellt, dass stets n Back- ground-Prozesse zur Ausführung von Jobs der Klasse A bereitstehen. Jobs der Klassen B und C müssen mit der Abarbeitung warten, bis mindestens n+1 Prozesse verfügbar sind. Die Konfiguration wird in Abschnitt 7.1, »Profilpflege«, im Rahmen der Betriebsartenpflege beschrieben. Zielserver In einem verteilten SAP-System können Sie die Ausführung eines Jobs einer beliebigen SAP-Instanz mit Background-Service zuweisen. Diese Instanz wird im Kontext der Hintergrundverarbeitung als Ziel- server bezeichnet. Verzichtet man auf die explizite Angabe eines Ziel- servers, so wird zum Ausführungszeitpunkt der erste verfügbare Background-Prozess ausgewählt. Die Prioritäten in der Abarbeitung des Auftrags auf einem definier- ten Hintergrundserver sind wie folgt: 72 Hintergrundverarbeitung 2.2 1. Jobklasse A, Zielserver angegeben 2. Jobklasse A, kein Zielserver angegeben 3. Jobklasse B, Zielserver angegeben 4. Jobklasse B, kein Zielserver angegeben 5. Jobklasse C, Zielserver angegeben 6. Jobklasse C, kein Zielserver angegeben Sind die anstehenden Jobs nach den oben stehenden Kriterien gleichberechtigt, so wird die Wartezeit herangezogen. Wird ein Zielserver definiert, so ist diese Angabe bindend. Ist er nicht verfügbar, wenn der Job gestartet werden soll, so übernimmt kein Hintergrund-Workprozess einer anderen Instanz die Abarbei- tung. Der Job bleibt in der Queue stehen, bis der definierte Zielser- ver wieder die Arbeit aufnimmt oder die Verarbeitung explizit auf einen anderen Server umgezogen wird. Die von einem ABAP-Programm generierte Ausgabe wird im SAP- Spool-System als Spool-Auftrag abgelegt. Mithilfe von Spool-Listen- Empfängern kann die Ausgabe einem Benutzer zugeschickt wer- den. Auf diese Weise können zum Beispiel Administration und Ergebnisauswertung eines Hintergrundjobs von verschiedenen Per- sonen wahrgenommen werden. Da die Ausgabe recht umfangreich sein kann, sollten Sie bei der Verwendung dieser Option vorsichtig vorgehen. Aus Performancegründen ist zum Beispiel die Länge einer über SAPoffice versendeten Ausgabeliste auf 1000 Zeilen beschränkt. In der Step-Definition werden Angaben zu den Druck- parametern selbst gemacht. In einem weiteren Schritt müssen die Parameter gewählt werden, die Startzeitpunkt den Startzeitpunkt bestimmen. Hierzu wählen Sie den Button Start- termin aus dem Eingangsbildschirm zur Jobdefinition. Der Startter- min kann durch eine Zeitangabe festgelegt oder ereignisgesteuert definiert werden (siehe Abbildung 2.3). Die Zeitangabe und die verwendete Zeitzone basieren auf der Sys- temzeit. Die zeitgesteuerte Einplanung von Jobs bietet neben der direkten Angabe des Startzeitpunkts auch die Möglichkeit der perio- dischen Einplanung, wie sie zum Beispiel bei regelmäßigen Auswer- tungen oder den weiter unten beschriebenen Pflegejobs nützlich sein kann. Dabei können die Zeitabstände beliebig gewählt werden: 73 2 Prozesskonzept des SAP NetWeaver Application Servers ABAP im Minutenrhythmus, stündlich, täglich, wöchentlich usw. Über die Funktion Einschränkungen können Abweichungen von der üblichen Periode definiert werden, was zum Beispiel für die Berücksichtigung von Feiertagen hinsichtlich des gültigen Fabrikkalenders günstig ist. Für zeitsensitive Jobs besteht die Möglichkeit, einen Zeitpunkt zu definieren, nach dessen Verstreichen sie keinesfalls mehr gestartet werden sollen. Abbildung 2.3 Starttermin festlegen Startereignis Sie können anstatt einer zeitlichen Steuerung auch ein definiertes Ereignis als Trigger festlegen. Insbesondere sind auch der Betriebsar- tenwechsel und das Jobende als Events definiert, sodass ein Hinter- grundjob auch als Folgejob gestartet werden kann. Mit der Option Start statusabhängig können Sie den Start des Jobs von der erfolg- reichen Beendigung des Vorgängerjobs abhängig machen. Bricht der Vorgängerjob ab, so wird der abhängige Nachfolgejob auch in den Status abgebrochen versetzt und nicht ausgeführt. Können Jobs mit Starttermin Nach Job, Nach Ereignis oder Bei Betriebsart nicht gestartet werden, weil bei Eintritt des erwarteten 74