Kapitel 12: "Transaktionsverwaltung in ERP
Werbung
Kap. 12 Transaktionsverwaltung in ERP-Systemen 12.1 Mehrstufige Transaktionsverwaltung 12.2 Transaktionen und „Logical Units of Work“ (LUWs) in SAP R/3 12.3 Workshop: ABAP-Dialogprogrammierung Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 1 12.1 Mehrstufige Transaktionsverwaltung … Client A-SQL AS In ERP-Systemen (allgemein: in mehrstufigen Client/Server-Architekturen) unterscheidet man zwei wesentliche Abstraktionsebenen: • • Daher werden Anwendungsobjekte (AS-Objekte) oder Business Objects oberhalb von Datenbankobjekten (DBMS-Objekte) betrachtet. Wir nehmen im folgenden an, dass … • D-SQL DBMS Anwendungsserver (AS) und Speicherserver; der Speicherserver ist ein DBMS • … 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 DBMSObjekten festgelegt ist (also auch die Abbildung von A-SQL auf D-SQL) Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 2 … 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? Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 3 … 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 2002 Kapitel 12: Transaktionsverwaltung – 4 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. Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 5 … Zweistufige Transaktionen t3 A4 t4 A5 t5 Commit t2 A3 Commit t1 A2 Commit A1 Commit DB-Objekte Anwendungs-Transaktion Commit AnwendungsObjekte ti: 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 2002 Kapitel 12: Transaktionsverwaltung – 6 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 2002 Kapitel 12: Transaktionsverwaltung – 7 Insert Select ? ? ? Update ? ? ? ? Delete ? ? ? ? Insert ? ? ? ? Select Delete Update Beispiel: Sperrverträglichkeit für A-SQL-Aktionen 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 XSperren, wie im einfachen Read/ Write-Modell: bei Select S, sonst X. Inverse können automatisch generiert werden: • Select: nil • Update: Update rückgängig • Insert: Delete • Delete: Insert Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 8 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-SchedulerStapel aufgefasst werden SAP-Scheduler DB-Scheduler Objektverwaltung höherer Ordnung (OHO) – SS 2002 Sperrverwaltung für SAP-Objekte Sperrverwaltung für DBObjekte Kapitel 12: Transaktionsverwaltung – 9 12.2 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 Di (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. • • Transaktionen und LUWs in SAP R/3 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 2002 Kapitel 12: Transaktionsverwaltung – 10 SAP/R3: Transaktionen, Verbuchung und LUWs Sperrdauer für SAP- Objekte SAP-Logical Unit of Work (LUW) t4 t5 V2 Commit t3 V1 Commit t2 D4 Commit t1 D3 Commit DB-Objekte D2 Commit D1 SAP-Verbuchung t6 Commit SAP-Transaktion SAP-Objekte Sperrdauer für Datenbank-Objekte Di: Vi: ti: Dialogschritte (DynPros) Verbuchungsschritte DB-Transaktionen Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 11 Architektur von SAP R/3: Prozess-orientierte Sichtweise X-Server SAPGUIProzess BatchWorkprozess VerbuchungsWorkprozess SAPGUIProzess Dispatcher DialogWorkprozess PC Präsentation SpoolWorkprozess EnqueueWorkprozess Anwendungslogik Datenhaltung Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 12 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 Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 13 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 2002 Kapitel 12: Transaktionsverwaltung – 14 Dialog- und Verbuchungs-WPs VerbuchungsWorkprozess Dialog-Workprozess 2 D12 Dialog-Workprozess 1 Transaktion 3 Transaktion 2 Transaktion 1 D21 D31 D22 D11 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 2002 Kapitel 12: Transaktionsverwaltung – 15 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 Output Modul (PBO) DynPro Bildschirmausgabe Benutzereingabe Objektverwaltung höherer Ordnung (OHO) – SS 2002 Input Modul (PAI) Output Modul (PBO) … Kapitel 12: Transaktionsverwaltung – 16 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) Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 17 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) Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 18 Beispiel: Asynchrone gebündelte Verbuchung SAP-LUW Protokollsatzdatei Funktion A (V1) Funktion B (V2) Funktion C (V1) PAI PBO Dialog-WP1 PAI PBO PAI SELECT … FROM … Objektverwaltung höherer Ordnung (OHO) – SS 2002 Commit SELECT … FROM … Commit SELECT … FROM … Commit SAP-Transaktion Verb.-WP Vx Verb.-WP Vy Funktion A Funktion C Funktion B V1 Verbuchung INSERT… UPDATE… V2 INSERT… UPDATE… Commit PBO Dialog-WP3 Commit Work Dialog-WP1 Commit CALL FUNCTION A IN UPDATE TASK EXPORTING ... Kapitel 12: Transaktionsverwaltung – 19 Protokollsatzdatei: Lokale Version der LUW Dialogprogramm Dialogprogramm PAI PBO Protokollsatzdatei Protokollsatzdatei Verbuchungsprogramm Verbuchungsprogramm Datenbank Datenbank Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 20 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) Sperranforderung (ABAP-Befehl) Datenzugriff (Open SQLBefehl) Objektverwaltung höherer Ordnung (OHO) – SS 2002 Sperrfreigabe (ABAP-Befehl) Kapitel 12: Transaktionsverwaltung – 21 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 automatisch generiert Sperrobjekt; umfasst die Tabellen ZOHO00KTO und ZOHO00BUCH ENQUEUE_EZOHO00KTO ABAP-Funktionsbaustein für Sperranforderung DEQUEUE_EZOHO00KTO ABAP-Funktionsbaustein für Sperrfreigabe Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 22 Sperranforderung … Anwendungsserver A Anwendungsserver B Shared Memory BEGIN … Call Function EZOHOxxKTO … … END BEGIN … Call Function EZOHOxxKTO … END … FUNCTION ENQUEUE_ EZOHO00KTO. … ENDFUNCTION. 1 FUNCTION ENQUEUE_ EZOHO00KTO. … ENDFUNCTION. Programm-Puffer ABAP-Interpreter Shared Memory Dialog-/ Batch- oder Verbuchungs-WP Objektverwaltung höherer Ordnung (OHO) – SS 2002 3 Sperrtabelle 2 Enqueue-Workprozess Kapitel 12: Transaktionsverwaltung – 23 … Sperranforderung 1. Aufruf des Enqueue-Funktionsbausteins (CALL FUNCTION 'ENQUEUE_EZOHOKTO') durch den DialogWorkprozess • 2. 3. Mit Parametern der zu sperrenden Daten – Modus der Sperre – Auswahl der zu sperrenden Tupel (über deren Primärschlüssel) Der Dialog-Workprozess übermittelt den Sperrantrag an den Enqueue-Workprozess 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) Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 24 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) Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 25 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) Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 26 12.3 Transaktionsverwaltung in SAP R/3 • • Aufruf von Sperrbausteinen Durchführung der Verbuchung Dialogprogrammierung • • SAP R/3 – Dialogprogrammierung Dynpros Modul-Pools (Ablauflogik) Vorbereitung der praktischen Übung (Ü9) mit SAP R/3 (Teil III) Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 27 Rückblick: Dialog-Workprozess Dialog-Workprozess Shared Memory DynPro-Interpreter ABAP-Interpreter Native SQL Open SQL DatenbankSchnittstelle Objektverwaltung höherer Ordnung (OHO) – SS 2002 Data Dictionary Tabellenpuffer Kapitel 12: Transaktionsverwaltung – 28 Komponenten von Dialogtransaktionen Modulpool (ABAP-Programm) • 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) • Implementierung der PBO- und PAI-Module Definition der aktiven Buttons der Dialogmaske Sperrbaustein Transaktion Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 29 Tools des R/3 Repository Data Modeler • Data Dictionary • Zugriff auf Datenbanktabellen (nur Anwendungsdaten) Object Navigator • Metadatenverwaltung Data Browser • Datenmodellierung Zugriff auf sämtliche Programmobjekte Entwicklungswerkzeuge • • • ABAP-Editor Screen Painter Menu Painter (Definition von Buttons & Menüeinträgen) Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 30 Programmtypen Ausführbares Programm (Typ 1) • • Modulpool (Typ M) • • Für Dialoganwendungen (Verarbeitungsschritte von DynPros) Nur über Transaktionsnummer aufrufbar Funktionsgruppe (Typ F) • Für Reports Nur Programme von diesem Typ können direkt abgearbeitet werden Sammlung von Funktionen Include-Programm (Typ I) Subroutinepool (Typ S) Klassen und Interfacedefinition (Typ K,J) Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 31 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 Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 32 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 0200. Wechsel zum Folge-Dynpro Leave Screen. Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 33 Ä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’. “ Fügt neues Tupel in DB ein INSERT ZAUTOR. “ (Schreiben in Protokollsatzdatei) ZAUTOR-Vorname UPDATE ZAUTOR. = ‘Max’ “ Ändert das Tupel Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 34 ABAP: Datenbank-Interaktion in SAP-LUWs Asynchron Gebündelte Verbuchung Verbuchung durch Verbuchungs-Workproszess (Funktionsbaustein) CALL FUNCTION verbucher IN UPDATE TASK. Synchron Verbuchung durch Dialog-Workproszess (Unterprogrammaufruf) PERFORM form_abc ON COMMIT. Verbuchung im PAI-Modul Ungebündelte Verbuchung Objektverwaltung höherer Ordnung (OHO) – SS 2002 DB-Änderungen nicht in Unterprogrammaufruf gekapselt, sondern OpenSQL (INSERT, UPDATE) direkt im PAI-Modul Kapitel 12: Transaktionsverwaltung – 35 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 KUNNR KONTONR = SY-MANDT = ZOHO00KTO-KUNNR = 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 ... Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 36 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: _SCOPE = 2: • _SCOPE = 3: Sperren werden nicht an Verbucher weitergegeben Sperre wird an Verbucher abgegeben; Dialog-WP gibt die Sperre dabei auf Sperre wird an Verbucher weitergegeben, bleibt aber auch gleichzeitig beim Dialog-WP Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 37 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 2002 Kapitel 12: Transaktionsverwaltung – 38 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) Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 39 Aufgabe 3: Ablauflogik Dynpro 0100 Eingabe der Kontonummer Selektion der Kontodaten Aufruf Sperrbaustein Dynpro 0200 Eingabe der Konto-Buchung Sperrkonflikt Insert direkt in DB OK Fehler Dynpro 0300 Dynpro 0400 Bestätigung Fehlermeldung Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 40 Aufgabe 4 Dynpro 0100 Eingabe der Kontonummer Selektion der Kontodaten Aufruf Sperrbaustein Verbuchungsfunktionsbaustein Dynpro 0200 Eingabe der Konto-Buchung Sperrkonflikt Aufruf der Verbuchung OK Fehler Dynpro 0300 Dynpro 0400 Commit Work Ausführen der Verbuchung Rollback Work Verwerfen des Protokollsatzes Objektverwaltung höherer Ordnung (OHO) – SS 2002 Kapitel 12: Transaktionsverwaltung – 41
