11.3 Transaktionen und LUWs in SAP R/3

Transkript

1 11.3 Transaktionen und LUWs in SAP R/3 G 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 G 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) G SAP-Objekte werden für die Dauer der SAP-LUW gesperrt, DB-Objekte nur während der DB-Transaktion (also kurz) Kapitel 11: Transaktionsverwaltung 1

2 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 t 2 t 3 t 4 t 5 t 6 Sperrdauer für Datenbank-Objekte D i : Dialogschritte (DynPros) V i : Verbuchungsschritte t i : DB-Transaktionen Kapitel 11: Transaktionsverwaltung 2

3 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 Kapitel 11: Transaktionsverwaltung 3

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

5 SAP-LUWs vs. Datenbank-Transaktionen G Jedes DynPro kann von einem unterschiedlichen Workprozess bearbeitet werden G 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- aus. Ein einzelnes DynPro entspricht also einer DB-Transaktion G 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 Kapitel 11: Transaktionsverwaltung 5

6 Dialog- und Verbuchungs-WPs Verbuchungs- Workprozess Dialog-Workprozess Transaktion 3 D3 1 Transaktion 2 D2 1 D2 2 Transaktion 1 D1 1 Zeitachse LUW 1 LUW 2 (Transaktion wird durch LUW 3 unterbrochen) LUW 3 (Verbuchung wird vom Dialog-WP ausgeführt) Kapitel 11: Transaktionsverwaltung 6

7 SAP R/3-Dialogschritte: DynPro-Konzept G Dialogprogramm = Folge von Dialogschritten G Jeder Dialogschritt entspricht einem DynPro (dynamisches Programm) G 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) Kapitel 11: Transaktionsverwaltung 7

8 Datenbank-Interaktion: Gebündelt G 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) Kapitel 11: Transaktionsverwaltung 8

9 Datenbank-Interaktion: Ungebündelt G Ungebündelte Aktualisierung Datenbank-Änderungen erfolgen direkt im PAI-Modul Allerdings: da nach jedem DynPro-Wechsel automatisch ein 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) Kapitel 11: Transaktionsverwaltung 9

10 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 Work Funktion A Funktion B Funktion C V1 Verbuchung V2 SELECT FROM SELECT FROM SELECT FROM INSERT UPDATE INSERT UPDATE Kapitel 11: Transaktionsverwaltung 10

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

12 SAP-Sperrmechanismus G 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 G 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 G Zentrale Sperrverwaltung (Enqueue-Workprozess) (ABAP-Befehl) Sperranforderung Datenzugriff (Open SQL- Befehl) Sperrfreigabe (ABAP-Befehl) Kapitel 11: Transaktionsverwaltung 12

13 SAP-Sperrobjekte G Sperrobjekte beinhalten eine (oder mehrere) Tabelle(n), aus denen betriebswirtschaftlich zusammengehörende Datensätze gleichzeitig gesperrt werden sollen G Sperrobjekte werden im ABAP Dictionary angelegt G 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 Kapitel 11: Transaktionsverwaltung 13

14 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 Kapitel 11: Transaktionsverwaltung 14

15 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) Kapitel 11: Transaktionsverwaltung 15

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

17 Zusammenfassung SAP-Transaktionsmodell G SAP R/3 verfolgt einen Zweischichtenansatz Verwendet eigene Sperrverwaltung auf Anwendungsebene Sperren auf Datenbankobjekten nur kurz gehalten G 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-Transkationsmanager 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) Kapitel 11: Transaktionsverwaltung 17