Transaktionssystemeigenschaften im SAP System R/3
Werbung
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, 10. 1999 SAP AG 1 1 Themenübersicht l Client/Server Architektur des R/3 System l Datenbankänderungen n Bündelung n Verbuchungstechniken n Sperrkonzept l Transaktionsverarbeitung n Synchrone Aufrufe n Asynchrone Aufrufe n Datenübergabetechniken n LUWs n RFC-Techniken n Transaktionsmonitore l Aktuelle Entwicklungen Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 2 2 SAP R/3: 3-Ebenen Client/Server-Architektur Presentation SAPGUI SAPGUI SAPGUI SAPGUI Dispatcher Application Workprozeß Database Thomas Arend SAP AG Jena‘99 June, 10. 1999 Workprozeß Workprozeß DB-Workprozesse 3 ❏ 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. SAP AG 3 R/3 multi-tier C/S Architecture WAN Presentation Internet Customer Service Rep Accept Customer Order Customer Order Create Production Orders Production Order Plant Personnel Explode Bill-ofMaterial Reserve Material Release Production Orders Build Products Part Material Schedule Production Task Confirm Delivery Application Database Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 4 4 9 R/3 Client Server Konfiguration SAP R/3 System Presentation Application Database Central System / Laptop Distributed Presentation Two-tier Client/Server Fat client Three-tier Client/Server Multi-Layer Cooperative Client/Server Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 5 5 147 Types of Processes and Application servers Message Update Dialog V M D SAP-Dispatcher SAP-Dispatcher Batch 11 10 12 Enqueue 1 2 9 3 8 4 7 6 5 B Spool E Gateway S R/2 Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG G R/3 6 6 Plattformunabhängigkeit des R/3 Hardware UNIX Systems Bull Digital HP IBM SNI SUN Data General Sequent AT&T SNI Bull/Zenith HP (Intel) IBM (Intel) Digital (Intel) Compaq ... IBM AS/400 Windows NT OS/400 ADABAS D MS SQL Server ORACLE DB2/400 Operating AIX Reliant Systems Digital UNIX UNIX (SINIX) HP-UX Databases Dialog SAP-GUI SOLARIS ADABAS D DB2 for AIX INFORMIX-OnLine ORACLE Windows 3.1, Windows 95, Windows NT, OSF/Motif, Presentation Manager, Macintosh Languages Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG Windows ‘95 OS/2 ABAP/4, C, C+ + 7 7 16 8 R/3 Repository Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 8 8 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, 10. 1999 9 ❏ 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. SAP AG 9 SAP-LUW Elementarer betriebswirtschaftlicher Vorgang Prozeßschritt 1 Prozeßschritt 2 ... Prozeßschritt n SAP-LUW Thomas Arend SAP AG Jena‘99 June, 10. 1999 10 ❏ 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. SAP AG 10 Datenbank-LUW Datenbankoperationen Zwischenzustände insert, update, delete Konsistenter Zustand 1 Konsistenter Zustand 2 DB-COMMIT ROLLBACK Thomas Arend SAP AG Jena‘99 June, 10. 1999 11 ❏ 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. SAP AG 11 Impliziter DB-COMMIT Bildschirm 1 DB-COMMIT DB-LUW 1 Bildschirm 2 DB-COMMIT DB-LUW 2 Bildschirm 3 DB-COMMIT DB-LUW 3 DB-LUW 4 Zeit Thomas Arend SAP AG Jena‘99 June, 10. 1999 12 ❏ 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>. SAP AG 12 DB-Änderungen einer SAP-LUW bündeln SAP-LUW Benutzerdialoge ABAPProgramm DB-Änderungen DB- LUW Thomas Arend SAP AG Jena‘99 June, 10. 1999 13 ❏ 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 DatenbankLUW 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. SAP AG 13 Bündelung: verzögerte Inline-Änderungen SAP-LUW Globale Daten des Programms Daten Daten Verarb. block 1 Verarb. block 2 Daten ... Letzter Dialogschritt Änderungsanforderungen Thomas Arend SAP AG Jena‘99 June, 10. 1999 DB-Commit 14 ❏ 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-oderNichts-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. SAP AG 14 Bündelung mit Hilfe von Unterprogrammen SAP-LUW 1 Globale Daten des Programms Daten Daten PERFORM x ON COMMIT. PERFORM y ON COMMIT. Daten ... Ausführungsliste Formroutine x Formroutine y ... Thomas Arend SAP AG Jena‘99 June, 10. 1999 COMMIT WORK. FORM x ... FORM y ... ... DB-Commit Änderungen 15 ❏ 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. SAP AG 15 Bündelung durch Verbuchung: Prinzip Protokolltabelle 1 Vormerkung 1 ... Vormerkung n Einträge löschen 2 Daten Daten lesen Workprozeß 1 Workprozeß 2 4 Dialogprogramm • asynchron • synchron • lokal Verbuchungsprogramm 3 Thomas Arend SAP AG Jena‘99 June, 10. 1999 DatenbankÄnderungen 16 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. SAP AG 16 Rollback im Dialogprogramm PROGRAM ... MODULE user_command INPUT. ... CASE save_ok. WHEN ’BACK’. . . . MESSAGE Axxx. * ROLLBACK WORK. . WHEN ’SAVE’. . . . COMMIT WORK. ENDCASE. ... ENDMODULE. Thomas Arend SAP AG Jena‘99 June, 10. 1999 Löschen aller bis dahin geschriebenen Vormerkungen 17 ❏ 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 AbbruchDialognachricht auslösen. Damit ist gewährleistet, daß auch alle im Programm gesammelten Daten beim Abbruch zurückgesetzt werden. SAP AG 17 Rollback im Verbuchungsprogramm FUNCTION-POOL ... ... FUNCTION ... ... UPDATE ... IF sy-subrc NE MESSAGE Annn ENDIF. ... INSERT ... IF sy-subrc NE MESSAGE Annn ENDIF. ... ENDFUNCTION. 0. ... ROLLBACK WORK Impliziter Rollback auf der Datenbank 0. ... Thomas Arend SAP AG Jena‘99 June, 10. 1999 18 ❏ 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 AbbruchDialognachricht 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. SAP AG 18 Anweisungen für Datenbankdialoge Native-SQL Open-SQL SELECT INSERT UPDATE DELETE MODIFY ... ... ... ... ... EXEC SQL. CREATE TABLE ... ENDEXEC. . . . Vorteile/Nachteile Vorteile/Nachteile - unabhängig von Datenbank - Möglichkeit mit Puffern zu arbeiten - Einbettung in ABAP - datenbankspezifisch - nicht bei gepufferten Tabellen Thomas Arend SAP AG Jena‘99 June, 10. 1999 19 ❏ 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/3Systems. 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. SAP AG 19 Asynchrone Verbuchung Zeit VBLOG DialogWP Verbuchungs-WP Text Protokolltabelle Vormerkung 1 1 ... COMMIT WORK. 3 Vormerkung n 2 1 SAP-LUW 1, Dialogprogramm DB 2 SAP-LUW 1, Verbuchungsprogramm 3 SAP-LUW 2, Dialogprogramm Thomas Arend SAP AG Jena‘99 June, 10. 1999 20 ❏ 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. SAP AG 20 Synchrone Verbuchung Zeit DialogWP VBLOG Verbuchungs-WP Text Protokolltabelle Vormerkung 1 1 ... COMMIT WORK AND WAIT. Vormerkung n 2 3 DB 1 SAP-LUW 1, Dialogprogramm 2 SAP-LUW 1, Verbuchungsprogramm 3 SAP-LUW 2, Dialogprogramm Thomas Arend SAP AG Jena‘99 June, 10. 1999 21 ❏ 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. SAP AG 21 Lokale Verbuchung Zeit Workprozeß Hauptspeicher Protokolltabelle SET UPDATE TASK LOCAL. Vormerkung 1 ... 1 Vormerkung n COMMIT WORK. 2 3 DB 1 SAP-LUW 1, Dialogprogramm 2 SAP-LUW 1, Verbuchungsprogramm 3 SAP-LUW 2, Dialogprogramm Thomas Arend SAP AG Jena‘99 June, 10. 1999 22 ❏ 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. SAP AG 22 SAP-LUW: Zeitlicher Verlauf bei Verbuchung synchron Zeit Dialog Verbuchung asynchron Dialog 1 Verbuchung 1 COMMIT WORK AND WAIT. Dialog SET UPDATE TASK LOCAL. 1 COMMIT WORK. COMMIT WORK. 2 3 2 2 lokal 3 3 1 SAP-LUW 1, Dialogprogramm 2 SAP-LUW 1, Verbuchungsprogramm 3 SAP-LUW 2, Dialogprogramm Thomas Arend SAP AG Jena‘99 June, 10. 1999 23 ❏ 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. SAP AG 23 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, 10. 1999 24 ❏ 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 V1Verbuchungsfunktions-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. SAP AG 24 Warum müssen Sperren gesetzt werden? Programm B Programm A Tabelle 4 Tabelle 1 Tabelle 3 Tabelle 6 Tabelle 5 Tabelle 2 Thomas Arend SAP AG Jena‘99 June, 10. 1999 25 ❏ 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. SAP AG 25 Datenbanksperren COMMIT COMMIT (implizit) (implizit) UPDATE UPDATE COMMIT WORK (explizit) SELECT SELECT FOR FOR UPD UPD INSERT INSERT DELETE DELETE Sperren Thomas Arend SAP AG Jena‘99 June, 10. 1999 26 ❏ 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. SAP AG 26 SAP Sperrkonzept SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI Dispatcher Dispatcher Dialog WP .. .. .. Dialog WP SAPGUI Sperrtabelle MessageServer WP .. .. .. Enqueue WP DB-Workprozesse Thomas Arend SAP AG Jena‘99 June, 10. 1999 27 ❏ 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 EnqueueWorkprozeß, 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. SAP AG 27 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, 10. 1999 28 ❏ 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, AMessage). SAP AG 28 Zusammenfassung l SAP-Transaktionen n 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. l Bündelungstechnik n Das SAP-System stellt mehrere Bündelungstechniken zur Verfügung, mit deren Hilfe eine SAP-LUW auf eine DatenbankLUW abgebildet werden kann. l SAP Sperrkonzept n Zur Gewährleistung der Datenkonsistenz während der Datenbankänderungen Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 29 29 Aufruf einer Transaktion Programm 1 Programm 1: Transaktion TCGB MODULE ... INPUT. ... CALL TRANSACTION ’TCGB’. * AND SKIP FIRST SCREEN. ... ENDMODULE. 1. Dynpro SAPMTCGB 2. Dynpro F15 Thomas Arend SAP AG Jena‘99 June, 10. 1999 MODULE ... INPUT. ... LEAVE PROGRAM. ... ENDMODULE. 30 ❏ 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>. SAP AG 30 Synchrone Programmaufrufe: Belegung des Hauptspeichers Externer Modus 1 nach dem Aufruf Externer Modus 1 Interner Modus 2 3 Programm 2 2 Interner Modus 1 Programm 1 1 Interner Modus 1’ 3 4 Programm 3 Funktionsgruppe 1 CALL FUNCTION 3 LEAVE TO TRANSACTION 2 CALL TRANSACTION, 4 SUBMIT <p> SUBMIT <p> AND RETURN Thomas Arend SAP AG Jena‘99 June, 10. 1999 31 ❏ 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. SAP AG 31 Synchrone Programmaufrufe: SAP-LUWs Art des Aufrufs - SUBMIT <prog2>. - LEAVE TO TRANSACTION <t_code>. - SUBMIT <prog2> AND RETURN. - CALL TRANSACTION <t_code>. - CALL FUNCTION <f_name>. Beteiligte SAP-LUWs SAP-LUW1 SAP-LUW2 Programm 1 prog2 / t_code SAP-LUW1 SAP-LUW2 SAP-LUW1 Programm 1 prog2 / t_code Programm 1 Zeit Zeit SAP-LUW1 Programm 1 f_name Programm 1 Zeit Thomas Arend SAP AG Jena‘99 June, 10. 1999 32 ❏ 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. SAP AG 32 Asynchrone Aufrufe Hauptspeicher Hauptspeicher Modus 1 Modus 2 1 CALL FUNCTION <f_name> STARTING NEW TASK ’<name>’ ... 1 2 1 Programm 1 2 Funktionsbaustein <f_name> Thomas Arend SAP AG Jena‘99 June, 10. 1999 33 ❏ 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". SAP AG 33 Asynchrone Programmaufrufe CALL FUNCTION <f_name> STARTING NEW TASK ’<name>’ EXPORTING ... Externer Modus 2 Externer Modus 1 Interner Modus 1 Programm 1 Thomas Arend SAP AG Jena‘99 June, 10. 1999 Interner Modus 1 zeitlich entkoppelt Funktionsgruppe 34 ❏ 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. SAP AG 34 Datenübergabe: Überblick SAP-Memory SET- /GET-Parameter 3 ABAP-Memory 2 Programm A Schnittstelle 1 Programm B 4 DB 5 Thomas Arend SAP AG Jena‘99 June, 10. 1999 35 ❏ 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. SAP AG 35 Programm A Daten Datenübergabe über die ABAP/4 Schnittstelle EXPORTING IMPORTING EXCEPTIONS Schnittstelle Funktionsbaustein FUNCTION xy. ... ENDFUNCTION. oder Programm A Daten Selektionsbild Thomas Arend SAP AG Jena‘99 June, 10. 1999 Programm B 36 ❏ 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 StandardSelektionsbild Sie geben beim Aufruf des gerufenen Programms konkrete Werte für die Eingabefelder mit. SAP AG 36 Asynchrone Programmaufrufe: SAP-LUWs CALL FUNCTION <f-name> STARTING NEW TASK ’’. SAP-LUW1 Modus 1 Zeit Programm 1 Programm 1 Zeit Modus 2 Funktionsbaustein f-name SAP-LUW2 Thomas Arend SAP AG Jena‘99 June, 10. 1999 37 ❏ Funktionsbausteine, die asynchron mit Hilfe der Anweisung CALL FUNCTION <function> STARTING NEW TASK ’ ’ aufgerufen werden, laufen in einer eigenen SAP-LUW. SAP AG 37 RFC-Szenario: R/3 - R/3 R/3-System A R/3-System B R/3-Applikations-Server R/3-Applikations-Server Workprozess Workprozess Funktionsgruppe PROGRAM ... RFC-CALL Remote Thomas Arend SAP AG Jena‘99 June, 10. 1999 Funktionsbaustein 38 ❏ 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. SAP AG 38 Programm-Kontext der Remote-Funktion R/3-Appl.-Server Remote-Server Funktionsgruppe Globale Daten PROGRAM ... . ... FUNCTION FUNC1. CALL FUNCTION ’FUNC1’ DESTINATION ’DEST’ ... ... DB-LUW1 ENDFUNCTION. FUNCTION FUNC2. CALL FUNCTION ’FUNC2’ DESTINATION ’DEST’ ... Thomas Arend SAP AG Jena‘99 June, 10. 1999 ... DB-LUW2 ENDFUNCTION. 39 ❏ 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 ). SAP AG 39 Remote Function Call: Überblick RFC-Techniken sRFC: synchroner RFC aRFC: asynchroner RFC tRFC: transaktionaler RFC Thomas Arend SAP AG Jena‘99 June, 10. 1999 40 ❏ 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). SAP AG 40 Ablaufschema: Synchroner RFC PROGRAM ... . . . CALL FUNCTION ’TEST’ DESTINATION ’<dest>’ EXPORTING ... Datenübergabe R/3-System ’<dest>’ ABAP-Funktionsbaustein FUNCTION TEST. ENDFUNCTION. . . . Datenrückgabe Thomas Arend SAP AG Jena‘99 June, 10. 1999 41 ❏ 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. SAP AG 41 Ablaufschema: Asynchroner RFC PROGRAM ... . Datenübergabe . . CALL FUNCTION ’TEST’ DESTINATION ’<dest>’ STARTING NEW TASK ’<a>’ . . . R/3-System ’DEST’ ABAP-Funktionsbaustein FUNCTION TEST. ENDFUNCTION. Datenrückgabe Thomas Arend SAP AG Jena‘99 June, 10. 1999 42 ❏ 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. SAP AG 42 Ablaufschema: Transaktionaler RFC PROGRAM ... ... Logische Einheit Starten CALL FUNCTION ’TEST1’ IN BACKGROUND TASK DESTINATION ’DEST’ ... CALL FUNCTION ’TEST2’ IN BACKGROUND TASK DESTINATION ’DEST’. Datenübergabe FUNCTION TEST1. ENDFUNCTION. FUNCTION TEST2. ... COMMIT WORK. ... ENDFUNCTION. Rückmeldungen: Verwaltung- u. Monitoring - Kein Verbindungsaufbau möglich - Anstarten der Einheit nicht möglich - Fehler während Ausführung Thomas Arend SAP AG Jena‘99 June, 10. 1999 43 ❏ 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 PartnerSystem 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 ). SAP AG 43 Transaktionaler RFC (tRFC) Beispiel-Szenario: Identische Datenbankänderung in verschiedenen R/3-Systemen R/3-System B R/3-System A Anwendungs-Programm Funktionsbaustein Identische DB-Änderung DB Thomas Arend SAP AG Jena‘99 June, 10. 1999 DB 44 ❏ 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. SAP AG 44 tRFC: Eigenschaften Job Client tRFC-Call 1 tRFC-Call 2 Aufruf L U W Server Funktion 1 Rückkopplung SM58 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, 10. 1999 45 ❏ 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 ClientSystem. 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. SAP AG 45 SAP R/3 4.6A Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 46 46 R/3 Mandarin Version Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 47 47 24 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 48 48 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 49 49 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 50 50 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 51 51 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 52 52 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 53 53 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 54 54 CCMS Monitore des R/3 Systems Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 55 55 Aktuelle Entwicklungen l Internet Integration l Business Objects l Object-oriented Development and Delivery n Java n C++ n VB n ... l Systemkopplung durch ALE l Business Warehouse l Object Repository Thomas Arend SAP AG Jena‘99 June, 10. 1999 SAP AG 56 56 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, 10. 1999 SAP AG 57 57
