SOA-Service (Socket) – Benutzerdaten über mehrere Anfragen verwenden

Wird zum SOA-Service der Betriebsart Socket auf dem eingestellten Port eine Verbindung aufgebaut, bleiben die ermittelten Daten maximal bis zum Verlassen der Prozedur nach der Abarbeitung der Anfrage erhalten. In diesem Artikel erläuterte ich, wie Daten über mehrere Anfragen hinweg bereitgehalten werden können.

Connection sharing

Die Datenbankverbindung der Anfrage kann erhalten bleiben, wenn in der Konfigurationsdatei des SOA-Tasks der Eintrag c16_connection_shared = Y gesetzt ist. Dies ist im produktiven Einsatz sinnvoll um die Anzahl der Verbindungen zu verringern und die Verarbeitungsgeschwindigkeit zu erhöhen. Die höhere Geschwindigkeit resultiert daraus, dass sich nicht für jede Anfrage ein neuer Benutzer in der Datenbank anmelden muss, sondern auf bestehende Benutzer von vorherigen Anfragen (auch anderer Benutzer) zugegriffen werden kann. Die Benutzer-ID wird in den Pool der verfügbaren IDs gelegt. In der Entwicklungs- und Testphase sollte der Eintrag auf N gesetzt werden, da mit dem Abmelden des Benutzers auch der Inhalt des Prozedurcaches geleert wird.

Vergabe der Benutzer-IDs im SOA-Service bei aktiviertem connection sharing

Zu beachten!

Datensatzsperren werden pro Benutzer-ID abgelegt. Ist “connection sharing” aktiv, ist der gesperrte Datensatz bei der nächsten Anfrage unter Umständen einem anderen Client zugeordnet. Ist hingegen “connection sharing” ausgeschaltet, wird der Datensatz beim Verlassen der Prozedur entsperrt. Dies ist in beiden Fällen nicht das gewünschte Ziel.

Bei Selektionen muss für die Mehrbenutzerfähigkeit eine Eindeutigkeit des Selektionsnamens sichergestellt werden. Hier bietet sich beim Windows-Client die Benutzer-ID an. Da hierbei jedoch für den SOA-Service das gleiche Problem wie bei den Datensatzsperren besteht, sollte hier stattdessen die Session-ID als Basis verwendet werden.

Um Probleme in diesen Bereichen feststellen zu können, sollten Tests mit mehreren Benutzern gleichzeitig erfolgen. Dabei sollte der Eintrag c16_connection_shared auch auf den Wert gesetzt werden, den er im produktiven Einsatz haben wird.

Sitzungen

Um die Daten eines Benutzers nun über mehrere Anfragen beizubehalten muss auf so genannte Sitzungen zugegriffen werden. Eine Sitzung wird mit dem Befehl SvcSessionControl(_SvcSessionCreate) erzeugt. Der Befehl gibt die Session-ID zurück. Sie ist auch im Task-Objekt in der Eigenschaft spSvcSessionID enthalten. Die erzeugte Session muss nun bei allen Links in der URI angegeben, oder als Cookie gesetzt werden. Am Ende der laufenden Prozedur werden die vorhandenen globalen Datenbereiche und Deskriptoren unter der Session-ID automatisch gespeichert. Hier ist zu beachten, dass die Deskriptoren von Datensatzpuffern und Oberflächenobjekten gelöscht und nicht gesichert werden.

Mit SvcSessionControl(_SvcSessionLoad, tSessionID) wird die Session wieder aktiviert. Anschließend kann auf die gespeicherten Daten zugegriffen werden. Auch hier werden nach dem Ende der Prozedur die aktuellen Daten wieder gespeichert.

Der Befehl SvcSessionControl(_SvcSessionDelete) löscht die aktive Session der Prozedur. Diese muss zuvor in der gleichen Anfrage mit dem Parameter _SvcSessionCreate angelegt, oder mit _SvcSessionLoad geladen worden sein. Anschließend kann eine neue Sitzung angelegt oder geladen werden.

Pro Prozedur kann nur eine Session zugeordnet werden. Ein weiterer Aufruf von den Parametern _SvcSessionCreate und _SvcSessionLoad führt zu dem Fehler _ErrSvcSessionState.

Beispiele

In der CodeLibrary wird die Verwendung der Sitzungen in den Beispielen “HTTP” und “MobileApp” gezeigt.