_SCOPE-Parameter 
Parameter, mit dem der Anwendungsprogrammierer festlegt, welchem der zwei Eigentümer die Sperre wirklich gehören soll.
_SCOPE kann die Werte 1,2 oder 3 annehmen.
Zu Beginn einer SAP-LUW werden automatisch zwei Sperreigentümer angelegt. Der Dialogeigentümer und der Verbuchungseigentümer. Mit diesem Parameter legen Sie den oder die Eigentümer für Ihre Sperre fest und steuern so das Verhalten der Sperre während der SAP-LUW.
Struktur
Folgende Werte sind möglich.
Wert |
Bedeutung |
|---|---|
_SCOPE = 1 |
Die Sperre gehört nur dem Dialogeigentümer (Eigentümer_1), bleibt also nur in der Dialogtransaktion bestehen. Die Sperre wird durch den DEQUEUE-Aufruf oder durch das Ende der Transaktion aufgehoben, nicht durch COMMIT WORK oder ROLLBACK WORK |
_SCOPE = 2 |
Die Sperre gehört nur dem Verbuchungseigentümer (Eigentümer_2), wird also an die Verbuchung vererbt, wenn CALL FUNCTION '...' IN UPDATE TASK und COMMIT WORK aufgerufen wird. Sie wird aufgehoben, wenn die Verbuchungstransaktion abgeschlossen ist. Bevor die Sperre an die Verbuchung übergeben wird, kann sie mit ROLLBACK WORK aufgehoben werden. COMMIT WORK hat keinen Einfluss, solange nicht CALL FUNCTION '...' IN UPDATE TASK aufgerufen wurde. |
_SCOPE = 3 |
Die Sperre gehört beiden Eigentümern (Eigentümer_1 und Eigentümer_2), kombiniert also die beiden Verhaltensweisen. Sie wird aufgehoben, wenn der letzte der beiden Eigentümer die Sperre freigibt. |
Da der _SCOPE-Parameter keine Eigenschaft der Sperre selbst, sondern ein Parameter der Sperroperation ist, kann auch zu einer bestehenden Sperre der Funktionsbaustein erneut aufgerufen werden. So kann eine Sperre mit einem Dialogeigentümer (_SCOPE=1) durch erneuten Aufruf mit _SCOPE=2 um einen Verbuchungseigentümer erweitert werden. Das Resultat dieser 2 Aufrufe ist dann nicht von einem Aufruf mit _SCOPE=3 zu unterscheiden.
Nach Beendigung der Verbuchung ändert eine _SCOPE=3 Sperre ihren Charakter in SCOPE = 1. Falls erneut verbucht werden soll, muss ein neuer Aufruf mit _SCOPE = 2 erfolgen.
Weitere Informationen:
Beispiel
Die folgende Abbildung zeigt die Sperren im Verlauf einer SAP-LUW im Zusammenhang mit dem _SCOPE-Parameter. Es wird dargestellt, wie lange die SAP-Sperren aktiv sind (das sind nicht die tatsächlichen Datenbanksperren, wie unter SAP-Sperrkonzept beschrieben).
Die Sperre besteht solange, bis entweder der entsprechende DEQUEUE-Funktionsbaustein aufgerufen wird oder (wie im Bild dargestellt) die Transaktion mit einem impliziten DEQUEUE_ALL endet.
SAP-Sperren und _SCOPE-Werte
In diesem Beispiel wird also im Laufe der Transaktion das Sperrobjekt A (das der Programmierer vorher im ABAP Dictionary angelegt hat) durch den Funktionsaufruf CALL FUNCTION 'ENQUEUE_A' gesperrt. Durch Setzen des _SCOPE-Parameters auf 1 wird festgelegt, dass die Sperre A nicht an den Verbucher weitergegeben wird (sie gehört nur dem Dialogeigentümer E_1) und damit mit dem Funktionsaufruf DEQUEUE_A oder spätestens mit dem Ende der Dialogtransaktion aufgehoben wird.
Später werden die Sperre B, die E_2 (dem Verbuchungseigentümer) gehört (_SCOPE=2) und die Sperre C, die zwei Eigentümer hat (_SCOPE=3), angefordert. Mit dem Aufruf CALL FUNCTION '...' IN UPDATE TASK wird ein Verbuchungsauftrag generiert. Beim COMMIT WORK wird der Verbucher aufgerufen, der die Sperren und den Verbuchungseigentümer der Sperren B und C erbt. Mit dem Ende der Verbuchung werden diese Sperren freigegeben. Es ist aber möglich, dass die Sperre C des Dialogeigentümers noch länger besteht (je nach Programmierung der Transaktion).
Dia Dialogsperren A und C bestehen noch bis zum Ende der Dialogtransaktion.
Achtung
Wird eine Sperre mit _SCOPE=2 gesetzt, und der COMMIT WORK-Aufruf erfolgt vor dem CALL FUNCTION '...' IN UPDATE TASK, so bleibt die Sperre bis zu diesem Zeitpunkt als Dialogsperre (schwarz in der Übersicht der Transaktion SM12) stehen. Sie konnte ja noch nicht an einen Verbuchungs-Workprozess übergeben werden.
Erst der Aufruf von CALL FUNCTION '...' IN UPDATE TASK und das COMMIT WORK zu einem späteren Zeitpunkt bewirkt, dass die Sperre an den Verbuchungsprozess übergeben wird. Sie ist dann in der Detailansicht der Sperrverwaltung (Transaktion SM12 Details) mit dem Backup-Flag als Sperre gekennzeichnet, die einem Verbuchungsauftrag gehört.