Verbuchung im SAP-System (BC-CST-UP) HELP.BCCSTUP Release 4.6C
SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden. Die von SAP AG oder deren Vertriebsfirmen angebotenen Software-Produkte können Software- Komponenten auch anderer Software-Hersteller enthalten. Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint und SQL Server sind eingetragene Marken der Microsoft Corporation. IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390, AS/400, OS/390 und OS/400 sind eingetragene Marken der IBM Corporation. ORACLE ist eine eingetragene Marke der ORACLE Corporation. INFORMIX -OnLine for SAP und Informix Dynamic Server TM sind eingetragene Marken der Informix Software Incorporated. UNIX, X/Open, OSF/1 und Motif sind eingetragene Marken der Open Group. HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des W3C, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA ist eine eingetragene Marke der Sun Microsystems, Inc. JAVASCRIPT ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der Lizenz der von Netscape entwickelten und implementierten Technologie. SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mysap.com Logo und mysap.com sind Marken oder eingetragene Marken der SAP AG in Deutschland und vielen anderen Ländern weltweit. Alle anderen Produkte sind Marken oder eingetragene Marken der jeweiligen Firmen. 2 April 2001
SAP AG Symbole Symbol Bedeutung Achtung Beispiel Hinweis Empfehlung Syntax April 2001 3
SAP AG Inhalt... 6 Funktionsweise der Verbuchung...7 Verbuchungsauftrag...9 Sammellauf...12 Der Verbuchungsprozeß...13 Verbuchungen bündeln...16 Synchrones und asynchrones Verbuchen...17 Die wichtigsten Verbuchungsstatus...18 Fehlerbehandlung und Datenkonsistenz...21 Verteilte Verarbeitung von Verbuchungen...22 V1- und V2-Verbuchungsmodule...23 Verbuchungs-Dispatching mit Lastausgleich...24 Hauptsystemprofilparameter für die Verbuchung...27 Weitere Systemprofilparameter...30 Meldung von Verbuchungsproblemen...32 Automatischer Verbuchungsstopp bei Datenbankproblemen...33 Die Verbuchungsverwaltung...34 Verbuchungen auswählen und anzeigen...36 Verbuchungskopf anzeigen...38 Verbuchungsmodule anzeigen...40 Abgebrochene Verbuchungen analysieren...41 Abgebrochene Verbuchungen testen...42 Verbuchungen manuell verarbeiten...43 Verbuchungsstatus zurücksetzen...44 Verbuchungssätze löschen...45 Verbuchungssätze reorganisieren...46 Verbuchungsgruppen konfigurieren...47 Verbuchungsstatistiken anzeigen und zurücksetzen...50 Server anzeigen...53 Die Verbucheradministration (Transaktion sm14)...54 Registerkarte Verbuchung...56 Registerkarte Server...57 Registerkarte Servergruppen...58 Registerkarte Parameter...59 Verbuchung überwachen...60 Verbuchungsstatus überprüfen...62 Verwendung des Alert Monitors...63 Verbuchung de- und reaktivieren...64 Verbuchungsfehler analysieren und beheben...66 Abgebrochene Verbuchungen wiederholen...69 Benutzer, Transaktion und Daten von Verbuchungen anzeigen...71 Problemtypen...72 4 April 2001
SAP AG April 2001 5
SAP AG Einsatzmöglichkeiten Im SAP-System wird ein betriebswirtschaftlicher Ablauf durch eine SAP-Transaktion, die mehrere Bildwechsel enthalten kann, abgebildet (z. B. das Anlegen eines Auftrags). Die Datenänderungen, die dieser Ablauf bewirkt, sollen komplett oder überhaupt nicht in der Datenbank ausgeführt werden. Wird der Vorgang also während der Transaktion abgebrochen oder tritt ein Fehler auf, soll die Transaktion überhaupt keine Datenbankänderung bewirken. Dies bewerkstelligt das SAP-Verbuchungssystem, das im folgenden beschrieben wird. Das Verbuchungssystem bietet außerdem erhöhte Sicherheit, Performance und Wiederherstellbarkeit bei der Durchführung von Datenbankänderungen. Integration Die Verbuchung hängt eng mit dem R/3-Sperrkonzept zusammen, das in der Dokumentation Das R/3 Sperrkonzept [Extern] beschrieben ist. Weitere Dokumentation zur Verbuchung finden Sie unter Techniken der Verbuchung [Extern] in der ABAP-Dokumentation. Hier wird erklärt, wie der Anwendungsprogrammierer durch ABAP- Befehle die Verbuchungslogik steuern kann. Funktionsumfang Das Verbuchungssystem dient zur Entlastung der SAP-Transaktionen bei den 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 in einer SAP-Transaktion und in der Datenbank verursacht werden. Wie die Verbuchung im SAP-System funktioniert, erfahren Sie im Kapitel Funktionsweise der Verbuchung [Seite 7]. Ferner enthält diese Dokumentation Abschnitte über die Verbuchungsverwaltung [Seite 34] (Transaktion sm13) das Überwachen der Verbuchung [Seite 60] das Analysieren und Beheben von Verbuchungsfehlern [Seite 66] 6 April 2001
SAP AG Funktionsweise der Verbuchung Funktionsweise der Verbuchung Die folgende Grafik zeigt den Zusammenhang zwischen R/3-System und Datenbank bei der Ausführung einer SAP-Transaktion und illustriert den Unterschied zwischen Datenbank-LUW (Logical Unit of Work) und SAP-LUW. SAP LUW Dialogtransaktion DB Transaktion DB Transaktion DB Transaktion Dynpro 1 PAI/PBO Dynpro 2 PAI/PBO Dynpro 3 PAI Verbuchungsteil Verbucher Transaktionen auf der Datenbank PAI Module zu Dynpro 1 PBO Module zu Dynpro 2 COMMIT auf der DB PAI Module zu Dynpro 2 PBO Module zu Dynpro 3 COMMIT auf der DB PAI Module zu Dynpro 3 ABAP-Kommando COMMIT WORK COMMIT auf der DB DIA-WP 1 DIA-WP 2 DIA WP 3 Anwendungsdaten werden bei Kommando CALL FUNCTION... IN UPDATE TASK in VB- Tabellen geschrieben (VBMOD, VBDATA) Alle VB-Module (Funktionsbausteine) werden der Reihe nach abgearbeitet COMMIT Verbuchungs WP Daten werden aus VB-Tabellen in Anwendungstabellen geschrieben Das Beispiel zeigt eine SAP-LUW. Diese beinhaltet eine Dialogtransaktion, die über 3 Dynpros geht. Hierbei kann jedes Dynpro von einem anderen (Dialog-)Workprozeß bearbeitet werden, da in der Zeit, in der auf eine Eingabe des Benutzers gewartet wird, der Workprozeß vom Dispatcher eine andere Aufgabe zugeteilt bekommt. Die Dialogtransaktion wird mit dem Kommando COMMIT WORK abgeschlossen; es beginnt der Verbuchungsteil der LUW: der Verbuchungsserver (in diesem Bild Verbucher genannt) übergibt den Verbuchungsauftrag [Seite 9] einem Verbuchungs- Workprozeß. Hierbei entspricht in der Dialogtransaktion die Zeitspanne zwischen zwei Dynprowechseln einer Datenbank-LUW (abgeschlossen mit einem COMMIT auf der DB), der Verbuchungsteil wird in einer Datenbank-LUW durchgeführt. Der Verbuchungsteil ist unter Der Verbuchungsprozeß [Seite 13] genauer beschrieben. Datenbank-LUW vs. SAP-LUW Für die Datenbank ist eine LUW eine nicht teilbare Folge von Datenoperationen, die entweder komplett oder überhaupt nicht ausgeführt werden soll. Datenbank-LUWs sind die Bausteine, aus denen sich die Datenbankverfahren für eine konsistente Datenverarbeitung zusammensetzen. Eine R/3-Transaktion kann mehrere Datenbank-LUWs umfassen (siehe obiges Beispiel), von denen jede mit einem automatisch erzeugten Datenbank-Commit beendet wird. April 2001 7
SAP AG Funktionsweise der Verbuchung Im Gegensatz dazu ist eine LUW für das R/3-System ein unteilbarer Geschäftsprozeß, der komplett oder überhaupt nicht durchgeführt werden soll. Die SAP-LUW einer R/3-Transaktion muß gewöhnlich mehrere Datenbank-LUWs umfassen. Sie beinhaltet im Normalfall eine Dialogtransaktion (die einen Geschäftsprozeß abbildet) und die Fortschreibung der Daten in die Datenbank (Verbuchung). Bei jeder Datenbank-LUW werden Daten in die Datenbank geschrieben, aber nicht in die Anwendungstabellen, sondern in spezielle Verbuchungstabellen. Ist der Dialogteil dann abgeschlossen, werden alle Daten in einer Datenbank-LUW in die Anwendungstabellen übernommen: der Verbuchungsauftrag [Seite 9] wird ausgeführt. Dies ist im Detail unter Der Verbuchungsprozeß [Seite 13] beschrieben. Vorteile des SAP Verbuchungssystems Das Verbuchungssystem bietet eine Reihe von Vorteilen gegenüber direkt in einer Transaktion erfolgenden Datenbankänderungen. Dies sind: verbesserte Performance für Dialog-Transaktionen: Langwierige Datenbankänderungen werden asynchron am Ende der LUW durchgeführt, wenn der Anwender schon in der nächsten LUW ist. Lösung der Probleme, die durch die unterschiedliche Bedeutung einer Logical Unit of Work (LUW) für ein Datenbanksystem und für eine R/3-Transaktion verursacht werden. Das Verbuchungssystem bietet durch das Bündeln der Verbuchungen [Seite 16] kritische Rollback- und Wiederherstellungsmöglichkeiten für Transaktionen. Um die Performance weiter zu erhöhen, können vom Anwendungsprogrammierer verschiedene Typen von Verbuchungen konfiguriert werden (vgl. V1- und V2-Verbuchungsmodule [Seite 23]): zeitkritische V1-Verbuchungen nicht zeitkritische V2 Verbuchungen, die von V1-Verbuchungen abhängen nicht zeitkritische V2 Verbuchungen, die gesammelt werden und zu einem späteren Zeitpunkt verarbeitet werden (Sammellauf [Seite 12]) Siehe auch: Weitere Details zum Verbuchungsprozeß finden Sie unter den folgenden Themen: Der Verbuchungsprozeß [Seite 13] Verteilte Verarbeitung von Verbuchungen [Seite 22] Hauptsystemprofilparameter für die Verbuchung [Seite 27] Meldung von Verbuchungsproblemen [Seite 32] 8 April 2001
SAP AG Verbuchungsauftrag Verbuchungsauftrag Definition Ein Verbuchungsauftrag oder auch Verbuchungssatz beschreibt die Datenänderungen, die in einer SAP-LUW festgelegt werden, die also entweder ganz oder überhaupt nicht (d. h. in einer Datenbank-LUW) ausgeführt werden sollen. (Dies bezieht sich nur auf die V1-Verbuchungen. Die V2-Verbuchungen werden angestoßen, wenn die V1-Verbuchung durchgeführt ist, finden somit in einer eigenen Datenbank-LUW statt.) Siehe hierzu Der Verbuchungsprozeß [Seite 13]. Ein Verbuchungsauftrag wird durch seinen Verbuchungsschlüssel identifiziert. Verwendung Wenn die Dialogtransaktion beendet ist (COMMIT WORK) und der Verbucher aufgerufen wird, wird zunächst der Verbuchungskopf erstellt. Dann ist der Verbuchungsauftrag angelegt. Die Verbuchungsdaten sind in den Verbuchungsmodulen (Funktionsbausteine) enthalten, die mit dem ABAP-Befehl CALL FUNCTION ' ' IN UPDATE TASK. angelegt wurden. In der Funktionsbausteinpflege (Transaktion se37, Function Builder [Extern]) wird der Typ des Funktionsbausteins festgelegt (siehe unten). Struktur Ein Verbuchungsauftrag besteht aus dem Verbuchungskopf, V1-Modulen (oder -Komponenten), V2-Modulen und Sammellauf [Seite 12]-Modulen. Ein Modul entspricht einem Funktionsbaustein und enthält die Verbuchungsdaten und u. U. die Fehlerinformation beim Verbuchungsabbruch. Die folgende Grafik zeigt den Aufbau eines Verbuchungsauftrags. April 2001 9
SAP AG Verbuchungsauftrag Verbuchungsauftrag Verbuchungskopf Modul X1 Modul X2 V1-Module Modul Xn Daten Daten.... Daten Modul Y1 Modul Y2 V2-Module Modul Ym Daten Daten.... Daten Modul Z1 Modul Z2 Sammellauf-Module Modul Zk Daten Daten.... Daten Integration Die folgenden Verbuchungstabellen in der Datenbank enthalten die Information: Verbuchungstabelle VBHDR VBMOD VBDATA VBERROR Inhalt/Bedeutung Verbuchungsköpfe (einer pro Verbuchungsauftrag), siehe auch Verbuchungskopf anzeigen [Seite 38] Verbuchungsmodule (eines pro Funktionsbaustein), n V1 Module und m V2-Module pro Verbuchungsauftrag (siehe auch Verbuchungsmodule anzeigen [Seite 40]) Daten, die den Modulen übergeben werden (Variablen, Feldleisten, interne Tabellen) Fehlerinformation bei Verbuchungsabbruch Die Verbuchungstabellen sind wie folgt aufgebaut. 10 April 2001
SAP AG Verbuchungsauftrag VBHDR Verbuchungskopf VBERROR Fehlerinformation VBMOD Verbuchungsmodul VBDATA Verbuchungsdaten VBMOD Verbuchungsmodul VBDATA Verbuchungsdaten VBDATA Verbuchungsdaten Diese Tabellen können Sie sich auch im R/3 System mit der Tabellenpflegetransaktion (se16) anschauen. Genauere Information zur Tabellenpflege finden Sie in der Dokumentation. April 2001 11
SAP AG Sammellauf Sammellauf Definition Neben V1- und V2-Funktionsbausteinen gibt es auch Funktionsbausteine vom Typ Sammellauf. Diese werden im Gegensatz zu Ersteren nicht automatisch verbucht, sondern erst, wenn ein spezieller Report (Report RSM13005) die Verbuchung anstartet (etwa im Batchbetrieb). Dann werden alle Aufrufe des Funktionsbausteins gesammelt, verdichtet (siehe Beispiel) und auf einmal verbucht. Hierbei werden sie behandelt wie V2-Verbuchungsmodule. Verwendung Bei der Programmierung einer Transaktion verwendet man dann Sammelläufe, wenn ein Funktionsbaustein häufig aufgerufen wird und man vermeiden will, daß jeder Aufruf einzeln Datenbankfortschreibungen bewirkt. Zeitkritische Verbuchungen dürfen nicht per Sammellauf gemacht werden, der Sammellauf wird erst (u. U. lang) nach der zeitkritischen V1-Verbuchung durchgeführt. Man hat einen Funktionsbaustein, der einen Statistikeintrag um eins erhöht. Dieser wird im Verlauf der Transaktion 10 mal aufgerufen. Implementiert man diesen als V2-Funktionsbaustein, so wird nach Abschluß der V1-Verbuchung 10 mal der Funktionsbaustein verbucht, das bedeutet, es wird 10 mal in die Datenbank geschrieben. Klassifiziert man diesen als Sammellauf, so hat man die Möglichkeit, die Verbuchung auf einen Schlag zu einem beliebigen Zeitpunkt durchzuführen: das Programm ermittelt, daß der Statistikeintrag um 10 erhöht werden muß und macht dieses in einer Datenbankoperation. Integration Die Sammellauf-Verbuchungsmodule sind in der Verbuchungsverwaltung [Seite 34] noch solange zu sehen, bis der Report, der die Verarbeitung auslöst, gestartet wird. Verbuchungssätze, deren V1 und V2-Module korrekt abgearbeitet sind, die aber noch Sammelläufe enthalten, sind im Status V2 (vgl. Die wichtigsten Verbuchungsstatus [Seite 18]). 12 April 2001
SAP AG Der Verbuchungsprozeß Der Verbuchungsprozeß Einsatzmöglichkeiten Das Verbuchungssystem dient unter anderem zur Entlastung der R/3-Transaktionen bei den zeitaufwendigen Datenbankänderungen. Die Änderungen werden asynchron normalerweise mit nur kurzer Verzögerung von speziellen Verbuchungs-Workprozessen durchgeführt. Aus diesen Gründen wird das Verbuchungssystem in R/3-Transaktionen stark genutzt (von fast allen Transaktionen, die Geschäftsdaten ändern), obwohl Transaktionen Daten auch direkt in der Datenbank ändern können. Voraussetzungen Ob und wie das Verbuchungssystem genutzt wird, entscheidet der Anwendungsprogrammierer bei der Entwicklung der Transaktion. Die Möglichkeiten, die der Programmierer hat, sind detailliert im ABAP-Handbuch im Kapitel Techniken der Verbuchung [Extern] beschrieben. Ablauf Beim Programmieren mit der SAP-Verbuchung ist darauf zu achten, nur inserts, uodates und deletes in der Verbuchung durchzuführen. Das Sammeln der benötigten Daten (mit select etc.) soll natürlich schon vorher erfolgen. Eine ungeschickte Programmierung hat eine schlechte Performance und unter Umständen schwerwiegende Probleme zur Folge. Wie die Grafik in Funktionsweise der Verbuchung [Seite 7] zeigt, wird am Ende einer Transaktion COMMIT WORK und damit der Verbucher aufgerufen; die Dialogtransaktion endet, der Verbuchungsteil der SAP-LUW beginnt. Folgendes Bild stellt die Aktionen und ihre Reihenfolge dar, die verschiedene Workprozesse [Extern] durchführen. April 2001 13
SAP AG Der Verbuchungsprozeß Ablauf der Verbuchung Abschluß der Transaktion (COMMIT WORK) Aufruf des Verbuchers Abschließen des VBHDR Eintrages Suchen eines VB Servers für V1-Verbuchung (VB Dispatching) VB Server arbeitet V1-Module ab COMMIT auf Datenbank Freigeben der Sperren Suchen eines VB-Servers für V2-Verbuchung (VB Dispatching) zweiter VB Server arbeitet V2-Module ab COMMIT auf Datenbank Start der nächsten Transaktion Dialog Prozeß V1 VB Prozeß (UPD) V2 VB Prozeß (UP2) Nach dem Abschluß der Transaktion schließt der Dialogworkprozeß den VBHDR-Eintrag ab (der Verbuchungskopf des Verbuchungsauftrags [Seite 9]) und sucht einen Verbuchungsserver für die V1-Verbuchung. Dies wird unter Verbuchungs-Dispatching mit Lastausgleich [Seite 24] genauer beschrieben. Der Verbuchungsserver verteilt die Aufgaben mit an einen Verbuchungs-Workprozeß. Dieser arbeitet die V1-Module des Verbuchungsauftrags ab, löst einen COMMIT auf der Datenbank aus und gibt die R/3-Sperren, die dieser Verbuchungsauftrag hatte, frei (vgl. Das R/3 Sperrkonzept [Extern]). Anschließend sucht der Workprozeß einen Verbuchungsserver für die V2-Verbuchung, sofern V2-Verbuchungsmodule vorhanden sind. Diese wird dann von einem V2-Verbuchungsserver an einen V2-Workprozeß weitergeleitet, der die V2-Module abarbeitet und einen COMMIT auf der Datenbank auslöst. Das folgende Bild zeigt dies nochmals aus Sicht der verschiedenen Workprozesse. Ferner wird dargestellt, zu welchen Zeitpunkten Änderungen in der Datenbank vorgenommen werden. 14 April 2001
SAP AG Der Verbuchungsprozeß Ablauf der Verbuchung - beteiligte Workprozesse COMMIT WORK VBHDR abschließen V1 Prozeß suchen und starten Neue Transaktion anfangen Dialogprozeß Verbuchungsprozeß (V1) Verbuchungsprozeß (V2) V1 Module abarbeiten Commit Sperren freigeben V2 Prozeß suchen + starten werden bei CALL FUNCTION IN UPDATE TASK gefüllt Datenbank VBHDR, VBMOD, VBDATA Anwendungstabellen Analog zu V1 ohne Sperren freigeben Das Abarbeiten der V1-Module besteht darin, den Inhalt der Verbuchungstabellen VBMOD und VBDATA in die Anwendungstabellen der Datenbank zu übertragen. Erst am Ende der Datenbank-LUW, in der dies geschieht, sind die Änderungen wirklich in den gewünschten Tabellen in der Datenbank angekommen. Die R/3-Sperren werden freigegeben, und, falls es V2- Verbuchungsmodule gibt, so wird die V2-Verbuchung angestartet. Ergebnis Verläuft die Verbuchung ohne Fehler, so erscheint der Verbuchungssatz nicht mehr in der Verbuchungsverwaltung [Seite 34] und die Daten sind verarbeitet. Weitere Informationen zum Verbuchungsprozeß finden Sie unter: Verbuchungen bündeln [Seite 16] Synchrones und asynchrones Verbuchen [Seite 17] Die wichtigsten Verbuchungsstatus [Seite 18] Fehlerbehandlung und Datenkonsistenz [Seite 21] April 2001 15
SAP AG Verbuchungen bündeln Verbuchungen bündeln Eine R/3-Transaktion kann je nach Programmierung Datenbankänderungen direkt durchführen, ohne das SAP Verbuchungssystem zu benutzen; die Datenbankänderungen erfolgen dann am Ende einer Datenbank-LUW. Die Transaktion kann aber auch das SAP-Verbuchungssystem nutzen und die Verbuchungen mehrerer Datenbank-LUWs bündeln (vgl. Funktionsweise der Verbuchung [Seite 7]). Unter Bündeln versteht man die ABAP-Programmierpraktik, Datenbankänderungen zu sammeln und dann am Ende einer Transaktion gemeinsam auszuführen. (Siehe hierzu: Techniken der Verbuchung [Extern].) Bei den bisher gezeigten Beispielen wurde immer von einer Bündelung der Verbuchungen ausgegangen. Mit dem Bündeln der Verbuchungen werden durch eine R/3-Transaktion vorgenommene wichtige Änderungen in einer Datenbank-LUW zusammengefaßt. Denn nur R/3-Änderungen, die in einer einzigen Datenbank-LUW durchgeführt werden, können zurückgenommen werden. Wenn es für die Datenbank-Konsistenz erforderlich ist, daß alle mit einer R/3-Transaktion getätigten Änderungen widerrufbar sind, dann müssen alle Änderungen in einer Datenbank-LUW gebündelt werden. Für die Verbuchungsbündelung wird die Verarbeitung der speziellen ABAP-Formroutinen und - Funktionsbausteine für die Datenbankänderungen bis zur Ausgabe des ABAP-Schlüsselworts COMMIT WORK aufgeschoben. Das R/3-System enthält zudem einen eigenen Sperrmechanismus für die Beschränkung des Datenzugriffs. Dieser Mechanismus dient zum Teil dazu, R/3-Sperren innerhalb einer R/3- Transaktion über die Grenzen von Datenbank-LUWs hinaus zu erhalten. (Zu Beginn einer neuen Datenbank-LUW werden die Datenbank-Sperren der vorherigen LUW freigegeben. R/3-Sperren bleiben dagegen weiterhin aktiv.) Nähere Informationen zu R/3-Sperren finden Sie in der Dokumentation Das R/3 Sperrkonzept [Extern]. Das Bündeln von Verbuchungen und das R/3-Sperrsystem gewährleisten die Datenintegrität in Prozessen, die mehrere Datenbank-LUWs umspannen, sowie die Erfüllung der Rollback- Anforderungen. Das heißt, daß im Falle eines Laufzeitfehlers während der Verbuchung alle Datenänderungen zurückgenommen werden können. Weitere Information zu LUWs und dem Bündeln finden Sie im ABAP Handbuch. 16 April 2001
SAP AG Synchrones und asynchrones Verbuchen Synchrones und asynchrones Verbuchen Datenbankänderungen, die über das SAP Verbuchungssystem durchgeführt und an einen Verbuchungs-Workprozeß übergeben werden, können entweder synchron oder asynchron laufen. Der Modus ist in der ABAP-Codierung der R/3-Transaktionen festgesetzt und kann vom Benutzer nicht dynamisch geändert werden. Die R/3-Transaktion legt mit CALL FUNCTION IN UPDATE TASK einen Verbuchungsauftrag [Seite 9] an und übergibt diesen an einen Verbuchungs-Workprozeß. Am Ende einer Datenbank-LUW werden dann Daten in die Verbuchungstabellen beschrieben. Kurz läßt sich sagen, daß beim synchronen Verbuchen das die Anweisung COMMIT WORK AND WAIT ausgebende Programm wartet, bis der Verbuchungs-Workprozeß den Status der Verbuchung ausgibt. Von Batch-Input-Mappen generierte Verbuchungen erfolgen immer synchron. Batch- Input mit CALL TRANSACTION USING kann sowohl synchron als auch asynchron verbuchen. Außerdem wird jede 100. Verbuchung in einem Hintergrundjob synchron durchgeführt, um zu verhindern, daß das Verbuchungssystem bei der Verarbeitung von Verbuchungen in Verzug gerät. Beim asynchronen Verbuchen gibt das die Anweisung COMMIT WORK ausgebende Programm die Verbuchung an das Verbuchungssystem weiter und wartet nicht auf eine Reaktion des Verbuchungsprozesses. Die meisten Verbuchungen in R/3-Anwendungstransaktionen sind für den asynchronen Modus programmiert. Diese asynchronen Verbuchungen sind die Objekte, die in der Verbuchungsverwaltung erscheinen. Siehe auch: Techniken der Verbuchung [Extern] im ABAP-Handbuch. April 2001 17
SAP AG Die wichtigsten Verbuchungsstatus Die wichtigsten Verbuchungsstatus Die Verbuchungsverwaltung kennt verschiedene Status, in denen sich ein Verbuchungsauftrag befinden kann; dieser wird in der Übersicht der Verbuchungssätze (Transaktion sm13) in der Spalte Status angezeigt. Der Status gibt an, in welcher Phase des Verbuchungsprozesses [Seite 13] die Bearbeitung sich momentan befindet oder auch hängengeblieben ist. Im folgenden werden die wichtigsten Status beschrieben. Wie unter Der Verbuchungsprozeß [Seite 13] dargestellt, gibt der Dialogworkprozeß nach Abschluß des Dialogteils den Verbuchungsauftrag an einen Verbuchungs-Workprozeß. Dieser arbeitet dann die V1-Verbuchungsmodule ab. In dem Moment, wenn das ABAP-Kommando COMMIT WORK kommt, werden die Daten in die Datenbank geschrieben und anschließend die V2-Verbuchung (falls V2-Module in dem Verbuchungsauftrag vorhanden sind) an einen V2- Workprozeß abgegeben. In dieser Phase sind folgende Status möglich: Status Phase init err V1 V2 ok von dem Moment an, in dem der Dialogworkprozeß den Verbuchungsauftrag an den Verbuchungs-Workprozeß übergibt bis zum COMMIT im Verbuchungs-Workprozeß falls in der init-phase ein Fehler auftritt und die Verbuchung deswegen nicht durchgeführt wird wenn die init-phase korrekt abgeschlossen wurde und die V2-Module zur Verarbeitung weitergegeben sind. Gibt es keine V2-Module, erscheint dieser Verbuchungsauftrag nicht mehr in der Übersicht. wenn auch die V2-Module korrekt verarbeitet sind, aber noch ein Sammellauf (das ist quasi V3) zu verbuchen ist. Gibt es keinen Sammellauf [Seite 12], erscheint dieser Verbuchungsauftrag nicht mehr in der Übersicht. Ist der Parameter rdisp/vb_delete_after_execution [Seite 27] auf 2 gesetzt, also das automatische Löschen deaktiviert, so befindet sich eine korrekt abgeschlossene Verbuchung im Status ok. Bei aktiviertem Löschen (Default) erscheint dann der Verbuchungssatz nicht mehr in der Übersicht. Nun ist es auch möglich, daß ein Verbuchungssatz im Status init hängenbleibt, ohne in den Fehlerzustand err zu kommen. Erscheint der Satz über längere Zeit im Status init, gibt es folgende Möglichkeiten, wie der Satz nachträglich verbucht werden kann; folgende Status werden dann aktiv (siehe auch die folgende Grafik). Status Phase 18 April 2001
SAP AG Die wichtigsten Verbuchungsstatus auto(dia) run auto(sys) der Systemadministrator hat mit der Transaktion sm13 (Verbuchungssätze Buchen) den Verbuchungssatz manuell verarbeitet [Seite 43]. Der Dialogworkprozeß (WP1) übergibt alle diese Verbuchungsaufträge einem Verbuchungs-Workprozeß (WP2) in dieser Zeitspanne befindet sich der Verbuchungssatz im Status auto(dia). Der Workprozeß WP2 sammelt die Aufträge und gibt sie portionsweise an einen weiteren Verbuchungs-Workprozeß (WP3), der dann die tatsächliche Verbuchung vornimmt. Bis zum COMMIT in WP3 befindet sich der Satz im Status run. Bei jedem Neustart eines Verbuchungsservers schaut dieser nach, ob Verbuchungsaufträge sich im Status init befinden. In diesem Fall startet er eine automatische Bearbeitung der Aufträge durch Verbuchungs-Workprozesse. Diese geht genauso vonstatten wie nach einem manuellen Anstarten der Verbuchung, nur daß in diesem Fall ein Verbuchungs-Workprozeß (WP4) das Ganze anstartet und kein Dialogworkprozeß. Der Verbuchungssatz befindet sich dann im Status auto(sys). Folgende Grafik illustriert diesen Sachverhalt. Verbuchungs-WP Sucht beim Start alle VB-Sätze, die Status init haben Verbuchungs-WP - nimmt 100 Stück und gibt sie zur Verarbeitung an WP3 - gibt ein 100-Signal weiter (an WP5)... Verbuchungs-WP - führt die V1- Verbuchung aus - gibt evtl. V2- Module weiter WP4 Auto (sys) WP2 100-Signal run WP3 COMMIT Auto(dia) WP5 ok V2 100-Signal WP1 Dialog-WP (sm13, VBSätze -> Buchen).. In dem seltenen Fall, daß die Verbuchung nicht im ersten Anlauf geklappt hat, entspricht beim Nachbuchen also der Zustand run dem Zustand init. Bleibt im Zustand auto oder run die Verbuchung hängen, muß der Status zurückgesetzt [Seite 44] werden, da mit den beschriebenen Methoden nur Sätze im Status init erfaßt werden. Siehe auch: Verbuchung überwachen [Seite 60] April 2001 19
SAP AG Die wichtigsten Verbuchungsstatus Verbuchungsfehler analysieren und beheben [Seite 66] 20 April 2001
SAP AG Fehlerbehandlung und Datenkonsistenz Fehlerbehandlung und Datenkonsistenz Um die Datenkonsistenz zu gewährleisten, muß, einfach ausgedrückt, eine Verbuchung entweder komplett oder überhaupt nicht ausgeführt werden. Man spricht hier von der Rollback- Anforderung. Im Falle eines Laufzeitfehlers in einem Teil der Verbuchung müssen alle durch die Verbuchung erfolgten kritischen Datenbankänderungen widerrufen werden. Weniger kritische Änderungen können nicht vorgenommen werden. Das R/3-Verbuchungssystem gewährleistet durch das Sperrsystem und das Bündeln von Verbuchungen [Seite 16] Datenkonsistenz (siehe Der Verbuchungsprozeß [Seite 13]). Im folgenden wird beschrieben, wie das Verbuchungssystem reagiert, wenn ein Teil einer Verbuchung (V1 oder V2) wegen eines Laufzeitfehlers abbricht. Hierfür gibt es verschiedene Möglichkeiten. Abbruch in einem Funktionsbaustein der Verbuchungstask V1 (angefordert IN UPDATE TASK) Bereits vorgenommene Verbuchungen für V1-Funktionen werden zurückgenommen. Alle weiteren Aufträge der Verbuchungstask (V1, V2 oder Sammellauf) werden verworfen. Der Anwender erhält eine Expreßmail, daß die Verbuchung fehlgeschlagen ist (vgl. Parameter rdisp/vbmail [Seite 27]) Abbruch in einem Funktionsbaustein der Verbuchungstask V2 (angefordert IN UPDATE TASK) Bereits vorgenommene Verbuchungen für V2-Funktionen werden zurückgenommen. Verbuchungen für bereits vorher ausgeführte V1-Funktionen werden nicht zurückgesetzt. Auf dem Bild erscheint eine Fehlermeldung, wenn das System dazu entsprechend eingerichtet ist. Abbruch in einem Funktionsbaustein vom Typ Sammellauf Sammelläufe werden behandelt wie V2-Verbuchungsbausteine April 2001 21
SAP AG Verteilte Verarbeitung von Verbuchungen Verteilte Verarbeitung von Verbuchungen Die Aufgabe, die Verbuchungsaufträge [Seite 9] (gleichmäßig) an die verschiedenen Verbuchungs-Workprozesse zu verteilen, übernimmt ein Verbuchungsserver. Der Verbuchungsserver ist also eine Zwischenschicht, die den Verbuchungsauftrag entgegennimmt und an Verbuchungs-Workprozesse verteilt. In R/3-Systemen mit Codepage-Heterogenität (d. h. die Codepages der R/3- Applikationsserver haben unterschiedliche Zeichensätze) ändern die Verbuchungs- Workprozesse dynamisch ihre Codepage entsprechend der Codepage des zu verarbeitenden Verbuchungsauftrags. Die Verteilung von Verbuchungen kann mit Parametern des R/3-Systemprofils deaktiviert und konfiguriert werden. Weitere Informationen finden Sie unter Hauptsystemprofilparameter für die Verbuchung [Seite 27] oder bei den Verbuchungsprofilparametern in Transaktion rz11 (verwenden Sie zur Suche der Parameter den Suchstring rdisp/vb* in rz11). Arten von Verbuchungs-Workprozessen Es gibt zwei Arten von Verbuchungs-Workprozessen, eine für V1-Verbuchungen (in der Anzeige der Transaktionen sm50/sm51 als Update-Prozesse aufgelistet) und eine für V2-Verbuchungen (in der sm50/sm51-anzeige als Upd2 aufgelistet). Es muß mindestens ein Verbuchungsprozeß vom Typ V1 im R/3-System vorhanden sein, es können jedoch auch mehr sein. Im letzteren Fall ist die Verbuchungsverarbeitung entsprechend einem Lastausgleichsalgorithmus auf die Workprozesse verteilt (siehe Verbuchungs-Dispatching mit Lastausgleich [Seite 24]). Der Typ V2 ist optional. Er dient dazu, Performance-Probleme bei zeitkritischen V1- Verbuchungen zu mindern, indem die Verarbeitung der V2-Verbuchungskomponenten abgespaltet wird. (V2-Verbuchungskomponenten sind in der Regel statistische Daten und daher weniger zeitkritisch. Nähere Informationen finden Sie unter Der Verbuchungsprozeß [Seite 13] und V1- und V2-Verbuchungsmodule [Seite 23]. Wenn kein V2-Workprozeß vorhanden ist, werden beide Arten von Verbuchungskomponenten im V1-Workprozeß verarbeitet. V2 Workprozesse werden auch verwendet, wenn Sammelläufe [Seite 12] verbucht werden. 22 April 2001
SAP AG V1- und V2-Verbuchungsmodule V1- und V2-Verbuchungsmodule Eine Verbuchung ist in verschiedene Module unterteilt (siehe Verbuchungsauftrag [Seite 9]). Jedes Modul entspricht einem Verbuchungs-Funktionsbaustein. Hierbei gibt es verschiedene Typen. Das R/3-System unterscheidet zwischen primären, zeitkritischen (V1) und sekundären, nicht kritischen (V2) Verbuchungsmodulen. Des weiteren gibt es Sammelläufe [Extern] für häufig benutzte Funktionsbausteine. Diese Unterscheidung ermöglicht es dem System, kritische Datenbankänderungen vor weniger kritischen Änderungen zu verarbeiten. V1-Module beschreiben kritische oder primäre Änderungen; sie betreffen Objekte, die eine Steuerfunktion im R/3-System haben, also beispielsweise eine Auftragserstellung oder eine Änderung in einem Materialbestand. V2-Module beschreiben weniger kritische, sekundäre Änderungen. Dies sind beispielsweise rein statistische Verbuchungen wie die Berechnung von Ergebnissen. Die V1-Module werden nacheinander in einem einzigen Verbuchungs-Workprozeß auf demselben Applikationsserver verarbeitet. Sie gehören also zu derselben Datenbank-LUW und können zurückgenommen werden. Die V1-Verbuchungen werden zudem unter den R/3-Sperren der die Verbuchung erzeugenden Transaktion durchgeführt (vgl. Das R/3 Sperrkonzept [Extern]). Somit ist die Datenkonsistenz gewährleistet; eine gleichzeitige Änderungen der zu verbuchenden Objekte ist nicht möglich. V2-Verbuchungen werden zusammen in einer eigenen LUW und nicht unter den Sperren der sie erzeugenden Transaktion durchgeführt. Ist in Ihrem R/3-System ein Workprozeß für V2- Verbuchungen vorhanden, erfolgen diese ausschließlich dort. Anderenfalls werden die V2- Komponenten durch einen V1-Verbuchungsprozeß verarbeitet. Alle V1-Module einer Verbuchung müssen vor den V2-Modulen verarbeitet werden. Angenommen, eine Transaktion nimmt dispositive Änderungen an einem Material und an einer Bilanz vor und aktualisiert zudem zwei Statistiken. Jede dieser Änderungen wird durch ein Verbuchungsmodul (Aufruf eines Verbuchungs-Funktionsbausteins) im Verbuchungsauftrag [Seite 9] repräsentiert die beiden dispositiven Änderungen durch ein V1-Verbuchungsmodul (zeitkritisch), die statistischen Änderungen durch ein V2-Verbuchungsmodul (weniger kritisch). (Die V1-Module haben Vorrang, wobei die V2-Module in der Regel ebenfalls direkt verarbeitet werden.) Dies ist ausführlich unter Der Verbuchungsprozeß [Seite 13] beschrieben. April 2001 23
SAP AG Verbuchungs-Dispatching mit Lastausgleich Verbuchungs-Dispatching mit Lastausgleich In einem R/3-System können mehrere Verbuchungsserver Verbuchungsdienste anbieten. In einem solchen Fall verteilt das R/3-System automatisch die Verbuchungsaufträge [Seite 9] unter den verfügbaren Verbuchungsservern anhand eines Prozesses, der als Verbuchungs- Dispatching bezeichnet wird. Die Verbuchungsverarbeitung wird durch einen Auftrag von dem Dialogserver ausgelöst, auf dem eine Verbuchung generiert wurde. Dieser Auftrag wird an einen bestimmten Verbuchungsserver gesendet. Der Dialogserver entscheidet also, welcher Verbuchungsserver für eine bestimmte Verbuchung verwendet werden soll. Die Grundlage für den Lastausgleich ist eine Liste der verfügbaren Verbuchungsserver. Diese Liste ist auf jedem Applikationsserver vorhanden und wird automatisch vom Message-Server aktualisiert, wenn ein Server startet oder stoppt oder über einen Wechsel in eine neue Betriebsart seine Konfiguration ändert. Mit Springen Server können Sie sich diese Liste anzeigen lassen. Wenn mehr als ein Verbuchungsserver für die Verarbeitung eines Verbuchungssatzes in Frage kommt, wählt der Dialogserver den zu verwendenden Verbuchungsserver anhand eines Lastausgleichsalgorithmus. Dieser Lastausgleichsalgorithmus weist den Verbuchungsservern zyklisch reihum Verbuchungssätze zu. Ein Server sendet Verbuchungsaufträge nacheinander zu jedem Verbuchungsserver. Wenn die Anzahl der gesendeten Aufträge der Anzahl der Verbuchungs- Workprozesse an einem Verbuchungsserver entspricht, wird der Server bis zum Anfang des nächsten Zyklus von der Liste genommen. Wenn alle Verbuchungs-Workprozesse im R/3- System auf diese Art Verbuchungsaufträge erhalten haben, beginnt der Zyklus von neuem mit allen Verbuchungsservern. Wurde ein V2-Workprozeß Upd2 definiert, können V2-Verbuchungsmodule nur von diesem Workprozeß verarbeitet werden. Existiert kein V2-Workprozeß, werden V2-Verbuchungen in V1-Workprozessen verarbeitet. Eine V2-Verbuchungskomponente muß jedoch warten, bis alle V1-Verbuchungsaufträge abgearbeitet sind. Das folgende Beispiel erklärt den Lastausgleichsalgorithmus.. 24 April 2001
SAP AG Verbuchungs-Dispatching mit Lastausgleich V1-Workprozeß 1 V1-Workprozeß 2 V1-Workprozeß 1 V2-Workprozeß 1 Verbuchungsserver 1 Verbuchungsserver 2 V1 Verbuchungsauftrag 1 V2 Verbuchungsauftrag 1 Zeit V1 Verbuchungsauftrag 2 V2 Verbuchungsauftrag 2 V1 Verbuchungsauftrag 3 V2 Verbuchungsauftrag 3 V1 Verbuchungsauftrag 4 V1-Verteilungszyklus wiederholen Auf Verbuchungsserver 1 laufen zwei Workprozesse für V1-Verbuchungsmodule. Verbuchungsserver 2 hat einen V1- und einen V2-Verbuchungs-Workprozeß. Ein Lastausgleichszyklus für V1-Verbuchungen besteht also aus drei Verbuchungsaufträgen. Diese werden wie folgt verteilt: 1. Der erste und zweite Verbuchungsauftrag werden an Verbuchungsserver 1 gesendet (Anzahl der Aufträge = Anzahl der V1-Verbuchungs-Workprozesse * Parameter rdisp/vb_factor (Standardwert 1; siehe hierzu Weitere Systemprofilparameter [Seite 30]). Den Parameter auf einen anderen Wert als 1 zu stellen kann sinnvoll sein, wenn ein Verbuchungsserver deutlich schneller ist und deshalb mehr Verbuchungsaufträge erhalten soll. 2. Für den dritten Auftrag wechselt das Verbuchungssystem zu Verbuchungsserver 2. Der Lastausgleichszyklus ist komplett (Anzahl der vergebenen Verbuchungen = Anzahl der Verbuchungs-Workprozesse). 3. V1-Verbuchungsauftrag 4 wird wieder an Verbuchungsserver 1 gesendet, und der Zyklus wiederholt sich. 4. V2-Verbuchungen werden der Reihe nach von dem V2-Workprozeß abgearbeitet. Neuzuweisung bei Ausfall eines Verbuchungsservers Wenn ein Verbuchungsserver aus irgendeinem Grund ausfällt, übernehmen die anderen Verbuchungsserver im System und verarbeiten etwaige Verbuchungen, die der ausgefallene Server nicht verarbeiten konnte. Wenn ein Verbuchungsserver beispielsweise abgeschaltet wird, findet der R/3-Message-Server anhand einer Fehlermeldung zu der fehlenden Serververbindung oder bei der regelmäßig durchgeführten Verbindungsüberprüfung heraus, daß der Server nicht mehr verfügbar ist. April 2001 25
SAP AG Verbuchungs-Dispatching mit Lastausgleich Nachdem der Message-Server darüber informiert ist, aktualisiert er die Liste der Applikationsserver und der entsprechenden Dienste und verteilt die Liste an die anderen Applikationsserver. Der erste Verbuchungsserver auf der Liste übernimmt automatisch die Aufgabe der Verteilung der Verbuchungsaufträge des ausgefallenen Servers anhand der oben beschriebenen dynamischen Verbuchungszuweisungskriterien. 26 April 2001
SAP AG Hauptsystemprofilparameter für die Verbuchung Hauptsystemprofilparameter für die Verbuchung Die folgende Tabelle zeigt zusammenfassende Informationen zu den wichtigsten Verbuchungsparametern. Beachten Sie, daß Sie diese Parameter normalerweise niemals direkt setzen müssen. Im allgemeinen ist entweder der Standardwert der Parameter der beste Wert oder die Parameter werden von der Profilverwaltungsfunktion für Sie gesetzt (beispielsweise wenn Sie die Anzahl der Verbuchungs-Workprozesse in einem Instanzenprofil setzen). Parameter Bedeutung rdisp/vb_dispatching rdisp/vbname rdisp/vb_delete_after_execution rdisp/max_vb_server Schaltet Verbuchungs-Dispatching mit Lastausgleich [Seite 24] ein (1) oder aus (0). Im Standard ist der Lastausgleich aktiv. Ändern Sie diesen Wert ausschließlich auf Anweisung von SAP. Gibt den Namen des Verbuchungsservers an, der die Verarbeitung der Verbuchungen übernehmen soll, wenn der Lastausgleich deaktiviert ist (rdisp/vb_dispatching = 0). Gibt im Standard den Namen eines Verbuchungsservers vor (beim Erstellen des Verbuchungsservers eingestellt). Wenn rdisp/vb_dispatching auf 0 steht, werden die Verbuchungen nur von dem Server in rdisp/vbname verarbeitet. Ist der Parameter falsch eingestellt (nicht auf einen Verbuchungsserver), wird dies bei der Installationsüberpüfung (Transaktion sick) gemeldet. Bestimmt, ob Verbuchungssätze nach der erfolgreichen Verarbeitung automatisch gelöscht werden. Im Standard auf 1 (automatisches Löschen aktiviert) eingestellt. Der Wert 2 deaktiviert das automatische Löschen. Dieser Wert kann verwendet werden, um die Verbuchungs- und Datenbank-Performance einzustellen. In diesem Fall sollte mindestens einmal täglich der Report rsm13002 mit dem Parameter DELETE = X im Hintergrundverarbeitungssystem laufen, damit die Verbuchungstabellen nicht zu groß werden. Siehe auch das Kapitel Hintergrundverarbeitung [Extern] in der CCMS- Dokumentation. Maximale Anzahl Verbuchungsserver, die im R/3-System erlaubt sind. Default sind 50 Server. April 2001 27
SAP AG Hauptsystemprofilparameter für die Verbuchung rdisp/vb_included_server rdisp/vbdelete rdisp/vbmail rdisp/vbreorg Liste der R/3-Verbuchungsserver, die für die Verarbeitung von Verbuchungen nach dem Lastausgleichsprinzip verwendet werden sollten. In der Liste nicht aufgeführten Verbuchungsservern werden keine Verbuchungen für die Verarbeitung zugewiesen. Im Standard ist dieser Parameter leer. Das heißt, daß alle aktiven Verbuchungsserver für den Lastausgleichsmechanismus berücksichtigt werden. Dies ist im allgemeinen der optimale Wert. Gibt an, nach wie vielen Tagen die Verbuchungssätze gelöscht werden. Im Standard ist der Parameter auf 50 Tage gesetzt. Nach Ablauf dieser Zeit wird ein Verbuchungssatz unabhängig von seinem Status (verarbeitet, nicht verarbeitet, Fehler usw.) gelöscht. Mit dem Wert 0 wird das automatische Löschen deaktiviert. Dieser Wert sollte nur vorübergehend eingestellt werden und nur, wenn ein fehlerhafter Verbuchungssatz für die weitere Analyse aufbewahrt werden soll. Legt fest, ob ein Benutzer über den Abbruch seiner Verbuchung per Expreßmail informiert werden soll. Im Standard ist der Parameter aktiviert (Wert 1). Wenn eine Verbuchung vorzeitig abbricht, sendet das System über R/3 Mail eine Expreßmail an den Benutzer, der die Verbuchung erstellt hat. Mit dem Wert 0 wird das automatische Versenden von Expreßmails deaktiviert. Legt fest, ob Verbuchungsserver nach dem Start nach unvollständigen Verbuchungssätzen suchen und diese löschen sollen. Unvollständige Verbuchungssätze können entstehen, wenn eine Transaktion eine oder mehr Verbuchungskomponenten registriert, durch eine Bildänderung in der die Verbuchung erzeugenden Transaktion ein Datenbank-Commit generiert wird, die Transaktion aber vorzeitig abbricht und ein Rollback ausgelöst wird. Unvollständige Verbuchungssätze sind ohne Bedeutung, belegen jedoch Platz in der Datenbank. Aus diesem Grund ist diese Reorganisation im Standard aktiviert (Wert 1). Mit dem Wert 0 können Sie die Reorganisation deaktivieren. In diesem Fall sollten Sie jedoch sicherstellen, daß regelmäßig der Report rsm13002 im Hintergrund ausgeführt wird, um die unvollständigen Verbuchungssätze zu löschen (siehe Hintergrundverarbeitung [Extern]). 28 April 2001
SAP AG Hauptsystemprofilparameter für die Verbuchung rdisp/vbstart Legt fest, ob nicht verarbeitete bzw. nicht vollständig verarbeitete (Status run, V2-Module nicht verarbeitet, usw.) Verbuchungsaufträge automatisch verarbeitet werden, wenn ein Verbuchungsserver gestartet wird. Im Standard (Wert 1) werden solche Verbuchungssätze (gewöhnlich mit dem Status auto) verarbeitet (vgl. Die wichtigsten Verbuchungsstatus [Seite 18]). Der Wert 0 deaktiviert die automatische Verarbeitung. Normalerweise kann der Wert dieses Parameters nur durch SAP geändert werden. Um weitere Informationen zu den Verbuchungsparametern zu erhalten, geben Sie im R/3-System den Transaktionscode /nrz11 ein und suchen dann nach Parametern, deren Namen mit rdisp/vb beginnen. April 2001 29
SAP AG Weitere Systemprofilparameter Weitere Systemprofilparameter Die wichtigsten Systemprofilparameter für die Verbuchung sind unter Hauptsystemprofilparameter für die Verbuchung [Seite 27] beschrieben. Es gibt noch weitere, die zur Fehlerbehebung und Optimierung der Verbuchungsperformance nützlich sein können. Diese werden im folgenden beschrieben. Detailliertere Informationen erhalten Sie, wenn Sie in der Transaktion rz11 nach den Parametern suchen und sich dann die Dokumentation anzeigen lassen. Parameter Beschreibung rdisp/vb_context Mit diesem Parameter kann geregelt werden, wie das V1- Verbuchungs-Dispatching [Seite 24] erfolgen soll. Der Parameter ist als Bitmaske zu interpretieren: Bit 0 : Beim Dispatching soll die DB-Gruppe erhalten bleiben (vgl. Verbuchungsgruppen konfigurieren [Seite 47]) rdisp/vb2_context rdisp/vb_factor Bit 1 : Beim Dispatching muß ein Verbuchungsserver ausgewählt werden, der die aktuelle Sprache installiert hat. Der Default-Wert von 3 (beide Bits gesetzt) bewirkt z.b., daß beim Update-Dispatching immer ein Verbuchungsserver ausgewählt wird, der in der gleichen DB-Gruppe liegt und der die aktuelle Sprache installiert hat. Änderungen sollten nur zur Behebung von Fehlersituationen erfolgen. Wertebereich: 0 3. Dieser Parameter regelt analog zu rdisp/vb_context das Update- Dispatching für V2-Verbuchungen. Das Dispatching von Verbuchungsaufträgen erfolgt nach einem einfachen Verfahren, das unter Verbuchungs-Dispatching mit Lastausgleich [Seite 24] beschrieben ist. Mit dem Parameter rdisp/vb_factor kann die für das Dispatching relevante Anzahl von Verbuchungs-Workprozessen beeinflußt werden, um z.b. sehr schnellen Servern mehr Verbuchungsaufträge zuzuteilen. Die für das Dispatching relevante Zahl ergibt sich als Produkt aus der aktuellen Anzahl von Verbuchungs-Prozessen und dem Wert von rdisp/vb_factor. Nach der Bearbeitung des V1-Teils eines Verbuchungsauftrags wird der V2-Teil analog "dispatched". Der Parameterwert muß folgender Syntax entsprechen: rdisp/vb_factor = S=<Instanz-Name>,F=<Faktor>; S=<Instanz-Name>,F=<Faktor>; rdisp/vb_factor = S=host1_C11_00,F=2.0; S=host2_C11_00, F=2.5; 30 April 2001
SAP AG Weitere Systemprofilparameter rdisp/vb_key_comp rdisp/vb_refresh_info rdisp/vb_v2_start Mit Hilfe des Parameters rdisp/vb_key_comp kann der Verbuchungsschlüssel (vgl. Verbuchungskopf anzeigen [Seite 38]) in seinem Aufbau verändert werden. Normalerweise setzt sich der key zusammen aus Datum, Zeit, Mikrosekunden, Hostname, Systemnummer und Workprozeßnummer. Um eine günstigere Indexstruktur zu erhalten, können durch Einstellung des Parameters veränderliche Anteile nach vorne gebracht werden. Dieser Parameter definiert die Zeitspanne, nach der der Kontext eines Verbuchungsservers neu bestimmt wird. Zum Kontext gehören die Anzahl der Verbuchungs-Workprozesse des Servers sowie die Codepage und DB-Node des Servers. Der Kontext eines Verbuchungsservers kann sich z. B. durch die Betriebsartenumstellung ändern. Deshalb wird der Kontext nur jede Stunde erneut gelesen. Der Parameter bestimmt, ob die V2-Phase eines Verbuchungsauftrags automatisch nach der V1-Phase ablaufen oder zeitverzögert durch einen Batch-Job angestoßen werden soll. Wertebereich: 1: V2-Phase wird sofort nach der V1-Phase gestartet 2: V2-Phase wird nicht automatisch angestartet April 2001 31
SAP AG Meldung von Verbuchungsproblemen Meldung von Verbuchungsproblemen Das Verbuchungssystem weist Sie wie folgt auf Verbuchungsprobleme hin: Der graphische Alert Monitor [Extern] meldet automatisch alle Verbuchungsprobleme. Das Verbuchungssystem sendet im Falle eines vorzeitigen Abbruchs einer Verbuchung eine R/3-Expreßmail. Der Benutzer wird in einem Dialogfenster über den Eingang der Expreßmail informiert. Der Benutzer, dessen Verbuchung vorzeitig abgebrochen wurde, erhält eine Fehlermeldung. Bei einer automatischen oder manuellen Deaktivierung der Verbuchung wird eine systemweite Meldung angezeigt. In der Verbuchungsverwaltung [Seite 34] sind alle abgebrochenen Verbuchungen aufgeführt. Sie erhalten den Status err. Siehe auch Die wichtigsten Verbuchungsstatus [Seite 18]. Expreßmails und Fehlermeldungen Zusätzlich zu den Alerts weist das R/3-System jeden Benutzer, dessen Verbuchung abgebrochen wurde, mit einer Expreßmail auf den Verbuchungsfehler hin. Die Mail wird in dem R/3-System geschickt, in dem das Problem auftrat. Im Standard ist die Warnung per Mail aktiviert, Sie können sie jedoch mit dem Parameter rdisp/vbmail im Systemprofil deaktivieren (nähere Informationen zu diesem Parameter finden Sie unter Hauptsystemprofilparameter für die Verbuchung [Seite 27] und in Transaktion rz11). Im allgemeinen zeigt das R/3-System am Terminal des Benutzers auch eine Meldung zu dem Verbuchungsfehler an. Ausnahmen sind, wenn beispielsweise durch einen RFC eine Fernverbuchung durchgeführt wurde oder wenn der Benutzer sich vor der Verarbeitung der Verbuchung abgemeldet hat. Hinweis über eine Verbuchungsdeaktivierung Bei einem schweren Datenbankfehler wird die Verbuchung automatisch gestoppt (nähere Informationen hierzu unter Automatischer Verbuchungsstopp bei Datenbankproblemen [Seite 33] und Verbuchung de- und reaktivieren [Seite 64]). In einem solchen Fall erhalten Sie und alle anderen Benutzer eine Warnmeldung in der Statuszeile des aktiven Modus. Durch die Deaktivierung werden allen aktiven Transaktionen im System unterbrochen. Siehe auch: Verbuchung überwachen [Seite 60] Verbuchungsfehler analysieren und beheben [Seite 66] 32 April 2001
SAP AG Automatischer Verbuchungsstopp bei Datenbankproblemen Automatischer Verbuchungsstopp bei Datenbankproblemen Wenn in der Datenbank des R/3-Systems ein schwerer Fehler auftritt, wird die Verbuchung automatisch gestoppt. Jede Datenbank-Fehlermeldung, die einen Datenbank-Administrator erfordert, bewirkt eine Benachrichtigung des Verbuchungssystems, welches daraufhin die Verbuchung unterbricht. Der automatische Stoppmechanismus ist für alle vom R/3-System unterstützten Datenbanken gültig. Angenommen, Ihre Oracle-Datenbank hat gerade die Meldung Tablespace-Überlauf ausgegeben. Die R/3-Datenbank-Schnittstelle erkennt die Meldung als schwere Fehlermeldung und gibt ein Signal an das Verbuchungssystem aus, welches daraufhin die Verbuchung stoppt. Die aktiven Transaktionen werden unterbrochen (mit einer entsprechenden Meldung), bis die Verbuchung reaktiviert wird. Das Stoppen der Verbuchung bei einem Datenbankproblem erleichtert die Wiederherstellung des Normalzustands, nachdem der Fehler behoben ist. Verbuchungen werden nicht abgebrochen, sondern erhalten den Status init oder auto, der sie als noch nicht erledigt ausweist. Bei der Reaktivierung der Verbuchung nach Behebung des Fehlers werden die Verbuchungen automatisch verarbeitet. Die Verbuchung wird nicht gestoppt, wenn ein lokaler Fehler in einem Verbuchungs- Funktionsbaustein einen vorzeitigen Abbruch einer Verbuchung verursacht (vgl. Fehlerbehandlung und Datenkonsistenz [Seite 21]). Weitere Informationen finden Sie unter Verbuchung de- und reaktivieren [Seite 64]. April 2001 33
SAP AG Die Verbuchungsverwaltung Die Verbuchungsverwaltung Verwendung Die Verbuchungsverwaltung dient dazu, Verbuchungen anzuzeigen abgebrochene Verbuchungen zu testen und zu bereinigen Verbuchungen zurückzusetzen Verbuchungen zu löschen Statistiken über die Verbuchung anzuzeigen Das Einstiegsbild der Verbuchungsverwaltung (Transaktion sm13) sieht so aus: Verbuchungssätze: Einstieg Verbuchungssätze Bearbeiten Springen System Hilfe Mandant 000 Benutzer HAUGT Status Abgebrochen Noch zu verbuchen V1 ausgeführt V2 ausgeführt Alle Die Verbuchung ist aktiv Selektion Ab Datum 15.10.1998 Ab Zeit 00:00:00 Max Anzahl Sätze 99999 Server Info Integration Wie man Verbuchungen überwachen kann und mit Verbuchungsfehlern umgeht, ist in den Kapiteln Verbuchung überwachen [Seite 60] und Verbuchungsfehler analysieren und beheben [Seite 66] beschrieben. Funktionsumfang Die Verbuchungsverwaltung bietet folgende Funktionen: Verbuchungen auswählen und anzeigen [Seite 36] Abgebrochene Verbuchungen analysieren [Seite 41] 34 April 2001