Transaktionssystemeigenschaften im SAP System R/3

Transkript

1 Blockseminar Transaktionssysteme Friedrich-Schiller-Universität Jena 1999: Transaktionssystemeigenschaften im SAP System R/3 Thomas Arend SAP AG Thomas Arend SAP AG Jena 99 June,

2 Themenübersicht Client/Server Architektur des R/3 System Datenbankänderungen n Bündelung n Verbuchungstechniken n Sperrkonzept Transaktionsverarbeitung n Synchrone Aufrufe n Asynchrone Aufrufe n Datenübergabetechniken n LUWs n RFC-Techniken n Transaktionsmonitore Aktuelle Entwicklungen Thomas Arend SAP AG Jena 99 June,

3 SAP R/3: 3-Ebenen Client/Server-Architektur Presentation SAPGUI SAPGUI SAPGUI SAPGUI Dispatcher Application Work- prozeß Work- prozeß Work- prozeß Database DB-Workprozesse Thomas Arend SAP AG Jena 99 June, Das SAP R/3-System basiert auf der 3-Ebenen-Architektur eines Client-Server-Systems. Es besteht aus den drei Ebenen Datenbank, Applikationsserver und Präsentationsserver. Durch die Wahl dieser Architektur mit dem Verteilen von Benutzeranfragen (Userdispatching) ist es möglich, ein hocheffizientes, kostengünstiges Mehrbenutzersystem zu realisieren. Die 3-Ebenen-Architektur erlaubt es, eine große Anzahl von Benutzern mit billigen und langsamen Endgeräten auf eine kleine Anzahl von Workprozessen auf teuren und schnellen Applikationsservern abzubilden.. Jedem Workprozeß eines Applikationsservers ist ein Workprozeß auf einem (teuren) Datenbankserver zugeordnet. Beim Userdispatching werden die einzelnen Clients auf der Präsentationsserverebene für bestimmte Zeitintervalle einem Workprozeß zugeordnet, der seinerseits für diese Zeitdauer einen Workprozeß der Datenbank nutzt. Nach der Verarbeitung der Benutzereingaben eines Dialogschritts, wird der Benutzer mit seinem Benutzer- und Programmkontext aus dem Workprozeß "herausgerollt" und der Workprozeß kann von einem anderen Benutzer verwendet werden. Die 3-Ebenen-Architektur hat sich als deutlich skalierbarer (hinzufügen von weiteren Benutzern) herausgestellt, als eine "Fat"-Client-Architektur, bei der die Präsentationsebene und die Applikationsserverebene auf einem Sever ablaufen. Bei der 3-Ebenen-Architektur werden weniger Datenbank-Schattenprozesse benötigt als bei einer "Fat"-Client-Architektur. Daher sind die Kosten der 3-Ebenen-Architektur geringer. 3

4 R/3 multi-tier C/S Architecture Presentation WAN Internet Customer Service Rep Create Production Production Order Orders Plant Personnel Accept Customer Order Explode Bill-of- Material Reserve Material Release Production Orders Build Products Customer Order Schedule Part Material Production Task Confirm Delivery Application Database Thomas Arend SAP AG Jena 99 June,

5 R/3 Client Server Konfiguration Central System / Laptop Distributed Presentation SAP R/3 System Presentation Application Database Two-tier Client/Server Fat client Three-tier Client/Server Multi-Layer Cooperative Client/Server Thomas Arend SAP AG Jena 99 June,

6 Types of Processes and Application servers Message Dialog Update V M D Batch B SAP-Dispatcher Spool S Enqueue E Gateway R/2 G R/3 Thomas Arend SAP AG Jena 99 June,

7 Plattformunabhängigkeit des R/3 Hardware UNIX Systems Bull Digital HP IBM SNI SUN AT&T Bull/Zenith Compaq... Data General HP (Intel) IBM (Intel) Sequent SNI Digital (Intel) IBM AS/400 Operating Systems AIX Digital UNIX HP-UX Reliant UNIX (SINIX) SOLARIS Windows NT OS/400 Databases ADABAS D DB2 for AIX INFORMIX-OnLine ORACLE ADABAS D MS SQL Server ORACLE DB2/400 Dialog SAP-GUI Windows 3.1, Windows 95, Windows NT, OSF/Motif, Presentation Manager, Macintosh Windows 95 OS/2 Languages ABAP/4, C, C+ + Thomas Arend SAP AG Jena 99 June,

8 R/3 Repository Thomas Arend SAP AG Jena 99 June,

9 Begriffsdefinition Transaktion Dialogprogramm mit einem oder mehreren Bildschirmbildern, das Objekte in der Datenbank in konsistenter Weise ändert. Mit Hilfe der Development Workbench in ABAP/4 können Transaktionen entwickelt werden, die in einer verteilten Client/Server Umgebung arbeiten. Logical Unit of Work (LUW) Eine in sich abgeschlossene Gruppe von Arbeitsschritten innerhalb einer Transaktion. Alle diese Schritte müssen korrekt abgeschlossen sein, bevor die LUW als Teil der Transaktion beendet wird (COMMIT). Wenn vor dem Abschluß einer Transaktion ein Fehler auftritt, werden alle Änderungen in der LUW verworfen (ROLLBACK), nicht aber die in vorhergehenden LUWs dieser Transaktion Thomas Arend SAP AG Jena 99 June, Da in R/3 viele verschiedene Benutzer und Anwendungen über viele verschiedene Transaktionen auf dieselbe Datenbank zugreifen können, müssen Schutzfunktionen eingerichtet werden, die verhindern, daß ein Benutzer durch einen falschen Tabelleneintrag die gesamte Datenbank beschädigt. Deshalb gibt es einen separaten Sperrmechanismus und ein spezielles Konzept zur Definition einer LUW. LUWs gewährleisten Konsistenz der Datenbank Ein Sperrmechanismus sorgt dafür, daß zu einem gegebenen Zeitpunkt immer nur ein Benutzer ein Datenobjekt ändern kann. 9

10 SAP-LUW Elementarer betriebswirtschaftlicher Vorgang Prozeßschritt 1 Prozeßschritt 2... Prozeßschritt n SAP-LUW Thomas Arend SAP AG Jena 99 June, Eine SAP-LUW (Logical Unit of Work) realisiert eine logisch zusammenhängende Einheit von Prozeßschritten eines betriebswirtschaftlichen Vorgangs in einem R/3-System. Die Schritte der Prozeßkette des betriebswirtschaftlichen Vorgangs müssen logisch zusammenhängend sein. In einer SAP-LUW werden entweder alle Schritte der zugehörigen Prozeßkette (umgesetzt in Datenbankänderungen) durchgeführt oder gar keiner (Alles-Oder-Nichts-Prinzip). Der abzubildende betriebswirtschaftliche Vorgang muß elementar sein. Das Eingehen einer Kundenbestellung bis zur Erstellung der Faktura wird i.a. nicht durch eine SAP-LUW abzubilden sein. Vielmehr wird man den betriebswirtschaftlichen Prozeß in logisch separat auszuführende Teile zerlegen, und diese Teile dann durch einzelne SAP-LUWs im R/3-System realisieren. Die Beurteilung, was ein "elementarer" Vorgang ist, hängt vom Gesamtvorgang und dessen Modellierung ab. 10

11 Datenbank-LUW Datenbankoperationen Zwischenzustände insert, update, delete Konsistenter Zustand 1 Konsistenter Zustand 2 ROLLBACK DB-COMMIT Thomas Arend SAP AG Jena 99 June, Eine Datenbank-LUW (DB Logical Unit of Work) ist eine nicht teilbare Folge von Datenbankoperationen, die die Datenbank von einem konsistenten Zustand in einen anderen überführen. Die Datenbank-LUW wird vom Datenbanksystem entweder vollständig oder überhaupt nicht ausgeführt (atomarer Prozeß). Eine Datenbank-LUW wird sowohl beim Starten einer Transaktion (Öffnen einer Verbindung zur Datenbank), als auch durch einen Datenbank-Commit der vorhergehenden DB-LUW eröffnet. Die Datenbank-LUW wird abgeschlossen mit einem Datenbank-Commit. Erst dadurch werden die Daten unwiderruflich auf der Datenbank fixiert. Vorher können Sie beim Auftreten eines Fehlers durch einen Datenbank-Rollback wieder zurückgenommen werden. Mit einer Datenbank-LUW können betriebswirtschaftlich zusammengehörende Aktionen, die einen abgeschlossenen Vorgang darstellen, abgebildet werden. Zum Beispiel muß bei einer Überweisung im Finanzwesen ein Betrag von einem Konto abgebucht und danach auf ein anderes Konto gutgeschrieben werden. Zwischen den beiden Buchungsschritten ist der Datenzustand evtl. inkonsistent. 11

12 Impliziter DB-COMMIT Bildschirm 1 Bildschirm 2 Bildschirm 3 DB-COMMIT DB-COMMIT DB-COMMIT DB-LUW 1 DB-LUW 2 DB-LUW 3 DB-LUW 4 Zeit Thomas Arend SAP AG Jena 99 June, Die 3-Ebenen-Architektur hat Auswirkungen auf das Process-Handling: Beim Freigeben eines Workprozesses, der dann einen anderen Benutzer (Client) bedienen kann, wird für den dem Workprozeß zugeordnete Datenbankprozeß ein impliziter Datenbank-COMMIT ausgelöst. Die Freigabe des Workprozesses auf dem Applikationsserver sowie auf der Datenbank erfolgt nach jedem Benutzerdialog. Damit ist gewährleistet, daß die unter Umständen langwierigen Benutzerdialoge ("Frühstückspause"), in denen "nur Bildschirmbilder" angezeigt werden, aus den Datenbank-LUWs herausgenommen werden. Damit ist die Lebensdauer einer DB-LUW i.a. sehr viel kürzer als die Dauer für die Anzeige eines Bildes. Kurze DB-LUWs bedeuten eine geringere Belastung der Datenbankresourcen. Implizite Commits auf der Datenbank werden bei jedem Benutzerdialog ausgelöst. Dazu zählen: das Senden eines SAP-Bildschirmbildes das Senden einer Dialognachricht der Aufruf eines RFC (Remote Function Call) evtl. mittelbar durch Bildwechsel nach einem Aufruf per CALL TRANSACTION <t_code> oder SUBMIT <program>. 12

13 DB-Änderungen einer SAP-LUW bündeln SAP-LUW Benutzerdialoge ABAP- Programm DB-Änderungen DB- LUW Thomas Arend SAP AG Jena 99 June, Die Abbildung einer betriebswirtschaftlichen Prozeßkette mit Hilfe einer SAP-LUW umfaßt sowohl Benutzerdialoge als auch die Änderungen aus einem Datenbankdialog. Ziel einer Transaktion ist es, die Informationen, die während des Benutzerdialogs der SAP-LUW ausgetauscht werden, in unteilbarer Form auf der Datenbank abzubilden. Dazu muß eine SAP-LUW auf eine Datenbank- LUW abgebildet werden. Da sich eine SAP-LUW i.a. über mehrere DB-LUWs erstreckt, ergibt sich für die Programmierung einer Transaktion das Ziel, die Anteile des Datenbankdialogs in einer DB-LUW zu bündeln. 13

14 Bündelung: verzögerte Inline-Änderungen SAP-LUW Globale Daten des Programms Daten Verarb. block 1 Daten Verarb. block 2... Daten Letzter Dialogschritt Änderungsanforderungen DB-Commit Thomas Arend SAP AG Jena 99 June, Sollen Benutzerdialog und Datenbankänderungen im Wechsel stattfinden, müssen Sie den Anteil, der die Datenbankänderungen beinhaltet, auf einen Dialogschritt (i.a. der letze Dialogschritt) beschränken. Nur damit ist die Durchführung der Datenbankänderungen als ganzes (Alles-oder- Nichts-Prinzip) gewährleistet. Hierzu müssen Sie die auf der Datenbank zu ändernden Daten bis zur Datenbankänderung in den globalen Programmdaten speichern. Das Ende der SAP-LUW kann ausgelöst werden durch: das Programmende oder programmgesteuert durch die ABAP-Anweisungen: LEAVE PROGRAM oder COMMIT WORK.. Beachten Sie, daß falls Ihr Programm mit dem logischen Sperrkonzept der SAP arbeitet, Sie die Sperreinträge programmgesteuert löschen müssen. Hierzu können Sie den Funktionsbaustein DEQUEUE_ALL verwenden. 14

15 Bündelung mit Hilfe von Unterprogrammen SAP-LUW 1 Globale Daten des Programms Daten Daten Daten PERFORM x ON COMMIT. PERFORM y ON COMMIT.... COMMIT WORK. FORM x... FORM y Ausführungsliste Formroutine x Formroutine y... Änderungen DB-Commit Thomas Arend SAP AG Jena 99 June, Die Bündelung von Datenbankänderungen in einer Datenbank-LUW wird vom System durch die Anweisung PERFORM <program> ON COMMIT unterstützt. Die Anweisung PERFORM <subroutine> ON COMMIT registriert das aufgerufene Unterprogramm zur Ausführung. Die Ausführung wird zurückgehalten, bis das System auf die nächste COMMIT WORK Anweisung trifft. Damit lassen sich die direkten Datenbankänderungen in den Unterprogrammen von der Programmlogik trennen und an das Ende der SAP-LUW verlagern. Die Anweisung COMMIT WORK führt alle zur Ausführung registrierten Unterprogramme nacheinander aus, löst dann einen Datenbank-Commit aus ( beendet die DB-LUW) und beendet die aktuelle SAP-LUW. Ist das Programm mit dem COMMIT WORK noch nicht zu Ende, eröffnet die Anweisung automatisch eine neue SAP-LUW. Die Unterprogramme, die mit dem Zusatz ON COMMIT aufgerufen werden, besitzen im Gegensatz zu gewöhnlichen Unterprogrammen keine Schnittstelle. Sie arbeiten mit globalen Daten, d.h. mit den Werten der Variablen zum Zeitpunkt der tatsächlichen Ausführung des Unterprogramms. 15

16 Bündelung durch Verbuchung: Prinzip Protokolltabelle 1 Vormerkung 1... Daten Workprozeß 1 Dialogprogramm Vormerkung n Daten lesen asynchron synchron lokal 2 Workprozeß 2 Verbuchungsprogramm Einträge löschen 4 3 Datenbank- Änderungen Thomas Arend SAP AG Jena 99 June, Zeit Transaktionen, die mit einer Verbuchungstechnik arbeiten, bestehen aus zwei Programmen: einem Dialogprogramm und einem Verbuchungsprogramm. Das Dialogprogramm führt den Benutzerdialog (Hintergrundverarbeitung ist ebenfalls möglich), das Verbuchungsprogramm führt die Datenbankänderungen durch. Der Verarbeitungsablauf bei der Verbuchung erfolgt in 4 Schritten: 1. Das Dialogprogramm schreibt die für die Datenbankänderungen benötigten Informationen in eine Protokolltabelle. 2. Das Verbuchungsprogramm wird gestartet und liest die Informationen aus der Protokolltabelle. 3. Das Verbuchungsprogramm führt die Datenbankänderungen durch. 4. Für den Fall, daß die Datenbankänderungen erfolgreich verlaufen sind, löscht der Workprozeß, in dem das Verbuchungsprogramm läuft, im letzten Verarbeitungsschritt die zugehörigen Einträge aus der Protokolltabelle. Für den Fall, daß bei den Datenbankänderungen ein Fehler aufgetreten ist, werden die Einträge in der Protokolldatei als fehlerhaft gekennzeichnet und der Anwender über den Abbruch der Verbuchung per Mail unterrichtet. (Das Versenden der Mail ist über den Parameter rdisp/vb_mail einstellbar.) Durch den Einsatz spezieller Techniken kann das Verbuchungsprogramm zeitlich entkoppelt vom Dialogprogramm (asynchrone Verbuchung) oder unmittelbar nach dem Dialogprogramm (synchrone und lokale Verbuchung) ausgeführt werden. 16

17 Rollback im Dialogprogramm PROGRAM... MODULE user_command INPUT.... CASE save_ok. WHEN BACK.. MESSAGE Axxx. * ROLLBACK WORK. WHEN SAVE.. COMMIT WORK. ENDCASE.... ENDMODULE. Löschen aller bis dahin geschriebenen Vormerkungen Thomas Arend SAP AG Jena 99 June, Im Laufe eines viele Schritte umfassenden Dialogs können Sie eine Fülle von Änderungsvormerkungen sammeln, die Sie dann durch ein explizites COMMIT WORK ausführen lassen. Es kann jedoch auch nötig sein, alle Änderungsvormerkungen der aktuellen SAP-LUW durch ROLLBACK WORK zu löschen. Die ABAP-Anweisung ROLLBACK WORK führt folgende Aktionen durch: Löschen aller mit PERFORM <subroutine> ON COMMIT registrierten Formroutinen Löschen aller Änderungsvormerkungen in der Protokolldatei Auslösen eines Rollbacks auf der Datenbank mit anschließendem Datenbank-Commit Beginn einer neuen SAP-LUW Bezogen auf bereits im Dialog vollzogene Datenbankänderungen bedeutet die ROLLBACK WORK Anweisung: Alle Änderungen der aktuellen DB-LUW werden rückgängig gemacht. Die Anweisung ROLLBACK WORK beendet das Dialogprogramm nicht Daher sollten Sie sie nicht direkt verwenden, sondern einen impliziten Rollback durch Ausgeben einer Abbruch- Dialognachricht auslösen. Damit ist gewährleistet, daß auch alle im Programm gesammelten Daten beim Abbruch zurückgesetzt werden. 17

18 Rollback im Verbuchungsprogramm FUNCTION-POOL FUNCTION UPDATE... IF sy-subrc NE 0. MESSAGE Annn... ENDIF.... INSERT... IF sy-subrc NE 0. MESSAGE Annn... ENDIF.... ENDFUNCTION. ROLLBACK WORK Impliziter Rollback auf der Datenbank Thomas Arend SAP AG Jena 99 June, Aufgabe eines Verbuchungsfunktionsbausteins ist es, die Änderungsanforderungen an die Datenbank zu geben und deren Rückmeldungen (Returncodes) auszuwerten. Konnte die Datenbank die Änderung nicht erfolgreich durchführen, muß im Verbuchungsfunktionsbaustein darauf reagiert werden. Wollen Sie in der Verbuchung einen Datenbank-Rollback auslösen, geben Sie eine Abbruch- Dialognachricht aus. Diese bewirkt einen Datenbank-Rollback. Der Datenbank-Rollback beendet die Verbuchung. Der zur SAP-LUW gehörende Protokollsatz wird als fehlerhaft gekennzeichnet und die Abbruch-Dialognachricht selbst wird in den Protokollsatz eingetragen. Der Benutzer wird über ein Expreß-Mail benachrichtigt, daß die Verbuchung abgebrochen wurde. Der Protokollsatz kann anschließend analysiert werden (siehe Monitorfunktion Verbuchung: Transaktion SM13). Die expliziten ABAP-Anweisungen COMMIT WORK und ROLLBACK WORK dürfen Sie im Verbuchungsfunktionsbaustein nicht verwenden. 18

19 Anweisungen für Datenbankdialoge Open-SQL SELECT... INSERT... UPDATE... DELETE... MODIFY... Native-SQL EXEC SQL. CREATE TABLE... ENDEXEC.... Vorteile/Nachteile - unabhängig von Datenbank - Möglichkeit mit Puffern zu arbeiten - Einbettung in ABAP Vorteile/Nachteile - datenbankspezifisch - nicht bei gepufferten Tabellen Thomas Arend SAP AG Jena 99 June, Für Datenbankdialoge stehen Ihnen im SAP-System sowohl die Befehle aus dem OPEN-SQL des ABAP als auch der jeweilige datenbankspezifische Befehlssatz des Native-SQL zur Verfügung. Die Verwendung der Befehle aus dem OPEN-SQL hat die Vorteile der Integration in das Konzept der Programmiersprache ABAP (Schleifenverarbeitung mit der SELECT-Leseschleife, Teilnahme an den Pufferungsstrategien der SAP-Applikationsserver) sowie der Plattformunabhängigkeit. Ein Nachteil des OPEN-SQL besteht darin, daß u.u. nicht der volle Funktionsumfang der Datenbank genutzt wird. Die Verwendung von Native-SQL-Befehlen bietet den Vorteil, den vollständigen Befehlssatz der jeweiligen Datenbank einsetzen zu können. Dieser ist i.a. größer als der datenbankunabhängige Befehlssatz des OPEN-SQL. Native-SQL-Befehle durchlaufen bei Ihrer Ausführung nicht die Datenbankschnittstelle des R/3- Systems. Daher finden Lese- oder Veränderungszugriffe auf die Datenbank immer ohne Beachtung der Tabellenpuffer des R/3-Systems statt. Somit dürfen Native-SQL-Befehle nicht bei gepufferten Tabellen eingesetzt werden, da sonst die Gefahr besteht, sich Inkonsistenzen zwischen Datenbanktabelle und Pufferinhalt auf der Datenbank einzuhandeln. 19

20 Asynchrone Verbuchung Zeit Protokoll- tabelle Dialog- WP 1 COMMIT WORK. Verbuchungs-WP VBLOG Text Vormerkung 1... Vormerkung n SAP-LUW 1, Dialogprogramm SAP-LUW 1, Verbuchungsprogramm SAP-LUW 2, Dialogprogramm DB Thomas Arend SAP AG Jena 99 June, Bei der asynchronen Verbuchung sind Dialogprogramm und Verbuchungsprogramm zeitlich entkoppelt. Das Dialogprogramm schreibt die Änderungsvormerkungen in die Protokolltabelle VBLOG auf der Datenbank. Sie schließen den Dialogteil der SAP-LUW im Dialogprogramm mit der Anweisung COMMIT WORK ab. Im Dialogprogramm startet sofort eine neue SAP-LUW, deren Benutzerdialoge sofort durchgeführt werden können, d.h. das Dialogprogramm arbeitet ohne Unterbrechung weiter. Es wird nicht auf die Ausführung des Verbuchungsprogramms gewartet. Das Verbuchungsprogramm wird in einem speziellen Verbuchungsworkprozeß, der sich auf einem anderen Server des R/3-Systems befinden kann, asynchron ausgeführt. Die im Dialogprogramm begonnene SAP-LUW wird in dem Verbuchungsprogramm fortgeführt und abgeschlossen. Die Protokolltabelle VBLOG kann in Ihrem System in Abhängigkeit von der Datenbank als Clusterdatei realisiert, oder durch die transparenten Tabellen VBHDR, VBMOD, VBDATA und VBERROR ersetzt sein. Die asynchrone Verbuchung eignet sich für Transaktionen, bei denen die Datenbankänderungen lange Antwortzeiten verursachen würde, die Performance des Benutzerdialogs jedoch im Vordergrund steht. 20

21 Synchrone Verbuchung Zeit Verbuchungs-WP Dialog- WP 1 COMMIT WORK AND WAIT. VBLOG Text Vormerkung 1... Vormerkung n Protokoll- tabelle SAP-LUW 1, Dialogprogramm SAP-LUW 1, Verbuchungsprogramm SAP-LUW 2, Dialogprogramm DB Thomas Arend SAP AG Jena 99 June, Bei der synchronen Verbuchung wartet das Dialogprogramm auf das Ende des Verbuchungsprogramms. Erst wenn das Verbuchungsprogramm beendet ist, startet das Dialogprogramm mit der Verarbeitung der zweiten SAP-LUW. Das Umschalten von der asynchronen auf die synchrone Verbuchung geschieht durch den Zusatz AND WAIT bei der Anweisung COMMIT WORK. 21

22 Lokale Verbuchung Zeit Protokoll- tabelle Workprozeß SET UPDATE TASK LOCAL. 1 COMMIT WORK. 2 Hauptspeicher Vormerkung 1... Vormerkung n SAP-LUW 1, Dialogprogramm SAP-LUW 1, Verbuchungsprogramm SAP-LUW 2, Dialogprogramm DB Thomas Arend SAP AG Jena 99 June, Bei der lokalen Verbuchung wird das Verbuchungsprogramm mit dem Dialog-Workprozeß ausgeführt, in dem sich das Dialogprogramm vor dem COMMIT WORK befindet. Dazu muß im Dialogprogramm vor dem Aufruf der Verbuchungsfunktionsbausteine, die lokal ausgeführt werden sollen, mit der Anweisung SET UPDATE TASK LOCAL auf lokale Verbuchung umgeschaltet werden. Die Änderungsvormerkungen werden dann nicht mehr in die Datenbanktabelle VBLOG geschrieben, sondern im Hauptspeicher gehalten. Beim Prozessieren des ABAP-Befehls COMMIT WORK werden die zugehörigen Verbuchungsfunktionsbausteine im aktuell durch das Dialogprogramm belegten Dialog-Workprozeß ausgeführt. Ein Datenbank-Commit wird erst nach erfolgreicher Abarbeitung aller Verbuchungsfunktionsbausteine durchgeführt. Im Fehlerfall wird ein Datenbank-Rollback ausgelöst. Nach Abarbeitung der Verbuchungsfunktionsbausteine wird das Dialogprogramm mit einer neuen SAP-LUW fortgesetzt. 22

23 SAP-LUW: Zeitlicher Verlauf bei Verbuchung Zeit synchron asynchron lokal Dialog Dialog Verbuchung Verbuchung Dialog SET UPDATE TASK LOCAL COMMIT WORK AND WAIT. 2 COMMIT WORK. 3 2 COMMIT WORK SAP-LUW 1, Dialogprogramm SAP-LUW 1, Verbuchungsprogramm SAP-LUW 2, Dialogprogramm Thomas Arend SAP AG Jena 99 June, Die Verwendung der asynchronen Verbuchung bietet sich bei Transaktionen an, bei denen der weitere Benutzerdialog nicht auf das Ergebnis der Datenbankänderungen warten muß. Nach Aufruf der Verbuchung geht die Kontrolle sofort wieder an den Benutzer über.. Die synchrone Verbuchung empfielt sich für Transaktionen, die die Vorteile einer Verbuchungstechnik (Protokollierung, Möglichkeit zur Nachverbuchung) nutzen wollen, aber die weitere Bearbeitung des Dialogteils von den Ergebnissen des Verbuchungsteils abhängen. Eine wichtige Anwendung besteht in dem Anlegen von sog. Rahmentransaktionen, die bestehende Transaktionen als Modularisierungseinheiten programmgesteuert hintereinander ausführen. Bei der programmgesteuerten ausführung von Transaktionen (CALL TRANSACTION <t_code>) kann beim Aufruf festgelegt werden, mit welcher Verbuchungstechnik die Transaktion ablaufen soll. Die lokale Verbuchung eignet sich besonders für die Abarbeitung von Dialogtransaktionen im Hintergrund.Bei dieser Ablaufart entfällt die Kommunikation mit der Datenbanktabelle VBLOG. Im Fall, daß das Programm alleine auf dem Server abläuft, wird es bei lokaler Verbuchung schneller ausgeführt als bei synchroner oder asynchroner Verbuchung. Im Fall meherer Benutzer auf dem Server (Regelfall), hängt die Geschwindigkeit des Programms von der Gesamtbelastung des Servers ab. 23

24 Was passiert bei Commit Work? Ausführung aller mit PERFORM... ON COMMIT registrierter Unterprogramme Schreiben des Verbuchungsheaders; Abschluß der Verbuchungsvormerkungen Registrierung des Verbuchungspakets für die Verbuchung Auslösen eines impliziten Datenbank-Commits Beenden des Dialogteils der alten und Eröffnen einer neuen SAP-LUW Im Regelfall werden Sperren an die Verbuchung übergeben. ABER: SAP-Sperren werden erst nach der Verbuchung freigegeben! Thomas Arend SAP AG Jena 99 June, Der ABAP-Befehl COMMIT WORK löst eine Reihe von Verarbeitungen aus: Zuerst werden alle Unterprogramme, die mit dem Zusatz ON COMMIT aufgerufen wurden, ausgeführt. Im zweiten Schritt werden die Änderungsvormerkungen, die bis zu diesem Zeitpunkt erzeugt wurden, durch das Schreiben der HEADER-Informationen zum aktuellen Verbuchungsschlüssel abgeschlossen. Die durch den HEADER abgeschlossenen Einträge werden für die Verbuchung registriert. Bei lokaler Verbuchung wird dieser Schritt durch das Ausführen der V1- Verbuchungsfunktions-bausteine ersetzt. Dann wird ein Datenbank-Commit durchgeführt. Im letzten Schritt wird die alte SAP-LUW abgeschlossen und eine neue eröffnet. Beachten Sie bitte: Das Auslösen des Datenbank-Commits durch den Befehl COMMIT WORK verbietet die Verwendung verschiedenartiger Bündelungstechniken. Insbesondere sollten direkte Datenbankänderungen sowie die Verwendung von PERFORM <subroutine> ON COMMIT zur Bündelung von Inline-Änderungen nicht mit Verbuchungstechniken zusammen eingesetzt werden. Datenbankänderungen aus dem Dialogprogramm und aus dem Verbuchungsprogramm sind zusammen nicht rollback-fähig. Der ABAP-Befehl COMMIT WORK gibt keine SAP-Sperren frei. 24

25 Warum müssen Sperren gesetzt werden? Tabelle 1 Programm A Programm B Tabelle 4 Tabelle 3 Tabelle 6 Tabelle 2 Tabelle 5 Thomas Arend SAP AG Jena 99 June, Wenn mehrere Benutzer konkurrierend auf mindestens eine Ressource zugreifen, müssen sie sich in geeigneter Weise synchronisieren, um die Konsistenz der Daten zu gewährleisten. Beispiel: In einem Flugbuchungssystem muß bei der Reservierung überprüft werden, ob noch Plätze frei sind. Erst dann kann eine Reservierung vorgenommen werden. Für die Dauer eines Reservierungs-Dialogprogramms muß garantiert sein, daß kein anderer Benutzer auf die kritischen Daten zugreift (z.b. die Anzahl freier Plätze). Ein geeignetes Mittel, um konkurrierende Zugriffe auf Ressourcen zu koordinieren, sind Sperren. Jeder Benutzer fordert eine Sperre an, bevor er auf kritische Daten zugreift. Damit andere Benutzer in ihrer Arbeit nicht unnötig behindert werden, ist es wichtig, Sperren nur so lange wie nötig zu halten. 25

26 Datenbanksperren COMMIT (implizit) COMMIT (implizit) COMMIT WORK (explizit) UPDATE UPDATE INSERT INSERT SELECT SELECT FOR FOR UPD UPD DELETE DELETE Sperren Thomas Arend SAP AG Jena 99 June, Werden in einem Dialogprogramm Datenbankänderungsanweisungen direkt ausgeführt, so setzt das Datenbanksystem entsprechende Sperren. Das Datenbankmanagementsystem (DBMS) sperrt zu ändernde Tabelleneinträge (INSERT UPDATE, MODIFY) und mit Änderungsabsicht (SELECT SINGLE <f> FROM <dbtab> FOR UPDATE) gelesene Tabellenzeilen physisch. D.h. andere Benutzer müssen für die Dauer der physischen Sperre warten, bis die Sperren aufgehoben sind. Am Ende einer Datenbanktransaktion gibt das Datenbanksystem alle während der Datenbanktransaktion gesetzten Sperren frei. Da vom SAP-System bei jedem Bildwechsel implizit eine Commit-Anforderung an das Datenbanksystem ergeht, gelten die während eines Dialogschritts gesetzten Datenbanksperren längstenfalls bis zum Ende dieses Dialogschritts. 26

27 SAP Sperrkonzept SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI Dialog WP Dispatcher... Dialog WP Message- Server WP. WP.. Dispatcher Enqueue WP Sperrtabelle DB-Workprozesse Thomas Arend SAP AG Jena 99 June, Um Sperren auch über Bildwechsel sowie über Dialog- und Verbuchungsprogramm aufrecht erhalten zu können gibt es auf Applikationsserverebene eine für das R/3-System globale Sperrtabelle, mit der Tabelleneinträge logisch gesperrt werden können. Auf genau einem der Applikationsserver gibt es eine Sperrtabelle, sowie einen speziellen Enqueue- Workprozeß, der die Sperranforderungen für die Sperrtabelle administriert. Alle logischen Sperranforderungen des R/3-Systems laufen über diesen Workprozeß. Mit Hilfe von logischen Sperren können auch Tabelleneinträge "gesperrt" werden, die auf der Datenbank noch nicht existieren (Einfügen neuer Tabellenzeilen). Dies ist mit Hilfe von Datenbanksperren nicht möglich. 27

28 Logische Sperren setzen Programm Erzeuge Sperreintrag Sperrtabelle Antwort = Returncode Sperre erfolgreich gesetzt Sperre konnte nicht gesetzt werden, da - Objekt bereits gesperrt ist - ein Systemfehler auftrat Thomas Arend SAP AG Jena 99 June, Sperren werden erzeugt, indem ein Eintrag in die Sperrtabelle geschrieben wird. Das geschieht mit Hilfe von Funktionsbausteinen. Das Absetzen eines Sperreintrags gelingt nur, wenn für die betreffenden Tabellensätze bisher noch keine Sperreinträge vorhanden sind. Auskunft über den Erfolg einer Sperranforderung bekommt die SAP-Transaktion über einen Returncode. Durch Auswerten des Returncodes kann die SAP-Transaktion entsprechend reagieren. Möchte ein weiterer Benutzer mit einer SAP-Transaktion ebenfalls dieselben Tabellensätze bearbeiten, kann er durch eine entsprechende Error-Message abgewiesen werden. Am Ende der Verarbeitung müssen bei Inline-Änderungen die Sperren durch das Dialogprogramm explizit freigegeben werden. Im Falle der V1-Verbuchung werden die Sperren i.a. an den Verbuchungsworkprozeß übergeben, in dem das Verbuchungsprogramm ausgeführt wird. Der Verbuchungsworkprozeß löscht nach Abarbeitung des Verbuchungsprogramms alle ihm übergebenen Sperreinträge automatisch. Bricht der Benutzer das Dialogprogramm ab, werden die Sperren automatisch (implizit) freigegeben (Befehlsfeldeingabe /n, die Anweisungen LEAVE PROGRAM, LEAVE TO TRANSACTION, A- Message). 28

29 Zusammenfassung SAP-Transaktionen Programme, die mit Hilfe des Konzeptes der SAP-LUW die Daten, die während eines Benuzerdialoges ausgetauscht werden, innerhalb einer Datenbank-LUW konsistent auf die Datenbank abbilden. Bündelungstechnik Das SAP-System stellt mehrere Bündelungstechniken zur Verfügung, mit deren Hilfe eine SAP-LUW auf eine Datenbank- LUW abgebildet werden kann. SAP Sperrkonzept Zur Gewährleistung der Datenkonsistenz während der Datenbankänderungen Thomas Arend SAP AG Jena 99 June,

30 Aufruf einer Transaktion Programm 1 MODULE... INPUT.... CALL TRANSACTION TCGB. * AND SKIP FIRST SCREEN.... ENDMODULE. Programm 1: Transaktion 1. Dynpro 2. Dynpro F15 SAPMTCGB TCGB MODULE... INPUT.... LEAVE PROGRAM.... ENDMODULE. Thomas Arend SAP AG Jena 99 June, Mit der Anweisung CALL TRANSACTION <t_code> können Sie ABAP-Programme, die einen Transaktionscode <t_code> besitzen, ausführen. Nach Beendigung des gerufenen Programms wird die Verarbeitung des rufenden Programms fortgesetzt. Falls die mit CALL TRANSACTION <t_code> gerufene Transaktion mit einer Verbuchungstechnik arbeitet, können sie über den Parameter FUNCTION beim Aufruf steuern, mit welcher Verbuchungstechnik (synchron oder asynchron) die Transaktion ablaufen soll. Durch die Anweisung LEAVE PROGRAM können Sie die Beendigung eines ABAP-Programms erzwingen. Im Fall, daß diese Anweisung in einem Programm ausgeführt wird, das durch CALL TRANSACTION <t_code> oder SUBMIT <program> AND RETURN aufgerufen wurde, wird das rufende Programm fortgesetzt. Andernfalls kommen Sie in das Anwendungsmenü zurück, aus dem das rufende Programm gestartet wurde. Mit der Anweisung LEAVE TO TRANSACTION <t_code> starten Sie die Transaktion mit dem Transaktionscode <t_code>. Eine Rückkehr zur Aufrufstelle ist hierbei nicht möglich. Die Anweisung entspricht der Befehlsfeld-Eingabe /n<t_code>. 30

31 Synchrone Programmaufrufe: Belegung des Hauptspeichers Externer Modus 1 Interner Modus 2 Externer Modus 1 nach dem Aufruf 2 Programm 2 3 Interner Modus 1 Programm 1 1 Funktions- gruppe 3 4 Interner Modus 1 Programm 3 1 CALL FUNCTION 2 CALL TRANSACTION, SUBMIT <p> AND RETURN 3 4 LEAVE TO TRANSACTION SUBMIT <p> Thomas Arend SAP AG Jena 99 June, Die unterschiedlichen Aufrufmöglichkeiten für Programme (ABAP-Programme mit und ohne Transaktionscode) oder Programmteile (Funktionsbausteine) unterscheiden sich hinsichtlich der Programmkontexte, die sie im Hauptspeicher erzeugen. Einzelheiten zu Programmkontexten finden Sie im Anhang. Die Aufteilung des Hauptspeichers aus Sicht von ausführbaren Programmen läßt sich in einem logischen Speichermodell erklären. Hierin sind Externe Modi und Interne Modi zu unterscheiden. Ein Externer Modus ist i.d.r. an ein R/3-Fenster gebunden. Er kann durch den Menüeintrag System / Neuer Modus oder durch den Aufruf /o<t_code> erzeugt werden. Innerhalb eines Externen Modus finden weitere Unterteilungen in sog. Interne Modi statt. Die Daten eines Programms sind nur innerhalb eines Internen Modus sichtbar. Ein Externer Modus kann in bis zu 20 Interne Modi unterteilt werden (Stapel). Programme, die mit CALL TRANSACTION <t_code>, SUBMIT <program> AND RETURN aufgerufen werden, laufen in je einem internen Modus zum gleichen externen Modus, in dem auch das rufende Programm lauft. Die Daten des rufenden Programms sind im gerufenen Programm nicht sichtbar (und umgekehrt). Funktionsbausteine laufen im gleichen internen Modus ab, wie das rufende Programm. Tabellenarbeitsbereiche werden in der Funktionsgruppe doppelt gehalten. Programme, die mit SUBMIT <program> oder LEAVE TO TRANSACTION <t_code> gerufen werden, werden in einem neuen internen Modus zum gleichen externen Modus ausgeführt. Das rufende Programm wird beendet. Einzelheiten hierzu finden Sie im Anhang. 31

32 Synchrone Programmaufrufe: SAP-LUWs Art des Aufrufs Beteiligte SAP-LUWs - SUBMIT <prog2>. - LEAVE TO TRANSACTION <t_code>. SAP-LUW1 Programm 1 SAP-LUW2 prog2 / t_code Zeit - SUBMIT <prog2> AND RETURN. - CALL TRANSACTION <t_code>. SAP-LUW1 Programm 1 SAP-LUW2 SAP-LUW1 prog2 / t_code Programm 1 Zeit - CALL FUNCTION <f_name>. Programm 1 SAP-LUW1 f_name Programm 1 Zeit Thomas Arend SAP AG Jena 99 June, Programme, die mit den Anweisungen SUBMIT <program>, LEAVE TO TRANSACTION <t_code>, SUBMIT <program> AND RETURN oder CALL TRANSACTION <t_code> aufgerufen werden, laufen in einer eigenen SAP-LUW (Verbuchungsaufträge bekommen einen eigenen Verbuchungsschlüssel!). Bei SUBMIT <program>. und LEAVE TO TRANSACTION <t_code> wird die SAP-LUW des rufenden Programms beendet. Falls Sie vor dem Programmaufruf keine Anweisung COMMIT WORK prozessiert haben, stehen die Verbuchungsaufträge des rufenden Programms unabgeschlossen in der Protokolltabelle. Sie können nicht mehr ausgeführt werden. Gleiches gilt für Inline-Änderungen, die mit Hilfe der Technik PERFORM... ON COMMIT durchgeführt werden sollten. Daten, die durch Inline-Änderungen auf die Datenbank geschrieben wurden werden beim nächsten Bildwechsel kommitiert. Falls Sie die Verarbeitung eines neuen Programms per SUBMIT <program> AND RETURN oder CALL TRANSACTION <t_code> in die Verarbeitung des aktuellen Programms einschieben, wird die SAP-LUW des rufenden Programms nach Beendigung des gerufenen Programms fortgesetzt. Die LUW-Verarbeitungen von rufendem und gerufenen Programm sind unabhängig voneinander. D.h. Inline-Änderungen werden jeweils beim nächsten Bildwechsel kommitiert, Verbuchungsaufträge und Aufrufe mittels PERFORM... ON COMMIT benötigen jeweils eine eigenständige Anweisung COMMIT WORK in der SAP-LUW, in der sie ablaufen. Funktionsbausteine laufen in der gleichen SAP-LUW wie das sie rufende Programm. 32

33 Asynchrone Aufrufe Hauptspeicher Modus 1 1 CALL FUNCTION <f_name> STARTING NEW TASK <name>... 1 Hauptspeicher Modus Programm 1 Funktionsbaustein <f_name> Thomas Arend SAP AG Jena 99 June, Funktionsbausteine können nicht nur synchron, sondern auch asynchron ausgeführt werden. Hierzu muß der Aufruf des Funktionsbausteins durch den Zusatz STARTING NEW TASK '<name>' erweitert werden. '<name>' ist hierbei ein symbolischer Name, mit dem der externe Modus, in dem das gerufene Programm ausgeführt wird, im rufenden Programm identifiziert werden kann. Funktionsbausteine, die mit dem Zusatz STARTING NEW TASK '<name>' aufgerufen werden, werden unabhängig vom rufenden Programm ausgeführt. Die Verarbeitung des rufenden Programms wird nicht unterbrochen. Funktionsbausteine, die lokal asynchron aufrufbar sein sollen, müssen als Remote aufrufbar gekennzeichnet werden (Ablaufart: Remote Function Call unterstützt). Funktionsbausteine, die mit dem Zusatz STARTING NEW TASK gerufen werden, können über den weiteren Zusatz DESTINATION '<dest>' auch in anderen R/3-Systemen ausgeführt werden. Einzelheiten hierzu siehe im Abschnitt "Programmaufrufe über RFC". 33

34 Asynchrone Programmaufrufe CALL FUNCTION <f_name> STARTING NEW TASK <name> EXPORTING... Externer Modus 1 Interner Modus 1 Programm 1 zeitlich entkoppelt Externer Modus 2 Interner Modus 1 Funktions- gruppe Thomas Arend SAP AG Jena 99 June, Funktionsbausteine, die mit dem Zusatz STARTING NEW TASK <name> aufgerufen werden, werden in einem vom rufenden Programm verschiedenen externen Modus ausgeführt. Ihre weitere Ausführung ist sowohl zeitlich als auch kausal unabhängig von dem rufenden Programm. Der gerufene Funktionsbaustein wird in einem weiteren freien Workprozeß gestartet. Die Lebensdauer des gerufenen Funktionsbausteins ist unabhängig von der des rufenden Programms. Das rufende Programm wird nach der Ausführung des Aufrufs unabhängig vom aufgerufenen Programm weiter fortgesetzt. Der Parameter '<name>' enthält einen frei wählbaren symbolischen Namen für den gerufen externen Modus. Bei lokalen Aufrufen können Sie den symbolischen Namen ' '(Leerzeichen) verwenden. Funktionsbausteine, die asynchron aufgerufen werden, geben keine Werte über die Schnittstelle des Funktionsbausteins zurück. 34

35 Datenübergabe: Überblick SAP-Memory SET- /GET-Parameter 3 ABAP-Memory 2 Schnittstelle Programm A 1 Programm B 4 DB 5 Thomas Arend SAP AG Jena 99 June, Es gibt verschiedene Möglichkeiten Daten an Programme, die in verschiedenen Programmkontexten (Interne Modi) ablaufen, zu übergeben. Sie können Daten über 1)die Schnittstelle des gerufenen Programms (Standard-Selektionsbild oder Schnittstelle eines Unterprogramms, Funktionsbausteins oder von Dialogbausteinen) 2)das ABAP-Memory 3)das SAP-Memory 4)Datenbanktabellen oder 5)lokale Dateien auf Ihrem Präsentationsserver übergeben. 35

36 Datenübergabe über die ABAP/4 Schnittstelle Programm A Daten EXPORTING IMPORTING EXCEPTIONS Schnittstelle FUNCTION xy.... ENDFUNCTION. Funktionsbaustein oder Selektionsbild Programm A Daten Programm B Thomas Arend SAP AG Jena 99 June, Funktionsbausteine besitzen eine Schnittstelle, über die das rufende und das gerufene Programm Daten austauschen können (vergleichbares gilt für ABAP-Unterprogramme). Funktktionsbausteine, die für RFC geeignet sind, besitzen Einschränkungen für ihre Schnittstelle. Sie können ABAP-Programmen, die ein Standard-Selektionsbild besitzen, beim Aufruf Werte für die Eingabefelder auf dem Selektionsbild mitgeben. Hierfür gibt es zwei Möglichkeiten: Sie verwenden beim Aufruf des gerufenen Programms eine Variante zum Standard- Selektionsbild Sie geben beim Aufruf des gerufenen Programms konkrete Werte für die Eingabefelder mit. 36

37 Asynchrone Programmaufrufe: SAP-LUWs CALL FUNCTION <f-name> STARTING NEW TASK. Modus 1 Programm 1 SAP-LUW1 Programm 1 Zeit Modus 2 Funktionsbaustein f-name SAP-LUW2 Zeit Thomas Arend SAP AG Jena 99 June, Funktionsbausteine, die asynchron mit Hilfe der Anweisung CALL FUNCTION <function> STARTING NEW TASK aufgerufen werden, laufen in einer eigenen SAP-LUW. 37

38 RFC-Szenario: R/3 - R/3 R/3-System A R/3-System B R/3-Applikations-Server R/3-Applikations-Server Workprozess PROGRAM... RFC-CALL Remote Workprozess Funktionsgruppe Funktionsbaustein Thomas Arend SAP AG Jena 99 June, Wird ein Funktionsbaustein "remote" aufgerufen, so läuft er auf einem anderen Applikations-Server in einem eigenen Workprozess ( in einer eigenen SAP-LUW ) ab. Es kann sich um einen Applikations-Server eines anderen R/3-Systems, eines R/2-Systems oder eines externen Server-Programms handeln. 38

39 Programm-Kontext der Remote-Funktion R/3-Appl.-Server Remote-Server Funktionsgruppe Globale Daten PROGRAM CALL FUNCTION FUNC1 DESTINATION DEST... FUNCTION FUNC1.... ENDFUNCTION. DB-LUW1 CALL FUNCTION FUNC2 DESTINATION DEST... FUNCTION FUNC2.... ENDFUNCTION. DB-LUW2 Thomas Arend SAP AG Jena 99 June, Die Verbindung zu einer Remote-Destination bleibt so lange bestehen, wie der Aufrufer-Kontext aktiv ist. Die auf einer Remote-Destination angesprochenen Funktionsgruppen bleiben ( wie bei einem lokalen Aufruf auch ) so lange aktiv, wie der Aufrufer selbst aktiv ist. Daher ist bei aufeinanderfolgenden Aufrufen von Funktionsbausteinen derselben Funktionsgruppe jeweils der Zugriff auf die globalen Daten der jeweiligen Funktionsgruppe möglich. Beim synchronen und asynchronen RFC bildet jeder Funktionsbaustein eine eigene DB-LUW ab ( Ausnahme: transaktionaler RFC ). 39

40 Remote Function Call: Überblick RFC-Techniken srfc: synchroner RFC arfc: asynchroner RFC trfc: transaktionaler RFC Thomas Arend SAP AG Jena 99 June, Funktionsbausteine, die in anderen R/3-Systemen ausgeführt werden sollen, können auf drei verschiedene Arten ausgeführt werden: synchron, sog. synchroner Remote Function Call (srfc) asynchron, sog. asynchroner Remote Function Call (arfc) mit transaktionaler Verarbeitungslogik, sog. transaktionaler Remote Function Call (trfc). 40

41 Ablaufschema: Synchroner RFC PROGRAM.... CALL FUNCTION TEST DESTINATION <dest> EXPORTING Datenübergabe Datenrückgabe R/3-System <dest dest> ABAP-Funktionsbaustein FUNCTION TEST. ENDFUNCTION. Thomas Arend SAP AG Jena 99 June, Beim synchronen RFC hält die Verarbeitung im rufenden Programm so lange an, bis der gerufene Funktionsbaustein abgearbeitet ist. Danach setzt der Aufrufer seine Verarbeitung hinter dem Aufruf fort. Über die Schnittstelle können Daten in beiden Richtungen ausgetauscht werden. Der Zusatz DESTINATION <dest> enthält den symbolischen Namen des Systems, in dem der Funktionsbaustein zur Ausführung gebracht werden soll. 41

42 Ablaufschema: Asynchroner RFC PROGRAM CALL FUNCTION TEST DESTINATION <dest> STARTING NEW TASK <a>... Datenübergabe R/3-System DEST ABAP-Funktionsbaustein FUNCTION TEST. ENDFUNCTION. Datenrückgabe Thomas Arend SAP AG Jena 99 June, Beim asynchronen RFC wird der gerufene Funktionsbaustein gestartet und sofort danach die Verarbeitung im rufenden Programm fortgesetzt. Die Verarbeitung des Funktionsbausteins selbst findet entkoppelt vom Aufrufer statt. Über die Schnittstelle können Daten in beiden Richtungen ausgetauscht werden. 42

43 Ablaufschema: Transaktionaler RFC PROGRAM CALL FUNCTION TEST1 IN BACKGROUND TASK DESTINATION DEST... CALL FUNCTION TEST2 IN BACKGROUND TASK DESTINATION DEST.... COMMIT WORK.... Starten Datenübergabe Logische Einheit FUNCTION TEST1. ENDFUNCTION. FUNCTION TEST2. ENDFUNCTION. Verwaltung- u. Monitoring Rückmeldungen: - Kein Verbindungsaufbau möglich - Anstarten der Einheit nicht möglich - Fehler während Ausführung Thomas Arend SAP AG Jena 99 June, Wenn Sie z.b. konsistente Datenbankänderungen in verschiedenen R/3-Systemen durchführen wollen, können Sie hierfür die Technik des transaktionalen RFC verwenden. Über dieses Verfahren kann sichergestellt werden, daß "remote" gerufene Funktionsbausteine auch dann abgearbeitet werden, wenn zum Aufrufzeitpunkt der relevante Remote-Partner gerade nicht erreichbar ist. Beispielsweise könnte die Verbindung zu dem Partner-System unterbrochen sein oder das Partner- System selbst zur Zeit nicht aktiv sein. Es stehen Mechanismen zur Verfügung, die eine geregelte Behandlung von Problemsituationen ( Verwaltung und Monitoring ) erlauben. Im Gegensatz zum synchronen und asynchronen RFC können Sie verschiedene Funktionsbausteine für die Remote-Verarbeitung zu einer logischen Einheit ( SAP-LUW ) zusammenfassen ( Rollback auf die ganze Einheit ist möglich ). 43

44 Transaktionaler RFC (trfc) Beispiel-Szenario: Identische Datenbankänderung in verschiedenen R/3-Systemen R/3-System A R/3-System B Anwendungs-Programm Funktionsbaustein Identische DB-Änderung DB DB Thomas Arend SAP AG Jena 99 June, Wenn Sie z.b. konsistente Datenbankänderungen in verschiedenen R/3-Systemen durchführen wollen, können Sie hierfür die Technik des transaktionalen RFC verwenden. Über dieses Verfahren kann sichergestellt werden, daß Remote gerufene Funktionsbausteine auch dann abgearbeitet werden, wenn zum Aufrufzeitpunkt der relevante Remote-Partner gerade nicht erreichbar ist. Beispielsweise könnte die Verbindung zu dem Partner-System gerade unterbrochen sein oder das Partner-System selbst ist gerade nicht aktiv. Desweiteren stehen in diesem Zusammenhang Mechanismen zur Verfügung, die eine geregelte Behandlung von Problemsituationen, die sich während einer Remote-Verarbeitung zur Laufzeit ergeben könnten, erlauben. 44

45 trfc: Eigenschaften Client Job Aufruf Server trfc-call 1 trfc-call 2 L U W SM58 Rückkopplung Funktion 1 Funktion 2 L U W - Partner-System muß zum Aufruf-Zeitpunkt nicht aktiv ( oder erreichbar ) sein - Protokollierung des Ausführungs-Status im Client-System mit Verwaltungsfunktionalität - Automatische Jobeinplanung für die spätere Wiederholung des Aufrufs bei Nichterreichbarkeit des Partner-Systems - LUW-Integrität: eine LUW auf der Client-Seite wird als LUW auf der Serverseite abgebildet Thomas Arend SAP AG Jena 99 June, trfc-aufrufe werden grundsätzlich erst einmal auf der Client-Seite in der Datenbank abgelegt ( übergebene Daten und Kontextinformationen ). Ein Systemprogramm startet im rufenden System einen Funktionsbaustein asynchron, der seinerseits alle trfc-aufrufe synchron im Zielsystem ausführt. Ist die direkte Ausführung nicht möglich, weil der Partner gerade nicht erreichbar ist, so wird dies auf der Client-Seite protokolliert. trfc-aufrufe, die noch nicht erfolgreich abgearbeitet werden konnten, sind über die Verwaltungstransaktion SM58 sichtbar und können hier z.b. interaktiv bearbeitet werden. In diesem Zusammenhang besteht auch die Möglichkeit, über eine automatische Jobeinplanung die Ausführung von trfc-aufrufen so lange anzustoßen, bis sie erfolgreich abgearbeitet werden konnten. Konnte die Ausführung eines trfc-aufrufs im Partner-System zwar initiiert werden, aber während der Abarbeitung im Server-System ergeben sich Fehler, so erfolgt eine Rückmeldung an das Client- System. Die Fehlerursache kann über die Transaktion SM58 analysiert und bearbeitet werden. trfc-aufrufe, die auf der Client-Seite eine SAP-LUW bilden, werden im Partner-System ebenfalls als eine SAP-LUW abgebildet. 45

46 SAP R/3 4.6A Thomas Arend SAP AG Jena 99 June,

47 R/3 Mandarin Version Thomas Arend SAP AG Jena 99 June,

48 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena 99 June,

49 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena 99 June,

50 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena 99 June,

51 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena 99 June,

52 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena 99 June,

53 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena 99 June,

54 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena 99 June,

55 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena 99 June,

56 Aktuelle Entwicklungen Internet Integration Business Objects Object-oriented Development and Delivery Java C ++ VB... Systemkopplung durch ALE Business Warehouse Object Repository Thomas Arend SAP AG Jena 99 June,

57 Blockseminar Transaktionssysteme Friedrich-Schiller-Universität Jena 1999: Transaktionssystemeigenschaften im SAP System R/3 Thomas Arend SAP AG Thomas Arend SAP AG Jena 99 June,