Funktionsbausteine für
Sperranforderungen
Durch die Aktivierung eines Sperrobjekts im ABAP Dictionary werden automatisch Funktionsbausteine für das Setzen (ENQUEUE_<Sperrobjektname>) und Freigeben (DEQUEUE_<Sperrobjektname>) von Sperren angelegt.
Die generierten Funktionsbausteine werden automatisch zu Funktionsgruppen zugeordnet. Sie sollten diese generierten Funktionsbausteine und deren Zuordnung zur Funktionsgruppe nicht ändern, da die Funktionsbausteine bei jeder neuen Aktivierung des Sperrobjekts wieder neu generiert werden.
Sie sollten die Funktionsgruppen, die die automatisch generierten Funktionsbausteine enthalten, niemals transportieren! Die generierten Funktionsbausteine eines Sperrobjekts können im Zielsystem in einer anderen Funktionsgruppe liegen! Transportieren Sie immer die Sperrobjekte! Bei der Aktivierung des Sperrobjekts im Zielsystem werden die Funktionsbausteine neu generiert und korrekt zu Funktionsgruppen zugeordnet.
Parameter der Funktionsbausteine
Feldnamen des Sperrobjekts
Hier müssen die zu sperrenden Schlüssel übergeben werden.
Zu jedem Sperrfeld <Feld> existiert ein weiterer Parameter X_<Feld>, der das Sperrverhalten bei Übergabe des Initialwertes bestimmt. Werden <Feld> und X_<Feld> mit dem Initialwert belegt, erfolgt bzgl. <Feld> eine generische Sperre. Wird <Feld> mit dem Initialwert und X_<Feld> mit X belegt, erfolgt die Sperre exakt mit dem Initialwert von <Feld>.
Parameter für die Sperrübergabe an den Verbucher
Eine Sperre wird in der Regel am Ende der Transaktion oder beim Aufruf des entsprechenden DEQUEUE-Funktionsbausteins aufgehoben. Falls die Transaktion Verbuchungsroutinen aufgerufen hat, gilt dies jedoch nicht mehr. In diesem Fall muß das Aufheben von Sperren über einen Parameter gesteuert werden.
Der Parameter _SCOPE steuert, wie die Sperre bzw. Sperrfreigabe an den
Verbucher weitergegeben wird (siehe
Das Eigentümerkonzept
von Sperren). Es gibt folgende Möglichkeiten:
· _SCOPE = 1: Sperren bzw. Sperrfreigaben werden nicht an den Verbucher weitergegeben. Die Sperre wird bei Beendigung der Transaktion aufgehoben.
· _SCOPE = 2: Die Sperre bzw. Sperrfreigabe wird an den Verbucher weitergegeben. Die Rücknahme der Sperre erfolgt durch den Verbucher. Der Dialog, aus dem heraus die Sperre gesetzt wurde, hat keinen Einfluß mehr auf das Sperrverhalten. Dies ist die Standardeinstellung für den ENQUEUE-Funktionsbaustein.
· _SCOPE = 3: Die Sperre bzw. Sperrfreigabe wird zusätzlich an den Verbucher weitergegeben. Die Sperre muß sowohl im Dialog als auch in der Verbuchung wieder freigegeben werden. Dies ist die Standardeinstellung für den DEQUEUE-Funktionsbaustein.
Parameter für den Sperrmodus
Für jede Basistabelle TAB des Sperrobjekts existiert ein Parameter MODE_<TAB>. Durch diesen Parameter kann der Sperrmodus für diese Basistabelle dynamisch gesetzt werden. Zulässige Werte für diesen Parameter sind S (Lesesperre), E (Schreibsperre), X (Erweiterte Schreibsperre) und O (Optimistische Sperre).
Der beim Anlegen des Sperrobjekts für die Tabellen angegebene Sperrmodus ist der Default-Wert für diesen Parameter. Dieser Default-Wert kann aber beim Aufruf des Funktionsbausteins beliebig übersteuert werden.
Soll eine mit einem Sperrmodus gesetzte Sperre durch Aufruf des DEQUEUE-Funktionsbausteins wieder aufgehoben werden, so muß dieser Aufruf mit dem gleichen Wert für den Parameter MODE_<TAB> erfolgen.
Steuerung des Abschickens der Sperre
Ob die Anforderung einer Sperre oder das Aufheben einer Sperre direkt erfolgt oder vorerst nur in den lokalen Sperrcontainer geschrieben wird, kann über den Parameter _COLLECT gesteuert werden. Dieser Parameter kann mit folgenden Werten belegt werden:
· Initialwert: Die Sperranforderung bzw. die Sperrfreigabe wird direkt an den Sperrserver abgeschickt.
· X : Die Sperranforderung bzw. Sperrfreigabe wird in den lokalen Sperrcontainer gestellt. Die in diesem Sperrcontainer aufgesammelten Sperranforderungen bzw. Sperrfreigaben können dann zu einem späteren Zeitpunkt durch Aufruf des Funktionsbausteins FLUSH_ENQUEUE gemeinsam an den Sperrserver abgeschickt werden.
Bei Sperrmodus X (Erweiterte Schreibsperre) sollten Sperren dann nicht in den lokalen Sperrcontainer geschrieben werden, wenn sich sehr viele Sperren auf dieselbe Sperrtabelle beziehen. In diesem Fall kommt es nämlich im Vergleich zum direkten Abschicken der Sperren zu erheblichen Performance-Verlusten.
Verhalten bei Sperrkonflikten (nur ENQUEUE)
Der ENQUEUE-Funktionsbaustein besitzt
noch den Parameter _WAIT. Dieser Parameter bestimmt das Sperrverhalten beim
Auftreten eines
Sperrkonflikts.
Es gibt folgende Möglichkeiten:
· Initialwert: Schlägt ein Sperrversuch fehl, weil bereits eine überschneidende Sperre gesetzt ist, wird die Ausnahme FOREIGN_LOCK ausgelöst.
· X : Schlägt ein Sperrversuch fehl, weil bereits eine überschneidende Sperre gesetzt ist, wird der Sperrversuch nach einer Wartezeit erneut unternommen. Nur wenn ein bestimmtes Zeitlimit seit dem ersten Sperrversuch überschritten wurde, wird die Ausnahme FOREIGN_LOCK ausgelöst. Die Wartezeit und das Zeitlimit werden durch Profile-Parameter bestimmt.
Steuerung des Löschens des Sperreintrags (nur DEQUEUE)
Der DEQUEUE-Funktionsbaustein besitzt noch den Parameter _SYNCHRON.
Wenn X übergeben wird, dann wartet die DEQUEUE-Funktion, bis der Eintrag tatsächlich aus der Sperrtabelle gelöscht wurde. Andernfalls erfolgt das Löschen asynchron, d.h. wenn sofort nach dem Entsperren die Sperrtabelle gelesen wird, kann unter Umständen der Sperreintrag noch vorgefunden werden.
Ausnahmen des ENQUEUE-Funktionsbausteins
· FOREIGN_LOCK: Es existiert bereits eine überschneidende Sperre. Der Benutzer, der die Sperre hält, kann der Systemvariablen SY-MSGV1 entnommen werden.
· SYSTEM_FAILURE: Diese Ausnahme wird ausgelöst, wenn der Sperrserver meldet, daß ein Problem beim Setzen der Sperre aufgetreten ist. Die Sperre konnte in diesem Fall nicht gesetzt werden.
Falls die Ausnahmen vom Aufrufer nicht selbst behandelt werden, werden zu allen Ausnahmen entsprechende Nachrichten gesendet.
Bezugsfelder bei RFC-fähigen Sperrobjekten
Ein RFC-fähiger Funktionsbaustein muß vollständig typisiert sein. Die Parameter der generierten Funktionsbausteine werden deshalb bei RFC-fähigen Sperrobjekten mit den folgenden Bezugsfeldern versehen:
Parameter |
Bezugsfelder |
X_<Feldname> |
DDENQ_LIKE-XPARFLAG |
_WAIT |
DDENQ_LIKE-WAITFLAG |
_SCOPE |
DDENQ_LIKE-SCOPE |
_SYNCHRON |
DDENQ_LIKE-SYNCHRON |
Siehe auch: