9.2 Sperrkonzept 
Beim Sperrkonzept muss man zwischen den Datenbanksperren der physischen Datenbank und den betriebswirtschaftlichen Sperren des SAP-Systems unterscheiden. Die Datenbanksperren des Datenbanksystems sind für die Anforderungen des SAP-Systems nicht ausreichend. Zwar verhängt das Datenbanksystem physische Sperren für die Datensätze, die durch Änderungsanweisungen angesprochen werden, diese Sperren gelten jedoch nur für einen SAP-Systemdialogschritt, d. h. einen Bildschirm. Da eine Transaktion einen kompletten betriebswirtschaftlichen Vorgang umfasst, genügen die Sperrkonzepte der physischen Datenbanksysteme für das SAP-System nicht.
Stellen Sie sich vor, Sie erfassen einen Auftrag. Die vollständige Erfassung beinhaltet mehrere Bildschirmbilder. Bevor Sie den abschließenden Bildschirm erreichen, merken Sie, dass Ihnen Daten für die vollständige Erfassung fehlen. In solchen Fällen muss es eine Möglichkeit geben, die angefangene Transaktion abzubrechen, ohne Teile davon bereits auf der Datenbank gebucht zu haben: Das Sperrkonzept des SAP-Systems ermöglicht das Sperren von Datensätzen über mehrere Dialogschritte hinweg.
Außerdem darf eine Sperre nicht nur für den Applikationsserver gelten, der die Sperre ausgelöst hat, sondern muss für alle Applikationsserver des SAP-Systems gelten. Dies bedeutet, dass die Sperren von mehreren Workprozessen erkannt werden müssen und gegebenenfalls entsprechende Reaktionen auslösen.
Aus diesen Gründen arbeitet das SAP-System mit einem eigenen, vom Datenbanksystem völlig unabhängigen Sperrkonzept. Die Grundlage hierzu bilden die Sperrobjekte. Diese ermöglichen auch das Sperren von Datensätzen mehrerer Datenbanktabellen bis zur Dauer einer gesamten SAP-Transaktion, sofern sie im ABAP Dictionary durch Fremdschlüsselbeziehungen verbunden sind.
Sperrobjekte müssen im ABAP Dictionary angelegt werden. Sie enthalten die Tabellen und die Schlüsselfelder, für die eine gemeinsame Sperre gelten soll. Es werden automatisch zwei Funktionsbausteine erzeugt: Ein Funktionsbaustein dient dem Setzen der Sperre für das Sperrobjekt und der andere dem Entsperren des Sperrobjektes. Im ABAP-Quellcode müssen diese Funktionsbausteine an der logisch richtigen Stelle aufgerufen werden. Damit sind Sie einerseits wirklich unabhängig von Sperrkonzepten eines Datenbanksystems, andererseits sind Sie aber selbst für das richtige Setzen und Freigeben von Sperren verantwortlich. Wie Sie Funktionsbausteine allgemein aufrufen, lernen Sie in Kapitel 13, »Modularisierung von Programmen«.
Die Funktionsbausteine zum Sperren und Entsperren werden in einem speziellen Workprozess ausgeführt. Sind in einem SAP-System mehrere Applikationsserver eingebunden, hat nur einer diesen speziellen Workprozess. Dieser Applikationsserver verwaltet auch eine zentrale Sperrtabelle für das gesamte System. In diese Sperrtabelle tragen die Funktionsbausteine die Sperre ein bzw. löschen sie, d. h. vereinfacht, dass die Funktionsbausteine einen Datensatz in die Sperrtabelle eintragen bzw. ihn löschen. Das Löschen kann durch den passenden Funktionsbaustein erfolgen, aber auch durch eine Verbuchung oder eine Transaktion. Die Beschreibung der letzten beiden Möglichkeiten würde hier aber zu weit führen und soll nicht weiter vertieft werden.
Auf diese Weise erfolgt die Sperre nicht beim physischen Datensatz auf dem Datenbanksystem, sondern als logische Sperre in einer zentralen Sperrtabelle. Deshalb müssen sich alle einschlägigen Anwendungsprogramme an die Konventionen des SAP-Sperrkonzeptes halten und die Sperrtabelle nach relevanten Einträgen abfragen.
Es gibt zwei Arten von Sperren: die Lese- und die Schreibsperre. Bei der Lesesperre dürfen andere Anwendungen ebenfalls eine Lesesperre setzen und lesend auf die Daten zugreifen. Lediglich das Setzen einer Schreibsperre, um Datensätze zu verändern, wird verhindert. Die Schreibsperre sperrt hingegen exklusiv; kein anderes Anwendungsprogramm kann für die Zeitdauer der Sperre schreibend oder lesend auf die gesperrten Daten zugreifen, und die anderen Anwender erhalten eine entsprechende Meldung.
[ ! ] Zeitpunktproblematik
Den richtigen Zeitpunkt zu finden, um eine Sperre zu setzen bzw. um sie wieder aufzuheben, ist eine sehr knifflige Angelegenheit. Setzt man die Sperre zu früh, blockiert man vielleicht unnötigerweise andere Anwender. Setzt man die Sperre zu spät, hat die Anwendung vielleicht das Nachsehen und Probleme, Daten zu aktualisieren. Entsprechend schwierig ist die Einschätzung des richtigen Zeitpunktes für das Wiederaufheben der Sperre. Wartet man zu lange, werden ebenfalls andere Anwendungen sinnlos blockiert.
Werden zu viele Lesesperren gesetzt, ist der schreibende Zugriff für eine Anwendung kaum mehr möglich. Eine unglücklich gesetzte Schreibsperre verhindert den lesenden Zugriff aller anderen Anwendungen. Demnach hängt es wieder einmal von der betriebswirtschaftlichen und technischen Aufgabenstellung ab, wann der richtige Zeitpunkt für bestimmte Maßnahmen ist.
Wie erwähnt, werden Sperren durch den jeweiligen Funktionsbaustein aufgehoben. Sollte der Aufruf durch einen Fehler nicht explizit erfolgen, werden Sperren automatisch während der Verbuchung oder am Ende der SAP-Transaktion aufgehoben.
[»] Sperren in der Dialogprogrammierung
Für den Einstieg in ABAP sollen diese Hinweise auf die Problematik von Berechtigungs- und Sperrkonzept vorerst genügen, da Sie üblicherweise nicht mit der Dialogprogrammierung beginnen werden. Doch bereits bei der Entwicklung von ABAP-Reports in der fortgeschrittenen Praxis müssen Sie diese Mechanismen berücksichtigen und bei Bedarf einbauen. Hier wird diese Thematik aber nicht weiterverfolgt. Für den Rest des Kapitels tun wir so, als ob Ihnen die Tabelle allein gehören würde.
Eine Bitte an alle fortgeschrittenen ABAP-Programmierer, die diese Zeilen vielleicht lesen: Sagen Sie jetzt nicht laut, was Ihnen auf der Zunge liegt. Einfach nur tief durchatmen und daran denken, dass jeder Entwickler spätestens nach der ersten schwierigen Fehlersuche wegen einer nicht gesetzten Sperre dauerhaft lernt, wie unverzichtbar Sperren in Wirklichkeit sind!
Einstieg in ABAP
