Standalone-Enqueue-Server 
Die Enqueue-Funktionalität steht nicht nur in der klassischen ABAP-Zentralinstanz zur Verfügung, sondern auch in Form eines Standalone-Servers, der nicht in den AS ABAP eingebunden ist. In folgenden Szenarien kommt der Standalone-Enqueue-Server zum Einsatz:
Der AS Java stellt einen Locking Service zur Verfügung, der auf die Enqueue-Funktionalität aufbaut. Hierbei wird der Standalone-Enqueue-Server eingesetzt, der zusammen mit dem Message-Server die SCS-Instanz bildet.
Um den Enqueue Service im AS ABAP hochverfügbar auszulegen, muss der Enqueue Service aus der Zentralinstanz herausgenommen werden. Er wird dann durch den Standalone-Enqueue-Server zur Verfügung gestellt. Sie haben dann statt der klassischen Zentralinstanz (kompletter Applikationsserver mit Enqueue-Workprozess und Sperrtabelle) eine SCS-Instanz für den AS ABAP (ASCS-Instanz). Wie bei der SCS-Instanz des AS Java ist auch hier der Message-Server Teil der ASCS-Instanz.
Einführungshinweise
Der Einsatz des Standalone-Enqueue-Servers bietet folgende Vorteile:
Die Kommunikation zwischen den Enqueue-Clients (SAP Applikationsserver) und dem Enqueue-Server erfolgt nicht mehr über die beteiligten Dispatcher und den Message-Server, sondern direkt, d.h. der Workprozess hat eine TCP-Verbindung zum Enqueue-Server.
Sie können den Standalone-Enqueue-Server im Rahmen des HA-Enqueue-Servers einsetzen (mit Replikationsserver) und somit den Enqueue-Service ausfallsicher machen. Die Verfahren dafür sind eng an die eingesetzte Clustersoftware gebunden.
Integration
Ein „klassisches“ SAP-System (AS ABAP) beinhaltet einige Single-Points-Of-Failure (SPOFs), die mehr oder minder einfach auf einem anderen Rechner nachgestartet werden können, wenn sie ausfallen:
Der SAP-Message-Server kann sehr einfach und schnell wieder hochgefahren werden. Während er nicht zur Verfügung steht, funktioniert die Kommunikation zwischen den Applikationsservern nicht, es gehen jedoch keine kritischen Daten verloren.
Die SAP-Datenbank muss mit Datenbank-Failover-Lösungen abgesichert werden.
Die SAP-Zentralinstanz (im klassischen Sinne) ist ein SPOF aufgrund des Enqueue-Services, den sie bereitstellt.
SPOFs im klassischen SAP-System
Der Enqueue-Server hält mit der Sperrtabelle kritische Daten im Hauptspeicher: alle Sperren, die derzeit von Benutzern gehalten werden. Fällt der Rechner aus, sind diese Daten verloren und können auch beim Neustart des Enqueue-Servers nicht wiederhergestellt werden. Alle Transaktionen, die Sperren gehalten hatten, müssen deshalb zurückgesetzt werden.
Um nicht die gesamte Zentralinstanz hochverfügbar machen zu müssen, empfiehlt sich der Einsatz des Standalone-Enqueue-Servers. Dieser ist zusammen mit dem Enqueue-Replikationsserver, der auf einer anderen Maschine gestartet wird, hochverfügbar. Ihr SAP-System hat keine Zentralinstanz im klassischen Sinn mehr (wie in der Grafik oben dargestellt).
Funktionsumfang
Im Fall des AS Java ist der Einsatz des Standalone-Enqueue-Servers standardmäßig konfiguriert. Auch im Falle des AS ABAP können Sie den Standalone-Enqueue-Server alleine einsetzen. In beiden Fällen können Sie das HA-Szenario mit dem Enqueue-Replikationsserver konfigurieren.
SAP-System (ABAP) mit hochverfügbarem Enqueue-Server
Die multithreaded Architektur des Standalone-Enqueue-Servers ermöglicht die parallele Verarbeitung von Enqueue-Requests und die Synchronisation der Sperrtabelle mit dem Replikationsserver.
Die I/O-Last, die bei einem herkömmlichen AS ABAP durch den Dispatcher seriell abgewickelt wird, wird hier auf mehrere Threads verteilt. Dies gewährleistet in den meisten Fällen einen höheren Durchsatz an Enqueue-Requests.
Einschränkungen
Falls Sie ein ABAP-System mit nur einer Instanz betreiben (klassisches ABAP-Zentralsystem) und Hochverfügbarkeit nicht unbedingt gewährleistet sein muss, empfiehlt sich der Einsatz des Standalone-Enqueue-Servers nicht. Die Workprozesse der Zentralinstanz können direkt auf die Enqueue-Funktionalität zugreifen.