Enqueue-Server 
Der Enqueue-Server (auch Sperrserver genannt) ist die Komponente im SAP-System, die die Sperrtabelle verwaltet.
In einem verteilten SAP-System gibt es genau einen Enqueue-Server. Für diesen gibt es verschiedene Installationsoptionen:
Der Enqueue-Server kann in einer Instanz als Enqueue-Workprozess konfiguriert sein. Diese Instanz wird dann als „Zentralinstanz“ bezeichnet. Diese Installationsoption wird vor allem bei älteren ABAP-only-Systemen und bei Systemen, die nur aus einer Instanz bestehen, eingesetzt.
Der Enqueue-Server kann im Rahmen einer eigenen Instanz installiert werden. Dann kommt der Standalone-Enqueue-Server zum Einsatz, der zusammen mit dem Message-Server die SCS-Instanz (SAP, Central Services – AS Java) bzw. die ASCS-Instanz (ABAP Central Services – AS ABAP) bildet. Diese Instanz ist dann ein Single-Point-Of-Failure, der mit dem Enqueue Replication Server hochverfügbar ausgelegt werden kann.
Funktionsumfang
Der Enqueue-Server nimmt Sperranfragen entgegen und prüft anhand der Sperrtabelle, ob die Sperranforderung mit einer schon gesetzten Sperre kollidiert. In diesem Fall weist er die Anforderung zurück, ansonsten setzt er die Sperre und nimmt den entsprechenden Eintrag in der Sperrtabelle vor.
Achtung
Wenn der Enqueue-Server durchgestartet wird, gehen Sperren verloren, sofern sie nicht in der Backup-Datei auf der Festplatte gesichert wurden. In dieser Datei werden diejenigen Sperren gesichert, die bei COMMIT WORK nach CALL FUNCTION .. IN UPDATE TASK an den Verbucher vererbt werden. Die Sicherung in der Backup-Datei erfolgt zu dem Zeitpunkt, zu dem der Verbuchungsauftrag gültig wird, also im o.g. COMMIT WORK. Bei jedem Neustart des Enqueue-Servers werden die auf gesicherten Sperreinträge in die Sperrtabelle zurückgeladen.
Wenn der Enqueue Replication Service als Teil einer Hochverfügbarkeits-Lösung verwendet wird, gehen Sperren auch beim Ausfall oder Durchstart des Enqueue-Servers nicht verloren.
Kommunikationsmodell
Da Kommunikationsmodell hängt von der gewählten Installationsoption ab.
Beim Einsatz des Standalone-Enqueue-Servers in einer SCS- oder ASCS-Instanz kommunizieren die ABAP-Workprozesse bzw. die Java-Server-Prozesse direkt mit dem Enqueue-Server.
Im „klassischen“ ABAP-System mit einer Zentralinstanz und mehreren Dialoginstanzen geht die Sperranforderung über den lokalen Dispatcher und den Message-Server zu dem Dispatcher der Zentralinstanz, der die Anfrage dann an den Enqueue-Workprozess weitergibt. Die Workprozesse auf der Zentralinstanz haben direkt Zugriff auf die Sperrtabellenfunktionalität. Sie müssen ihre Sperranforderungen nicht via Dispatcher und Message-Server versenden.
Die folgende Grafik zeigt den Kommunikationsweg in einem verteilten SAP-System mit Zentralinstanz und weiteren Instanzen.
„Klassische“ Zentralinstanz mit Enqueue-Workprozess
Im Hauptspeicher (Shared Memory) der Zentralinstanz liegt die Sperrtabelle. Zugriff auf die Sperrtabelle haben alle Workprozesse der Zentralinstanz. Fremde Applikationsserver lassen ihre Sperroperationen im Enqueue-Prozess der Zentralinstanz ausführen. Die Kommunikation erfolgt dann über die betroffenen Dispatcher und den Message-Server.
HinweisObwohl bei einem zentralen (ABAP-)System der Enqueue-Workprozess nicht genutzt wird, da alle Workprozesse gleichermaßen Zugang auf das Shared Memory und damit auf die Sperrtabelle haben (vgl. Grafik), ist die Konfiguration eines Enqueue-Servers (Parameter rdisp/enqname) sowie eines Enqueue-Workprozesses (rdisp/wp_no_enq = 1) zwingend erforderlich.
Sind diese Parameter nicht korrekt gesetzt, meldet die Konsistenzprüfung (Transaktion SICK) einen Installationsfehler.
Ende des Hinweises.