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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
Kapitel 12: Transaktionsverwaltung – 7
Select
Update
Delete
Insert
Beispiel: Sperrverträglichkeit für A-SQL-Aktionen
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 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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
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 2003
Kapitel 12: Transaktionsverwaltung – 41
Zusammenspiel: Scheduling auf Anwendungs- und DB-Ebene
A: Menge von
AnwendungsAktionen
CON: Konflikte
zwischen
A-Aktionen
a: Menge von
DatenbankAktionen
con: Konflikte
zwischen
DB-Aktionen
T:
Menge von AnwendungsTransaktionen T
AnwendungsScheduler
ÜT: Ordnung der
Aktionen innerhalb einer
Transaktion T
(t, Ü)
(t, fi): geordnete Menge von
Datenbank-Transaktionen t
DatenbankScheduler
(τ, Ü)
Objektverwaltung höherer Ordnung (OHO) – SS 2003
Üt: Ordnung der
Aktionen innerhalb einer
Transaktion t
Kapitel 12: Transaktionsverwaltung – 42
Herunterladen