Kap. 12 Transaktionsverwaltung in ERP-Systemen

Transkript

1 Kap. 12 Transaktionsverwaltung in ERP-Systemen 12.1 Mehrstufige Transaktionsverwaltung 12.2 Transaktionen und Logical Units of Work (LUWs) in SAP R/ Workshop: ABAP-Dialogprogrammierung Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 1

2 Kapitel 12: Transaktionsverwaltung Mehrstufige Transaktionsverwaltung Client A-SQL AS D-SQL DBMS In ERP-Systemen (allgemein: in mehrstufigen Client/Server-Architekturen) unterscheidet man zwei wesentliche Abstraktionsebenen: Anwendungsserver (AS) und Speicherserver; der Speicherserver ist ein DBMS Daher werden Anwendungsobjekte (AS-Objekte) oder Business Objects oberhalb von Datenbankobjekten (DBMS-Objekte) betrachtet. Wir nehmen im folgenden an, dass AS-Objekte mittels A-SQL angelegt und manipuliert werden, während für DBMS-Objekte D-SQL verwendet wird die Abbildung zwischen AS-Objekten und DBMS- Objekten festgelegt ist (also auch die Abbildung von A-SQL auf D-SQL)

3 Kapitel 12: Transaktionsverwaltung 3 Mehrstufige Transaktionsverwaltung Wir können daher auch A-Transaktionen und D-Transaktionen unterscheiden Triviale Abbildung: jede A-Transaktion entspricht einer D-Transaktion (also beide Transaktionen sind identisch). Aber: Anwendungssemantik wird dabei nicht berücksichtigt Anwendungsobjekte umspannen mehrere DB-Objekte Sperren können z.b. nicht atomar auf mehreren DB-Objekten angefordert werden Fehlende Unterstützung langer Transaktionen über Prozessgrenzen hinweg (eine A-Transaktion durch mehrere OS-Prozesse ausgeführt) Da in der Regel mehrere DBMS unterstützt werden, muss die Heterogenität der verwendeten Transaktionsmodelle berücksichtigt werden Seitensperren auf DBMS-Ebene (die viele kommerzielle DBMS verwenden) sind zu restriktiv, da auch andere Objekte davon betroffen sein können Ist hier eine effizientere und bessere Abbildung möglich?

4 Mehrstufige Transaktionsverwaltung Lösung: Anwendung der Theorie zusammengesetzter Transaktionen (siehe IS-K) bei der jede Anwendungsaktion als eine Datenbank-Transaktion angesehen wird Dies entspricht dann einer 1:n-Zuordnung von Anwendungstransaktionen zu Datenbanktransaktionen (wird daher auch der 1:n-Abbildung von Anwendungsobjekten auf Datenbankobjekte gerecht) Transaktionsverwaltung auf jeder Stufe: Zweistufige Transaktionsverwaltung Datenbank-Transaktionsverwaltung (durch DBMS gegeben) Zusätzlich: Transaktionsverwaltung auf Anwendungsebene Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 4

5 Kapitel 12: Transaktionsverwaltung 5 Zweistufige Transaktionen Die Vorteile sind Höhere Parallelität (als bei trivialer Abbildung erzielt werden kann) Unterstützung langer Transaktionen über Prozessgrenzen Ausnützen von Semantik auf der AS-Ebene Ziel ist es, ein einfaches mehrstufiges Transaktionsprotokoll zu entwickeln, ausgehend von der Theorie aus IS-K. Dabei soll ein einfaches striktes 2PL auf A-Objektmengen verwendet werden. Dieses Protokoll wird dann dem in SAP implementierten gegenübergestellt. Aus IS-K: Der Scheduler verwendet Konfliktrelation und ordnet Konfliktpaare. Bei Anwendung eines Sperrprotokolls wird ein Konflikt in unverträgliche Sperranforderungen übersetzt. Damit werden Konfliktpaare stark geordnet.

6 Zweistufige Transaktionen Anwendungs- Objekte Anwendungs-Transaktion A 1 A 2 A 3 A 4 A 5 DB-Objekte t 1 Commit t 2 Commit t 3 Commit t 4 Commit t 5 Commit t i : DB-Transaktionen Auf Anwendungsebene: Sperrprotokolle, um Aktionen, die in Konflikt stehen, gegenseitig auszuschliessen Konflikte auf Datenbankebene (Zugriff auf gleiche Seite) werden dann vom DBMS korrekt behandelt Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 6

7 Zweistufiges Recovery Im Fehlerfall sind besondere Massnahmen erforderlich Da jede DB-Transaktion mit Commit beendet wird, müssen geeignete Kompensations-Aktionen (Inverse) für den Abbruch von A-Transaktionen vorgesehen (bzw. automatisch generiert) werden z.b. indem vor der Ausführung einer A-SQL-Aktion ein Logsatz zur Ausführung der Inverse auf der A-SQL-Ebene geschrieben wird, im Sinne eines Write-Ahead-Logs (WAL) Zweistufiges Recovery Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 7

8 Kapitel 12: Transaktionsverwaltung 8 Beispiel: Sperrverträglichkeit für A-SQL-Aktionen Select Update Delete Insert Select Update Delete Insert??????????????? In allen Fällen, ausser Select, muss geprüft werden, ob die Tupelmengen aller Sperrenbesitzer disjunkt sind zur Tupelmenge, die der Sperranforderer möchte. z.b. Anwendung von groben Prädikaten für effizientes Testen Unterscheidung von S und X- Sperren, wie im einfachen Read/ Write-Modell: bei Select S, sonst X. Inverse können automatisch generiert werden: Select: Update: Insert: Delete: nil Update rückgängig Delete Insert

9 SAP R/3 Einordnung SAP R/3 implementiert eine eigene Sperrverwaltung auf Anwendungsebene SAP R/3 verwendet also ein zweistufiges Transaktionsmodell SAP-Transaktionen über DB-Transaktionen definiert Scheduling erfolgt auf beiden Ebenen gleichzeitig Die SAP Transaktionsverwaltung kann daher als ein Zwei-Scheduler- Stapel aufgefasst werden SAP-Scheduler Sperrverwaltung für SAP-Objekte DB-Scheduler Sperrverwaltung für DB- Objekte Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 9

10 12.2 Transaktionen und LUWs in SAP R/3 Transaktionen heissen in SAP/R3 Logical Unit of Work (LUW). Eine LUW besteht in der Regel aus zwei Teilen: SAP-Transaktion: Folge von vorbereiteten Dialogschritten D i (sukzessive Durchführung von Benutzereingaben) SAP-Verbuchung: eigentliche Durchführung der Änderungen/ Einfügungen der Dialogschritte in der Datenbank Dialogschritte und Verbuchung werden jeweils als eigenständige DB-Transaktionen ausgeführt. Ausführung der Dialogschritte entspricht einem Enqueue der Aufträge Verbuchung ist deren Durchführung innerhalb von (einer) DB-Transaktion(en) SAP-Objekte werden für die Dauer der SAP-LUW gesperrt, DB-Objekte nur während der DB-Transaktion (also kurz) Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 10

11 SAP/R3: Transaktionen, Verbuchung und LUWs Sperrdauer für SAP- Objekte SAP-Logical Unit of Work (LUW) SAP-Objekte SAP-Transaktion SAP-Verbuchung D 1 D 2 D 3 D 4 V 1 V 2 DB-Objekte t 1 Commit t 2 Commit t 3 Commit t 4 Commit t 5 Commit t 6 Commit Sperrdauer für Datenbank-Objekte D i : Dialogschritte (DynPros) V i : Verbuchungsschritte t i : DB-Transaktionen Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 11

12 Kapitel 12: Transaktionsverwaltung 12 Architektur von SAP R/3: Prozess-orientierte Sichtweise X-Server SAPGUI- Prozess SAPGUI- Prozess PC Präsentation Batch- Workprozess Dispatcher Spool- Workprozess Verbuchungs- Workprozess Dialog- Workprozess Enqueue- Workprozess Anwendungslogik Datenhaltung

13 Kapitel 12: Transaktionsverwaltung 13 SAP R/3: Dienste und Prozesse Anwendungsserver ( 1 pro R3-System) Dispatcher (1 pro Anwendungsserver) Zentraler Prozess auf Anwendungsebene Zuweisung von Workprozessen Dialog-Workprozess ( 1 pro Anwendungsserver) ABAP-Interpreter & DynPro-Prozessor Batch-Workprozess ( 1 pro R3-System) Hintergrundverarbeitung Enqueue-Workprozess (genau 1 pro R3-System) Sperrverwaltung für SAP-Objekte Verwendet eigene Sperrtabelle, unabhängig von unterliegender DB Verbuchungs-Workprozess ( 1 pro R3-System) Durchführung von Datenbank-Änderungen Spool-Workprozess (1 pro Rechner) Druckaufbereitung

14 SAP-LUWs vs. Datenbank-Transaktionen Jedes DynPro kann von einem unterschiedlichen Workprozess bearbeitet werden Dialogtransaktion und Verbuchung werden durch unterschiedliche Prozesse bearbeitet Wenn SAP-LUW identisch mit DB-Transaktion wäre, dann müssten in der DB-Sperren über Prozessgrenzen hinweg weitergegeben werden DynPro-Wechsel löst automatisch DB-Commit aus. Ein einzelnes DynPro entspricht also einer DB-Transaktion Für den Fehlerfall sind keine Kompenationsoperationen (Inverse) der Änderungsoperationen verfügbar Alle Änderungen müssen im Verbuchungs-Workprozess zusammengefasst werden, um ACID zu garantieren Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 14

15 Dialog- und Verbuchungs-WPs Verbuchungs- Workprozess Dialog-Workprozess 2 D1 2 Dialog-Workprozess 1 Transaktion 3 D3 1 Transaktion 2 D2 1 D2 2 Transaktion 1 D1 1 Zeitachse LUW 1 (durch zwei unterschiedliche Dialog-WP ausgeführt) LUW 2 (Transaktion wird durch LUW 3 unterbrochen) LUW 3 (Verbuchung wird vom Dialog-WP ausgeführt) Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 15

16 Kapitel 12: Transaktionsverwaltung 16 SAP R/3-Dialogschritte: DynPro-Konzept Dialogprogramm = Folge von Dialogschritten Jeder Dialogschritt entspricht einem DynPro (dynamisches Programm) DynPro-Ablauflogik PBO (Process Before Output) Bereitet Bildschirmbild zur Ausgabe vor PAI (Process After Input) Verarbeitung der Benutzereingaben DynPro Output Modul (PBO) Bildschirmausgabe Benutzereingabe Input Modul (PAI) Output Modul (PBO)

17 Kapitel 12: Transaktionsverwaltung 17 Datenbank-Interaktion: Gebündelt Gebündelte Aktualisierung DB-Änderungen werden in eine Protokollsatzdatei geschrieben DB-Verbuchung erfolgt erst am Ende der SAP-Transaktion Asynchrone Verbuchung (Standard-Verfahren): Abarbeitung von Funktionsbausteinen durch spezielle Verbuchungs-Workprozesse V1: Primäre Verbuchungskomponenten, für die ACID gefordert wird V2: Sekundäre Verbuchungskomponenten. Werden nach den V1-Komponenten durchgeführt. Fehler der V2-Komponenten führen NICHT zum Fehlschlagen der LUW. V1 bzw. V2 ist Eigenschaft des aufgerufenen Funktionsbausteins Synchrone Verbuchung: Änderungen in der Datenbank erfolgen im Dialog-Workprozess (Aufruf der Funktionsbausteine durch Dialog-WP)

18 Kapitel 12: Transaktionsverwaltung 18 Datenbank-Interaktion: Ungebündelt Ungebündelte Aktualisierung Datenbank-Änderungen erfolgen direkt im PAI-Modul Allerdings: da nach jedem DynPro-Wechsel automatisch ein Commit erfolgt ist die ungebündelte Verbuchung nur dann möglich, wenn die LUW aus einem einzigen DynPro besteht Ansonsten sind keine ACID-Garantien möglich (Kompensation zur Fehlerbehebung wird nicht berücksichtigt)

19 Kapitel 12: Transaktionsverwaltung 19 Beispiel: Asynchrone gebündelte Verbuchung SAP-LUW Protokollsatzdatei CALL FUNCTION A IN UPDATE TASK EXPORTING... Funktion A (V1) Funktion B (V2) Funktion C (V1) Dialog-WP 1 Dialog-WP 3 Dialog-WP 1 Verb.-WP V x Verb.-WP V y PBO PAI SAP-Transaktion PBO PAI PBO PAI Commit Work Funktion A Funktion B Funktion C V1 Verbuchung V2 SELECT FROM Commit SELECT FROM Commit SELECT FROM Commit INSERT UPDATE Commit INSERT UPDATE Commit

20 Kapitel 12: Transaktionsverwaltung 20 Protokollsatzdatei: Lokale Version der LUW Dialogprogramm PAI PBO Protokollsatzdatei Verbuchungsprogramm Datenbank

21 SAP-Sperrmechanismus Um ungewollte und inkorrekte Wechselwirkungen paralleler Zugriffe auf gemeinsame Daten zu vermeiden, müssen sowohl Lese- als auch Schreiboperationen auf SAP-Objekten mit Sperren gekapselt werden Dies erfolgt jedoch nicht wie im Falle eines DBMS automatisch und transparent für den Benutzer Sperren müssen explizit im Anwendungsprogramm (ABAP) gesetzt werden Zentrale Sperrverwaltung (Enqueue-Workprozess) (ABAP-Befehl) Sperranforderung Datenzugriff (Open SQL- Befehl) Sperrfreigabe (ABAP-Befehl) Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 21

22 Kapitel 12: Transaktionsverwaltung 22 SAP-Sperrobjekte Sperrobjekte beinhalten eine (oder mehrere) Tabelle(n), aus denen betriebswirtschaftlich zusammengehörende Datensätze gleichzeitig gesperrt werden sollen Sperrobjekte werden im ABAP Dictionary angelegt Aus dem Sperrobjekt werden automatisch zwei Sperrbausteine generiert Enqueue-Baustein: Sperranforderung Dequeue-Baustein: Sperrfreigabe EZOHO00KTO Sperrobjekt; umfasst die Tabellen ZOHO00KTO und ZOHO00BUCH automatisch generiert ENQUEUE_EZOHO00KTO DEQUEUE_EZOHO00KTO ABAP-Funktionsbaustein für Sperranforderung ABAP-Funktionsbaustein für Sperrfreigabe

23 Kapitel 12: Transaktionsverwaltung 23 Sperranforderung Anwendungsserver A Anwendungsserver B Shared Memory BEGIN Call Function EZOHOxxKTO END BEGIN Call Function EZOHOxxKTO END 3 Sperrtabelle FUNCTION ENQUEUE_ EZOHO00KTO. ENDFUNCTION. Programm-Puffer 1 FUNCTION ENQUEUE_ EZOHO00KTO. ENDFUNCTION. ABAP-Interpreter 2 Enqueue-Workprozess Shared Memory Dialog-/ Batch- oder Verbuchungs-WP

24 Kapitel 12: Transaktionsverwaltung 24 Sperranforderung 1. Aufruf des Enqueue-Funktionsbausteins (CALL FUNCTION 'ENQUEUE_EZOHOKTO') durch den Dialog- Workprozess Mit Parametern der zu sperrenden Daten Modus der Sperre Auswahl der zu sperrenden Tupel (über deren Primärschlüssel) 2. Der Dialog-Workprozess übermittelt den Sperrantrag an den Enqueue-Workprozess 3. Der Enqueue-Workprozess überprüft anhand einer zentralen Sperrtabelle, ob die gewünschten Sätze bereits gesperrt sind Falls nicht: Sperre wird in die Sperrtabelle eintragen; der aufrufende Dialog-Workprozess setzt seine Arbeit fort Falls bereits gesperrt: Entweder Warten auf Freigabe oder Abbruch (dieses Verhalten ist ebenfalls als Parameter im Enqueue-Aufruf spezifiziert)

25 Kapitel 12: Transaktionsverwaltung 25 Sperrfreigabe Kann explizit erfolgen durch Aufruf des Dequeue-Funktionsbausteins CALL FUNCTION 'DEQUEUE_EZOHOKTO' Erfolgt automatisch bei Commit Work Rollback Work Ende der Dialogtransaktion Das Nicht-Berücksichtigen des expliziten Freigebens von SAP-Sperren führt also zu keinen Problemen (im Gegensatz zur Sperranforderung)

26 Kapitel 12: Transaktionsverwaltung 26 Zusammenfassung SAP-Transaktionsmodell SAP R/3 verfolgt einen Zweischichtenansatz Verwendet eigene Sperrverwaltung auf Anwendungsebene Sperren auf Datenbankobjekten nur kurz gehalten Besserer Ansatz als der anderer ERP-Systeme, die zumeist die triviale 1:1-Abbildung von A-Transaktionen auf D-Transaktionen verwenden Aber: Programmierer müssen explizit Sperren setzen! (Dies ist, verglichen mit dem Stand der Technik, ein grosser Rückschritt, mindestens optional sollten automatisch Sperren gesetzt werden) Es gibt keine Garantie des Systems, dass gemeinsame Zugriffe auf dieselbe Ressource (Datenbankobjekte) korrekt behandelt werden Der SAP-Transaktionsmanager kann durch Native SQL umgangen werden (man müsste föderierte Transaktionsverwaltung einsetzen, wenn man Native SQL zulässt) Es können (private) für andere Nutzer nicht sichtbare Versionen verwendet werden (über die Protokollsatzdatei)

27 Kapitel 12: Transaktionsverwaltung SAP R/3 Dialogprogrammierung Transaktionsverwaltung in SAP R/3 Aufruf von Sperrbausteinen Durchführung der Verbuchung Dialogprogrammierung Dynpros Modul-Pools (Ablauflogik) Vorbereitung der praktischen Übung (Ü9) mit SAP R/3 (Teil III)

28 Kapitel 12: Transaktionsverwaltung 28 Rückblick: Dialog-Workprozess Dialog-Workprozess DynPro-Interpreter Shared Memory ABAP-Interpreter Native SQL Tabellenpuffer Datenbank- Schnittstelle Open SQL Data Dictionary

29 Komponenten von Dialogtransaktionen Modulpool (ABAP-Programm) Implementierung der PBO- und PAI-Module Dynpro (mehrere pro Dialog-TA) Definition der Bildschirmmaske Zuordnung von Modulen aus dem Modulpool an PBO- und PAI-Zeitpunkt Festlegen der Felder der Maske und Zuordnung zu Variablen im Modulpool (gleiche Benennung!) Status (einmal pro Dynpro) Definition der aktiven Buttons der Dialogmaske Sperrbaustein Transaktion Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 29

30 Kapitel 12: Transaktionsverwaltung 30 Tools des R/3 Repository Data Modeler Datenmodellierung Data Dictionary Metadatenverwaltung Data Browser Zugriff auf Datenbanktabellen (nur Anwendungsdaten) Object Navigator Zugriff auf sämtliche Programmobjekte Entwicklungswerkzeuge ABAP-Editor Screen Painter Menu Painter (Definition von Buttons & Menüeinträgen)

31 Programmtypen Ausführbares Programm (Typ 1) Für Reports Nur Programme von diesem Typ können direkt abgearbeitet werden Modulpool (Typ M) Für Dialoganwendungen (Verarbeitungsschritte von DynPros) Nur über Transaktionsnummer aufrufbar Funktionsgruppe (Typ F) Sammlung von Funktionen Include-Programm (Typ I) Subroutinepool (Typ S) Klassen und Interfacedefinition (Typ K,J) Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 31

32 Kapitel 12: Transaktionsverwaltung 32 Process Before Output (PBO) Setzen des Dynpro-Status Welche Buttons sind aktiv? Welche Funktion ist jeweils hinterlegt? Initialisierung der Werte, die angezeigt werden sollen z.b. durch DB-Zugriff (Open oder Native SQL) Oder durch Übernahme von Werten aus dem Vorgänger-Dynpro

33 Kapitel 12: Transaktionsverwaltung 33 Process After Input (PAI) Verarbeitung der eingegebenen Daten Direkter Zugriff auf Datenbank Aufruf einer Verbuchungstask = Aufruf eines Funktionsbausteins (nicht im Modulpool definiert, sondern in Funktionsgruppe) CALL FUNCTION Verbuchung IN UPDATE TASK EXPORTING PARA1 = PARA2 =. Festlegen des Folge-Dynpros SET SCREEN Wechsel zum Folge-Dynpro Leave Screen.

34 Kapitel 12: Transaktionsverwaltung 34 Änderungsoperationen in Open-SQL Tables definiert Tabellenarbeitsbereich (für EIN Tupel) Elemente des Tupels können beliebig gesetzt (INSERT) bzw. verändert (UPDATE / MODIFY) werden Beispiel: TABLES zautor. ZAUTOR-Nachname = Frisch. ZAUTOR-Vorname = Friedrich. INSERT ZAUTOR. Fügt neues Tupel in DB ein (Schreiben in Protokollsatzdatei) ZAUTOR-Vorname = Max UPDATE ZAUTOR. Ändert das Tupel

35 Kapitel 12: Transaktionsverwaltung 35 ABAP: Datenbank-Interaktion in SAP-LUWs Asynchron Synchron Gebündelte Verbuchung Ungebündelte Verbuchung Verbuchung durch Verbuchungs-Workproszess (Funktionsbaustein) CALL FUNCTION verbucher IN UPDATE TASK. Verbuchung durch Dialog-Workproszess (Unterprogrammaufruf) PERFORM form_abc ON COMMIT. Verbuchung im PAI-Modul DB-Änderungen nicht in Unterprogrammaufruf gekapselt, sondern OpenSQL (INSERT, UPDATE) direkt im PAI-Modul

36 Kapitel 12: Transaktionsverwaltung 36 Verwendung von SAP R/3-Sperrobjekten *** Aufruf eines Sperrbausteins *** CALL FUNCTION 'ENQUEUE_EZOHO00KTO' EXPORTING *** Angabe der Sperrparameter *** MODE_ZOHO00KTO = E MODE_ZOHO00BUCH = E " beide Tabellen exklusiv (E) gesperrt " für Änderungen MANDT = SY-MANDT KUNNR = ZOHO00KTO-KUNNR KONTONR = ZOHO00KTO-KONTONR " Angabe der zu sperrenden Tupel über " Attribute KunNr und KontoNr _SCOPE = 2 " Sperre an Verbucher weitergeben EXCEPTIONS " Ausnahmebehandlung FOREIGN_LOCK = 1 " Sperre bereits gehalten...

37 Kapitel 12: Transaktionsverwaltung 37 Sperrmodi und Weitergabe SAP sieht drei verschiedene Modi für Sperren vor: MODE_... Schreibsperren (X) Exklusiver Zugriff auf die gesperrten Objekte Lesesperren (S) Gleichzeitiger lesender Zugriff erlaubt Nicht verträglich mit X oder E-Sperren Erweiterte Schreibsperren (E) ( kumulative Sperren ) Wie X ebenfalls exklusiver Zugriff Allerdings darf derselbe Anwender weitere E-Sperren auf einem Objekt, das er selbst mit E gesperrt hat, kumulieren Ebenso existieren drei verschiedene Optionen für die Weitergabe von Sperren zwischen Dialog- und Verbuchungsprozess (_SCOPE) _SCOPE = 1: Sperren werden nicht an Verbucher weitergegeben _SCOPE = 2: Sperre wird an Verbucher abgegeben; Dialog-WP gibt die Sperre dabei auf _SCOPE = 3: Sperre wird an Verbucher weitergegeben, bleibt aber auch gleichzeitig beim Dialog-WP

38 Transaktion Einstiegspunkt in Dialogtransaktion Angabe von Programmname (Modulpool) und Nummer des ersten Dynpros Aufruf durch Transaktionsnummer /nzvb00 Weiterer Kontrollfluss ist innerhalb der Transaktion, in den PAI-Modulen definiert Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 38

39 Kapitel 12: Transaktionsverwaltung 39 Praktische Übung (Ü9) Implementierung von Dialogtransaktionen Aufgabe 1: Einfacher Dialog, bestehend aus einem Dynpro Datenbankzugriff in PAI-Modul Skelett des Modulpools vorgegeben (ZOHO00SingleDynpro) Aufgabe 2: Anlegen eines Sperrbausteins Aufgabe 3: Dialog bestehend aus vier Dynpros Verwendung des Sperrbausteins Skelett ZOHO00DialogTransaction vorgegeben Aufgabe 4: Verbuchung in Verbuchungsprozess (Funktionsbaustein)

40 Kapitel 12: Transaktionsverwaltung 40 Aufgabe 3: Ablauflogik Dynpro 0100 Eingabe der Kontonummer Selektion der Kontodaten Aufruf Sperrbaustein Dynpro 0200 Eingabe der Konto-Buchung Sperrkonflikt Insert direkt in DB Dynpro 0300 OK Fehler Dynpro 0400 Bestätigung Fehlermeldung

41 Aufgabe 4 Verbuchungsfunktionsbaustein Dynpro 0100 Eingabe der Kontonummer Selektion der Kontodaten Aufruf Sperrbaustein Dynpro 0200 Eingabe der Konto-Buchung Aufruf der Verbuchung Sperrkonflikt OK Fehler Dynpro 0300 Dynpro 0400 Commit Work Ausführen der Verbuchung Rollback Work Verwerfen des Protokollsatzes Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 12: Transaktionsverwaltung 41

42 Kapitel 12: Transaktionsverwaltung 42 Zusammenspiel: Scheduling auf Anwendungs- und DB-Ebene A: Menge von Anwendungs- Aktionen CON: Konflikte zwischen A-Aktionen T: Menge von Anwendungs- Transaktionen T Anwendungs- Scheduler (t, Ü) Ü T : Ordnung der Aktionen innerhalb einer Transaktion T a: Menge von Datenbank- Aktionen con: Konflikte zwischen DB-Aktionen (t, fi): geordnete Menge von Datenbank-Transaktionen t Datenbank- Scheduler (τ, Ü) Ü t : Ordnung der Aktionen innerhalb einer Transaktion t