Funktionsbausteine für
Sperranforderungen
Verwendung
Wenn Sie ein Sperrobjekt im ABAP Dictionary aktivieren, 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 erneuten Aktivierung des Sperrobjekts wieder neu generiert werden.
Sie sollten die Funktionsgruppen, die die automatisch generierten Funktionsbausteine enthalten, nicht transportieren. Die generierten Funktionsbausteine eines Sperrobjekts können im Zielsystem in einer anderen Funktionsgruppe liegen. Transportieren Sie immer die Sperrobjekte. Wenn Sie ein Sperrobjekt im Zielsystem aktivieren, werden die Funktionsbausteine neu generiert und korrekt zu Funktionsgruppen zugeordnet.
Funktionsumfang
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, wird für <Feld> eine generische Sperre initialisiert. Wird <Feld> mit dem Initialwert und X_<Feld> mit X belegt, wird die Sperre exakt mit dem Initialwert von <Feld> gesetzt.
Parameter für die Sperrübergabe an den Verbucher
Eine Sperre wird am Ende der Transaktion oder beim Aufruf des entsprechenden DEQUEUE-Funktionsbausteins aufgehoben.
Dies ist nicht der Fall, wenn die Transaktion Verbuchungsroutinen aufgerufen hat. In diesem Fall muss 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 Einfluss 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 muss 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 Tabelle angegebene Sperrmodus ist der Default-Wert für diesen Parameter. Diesen Default-Wert können Sie jedoch beim Aufruf des Funktionsbausteins beliebig übersteuern.
Soll eine mit einem Sperrmodus gesetzte Sperre durch Aufruf des DEQUEUE-Funktionsbausteins wieder aufgehoben werden, so muss 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 erfolgen oder vorerst nur in den lokalen Sperrcontainer geschrieben werden muss, wird über den Parameter _COLLECT gesteuert. Dieser Parameter kann mit folgenden Werten belegt werden:
● Initialwert:
Die Sperranforderung bzw. die Sperrfreigabe wird direkt an den Sperrserver abgeschickt.
● X:
Die Sperranforderung bzw. die Sperrfreigabe wird in den lokalen Sperrcontainer gestellt. Die in diesem Sperrcontainer gesammelten 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) dürfen Sperren nicht in den lokalen Sperrcontainer geschrieben werden, wenn sich viele Sperren auf dieselbe Sperrtabelle beziehen. In diesem Fall kommt es 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 Profilparameter 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, dass 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 muss vollständig typisiert sein. Die Parameter des generierten Funktionsbausteins werden 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: