Vergessen Sie serverseitige Wrapper, nutzen Sie stattdessen 4D Sessions auf dem Client

April 30, 2026 3 Lesezeit

Verbessern Sie die Benutzererfahrung Ihrer Endnutzer in Client-Server-Anwendungen, indem Sie die Vorteile von 4D-Sitzungen nutzen. Eine 4D-Sitzung wird nativ und automatisch erstellt, sobald ein Benutzer seine Desktop-Client-Anwendung öffnet, und bietet zahlreiche Vorteile.

Der wichtigste Vorteil? Der Datenzugriff lässt sich ganz einfach je nach aktuellem Benutzereinschränken.

Es sind keine Konfigurationen erforderlich, um mit 4D-Sitzungen zu arbeiten, und es fallen keine zusätzlichen Lizenzkosten an. Mit 4D 21 R3 wurde die Nutzung von 4D-Sitzungen im Client-Server-Modus weiter verbessert.

Lesen Sie weiter, um diese Verbesserungen zu entdecken!

HDI_Session_4DClient

Remote-Benutzersitzungen

Wenn sich ein 4D-Client mit einer auf einem 4D-Server bereitgestellten Anwendung verbindet, wird auf dem Server eine Remote-Benutzersitzung erstellt. Sitzungen eignen sich ideal zum Speichern kontextbezogener oder benutzerspezifischer Informationen im Arbeitsspeicher, wie z. B. Namen, Firmen oder der aktuelle Fortschritt eines Benutzers in einem Workflow.

Auf dem Server existieren mehrere Sitzungen nebeneinander: Jeder Benutzer verfügt über eine eigene dedizierte Sitzung.

Darüber hinaus führt 4D 21 einen vollständigen Satz von ORDA-Ereignissen ein. Diese Ereignisse werden immer auf dem Server ausgelöst. Wenn ein Ereignis Zugriff auf den Benutzerkontext benötigt, ist die 4D-Sitzung die perfekte Lösung, insbesondere um den Datenzugriff basierend auf dem aktuellen Benutzer einzuschränken.

Neuerungen beim Befehl „Session“

Wenn Sie in Ihrem Code den Befehl „ Session “ aufrufen, werden die Informationen zur Remote-Benutzersitzung als Objekt zurückgegeben.

Vor 4D 21 R3 musste dies auf der Serverseite erfolgen (innerhalb einer dedizierten Projektmethode oder einer ORDA-Klassenfunktion), da der Aufruf des Befehls „Session“ auf dem 4D-Client den Wert Null zurückgab.

Mit 4D 21 R3 kann der Befehl „Session“ nun auch direkt vom 4D-Client aus aufgerufen werden.

Dies verbessert sowohl die Code-Organisation als auch die Lesbarkeit. Während der Entwicklung müssen Sie sich keine Gedanken mehr über Fragen wie „Wo wird mein Code ausgeführt?“ machen.

Beispiel

Code, der auf dem 4D-Client ausgeführt wird:

var $session : 4D.Session

ASSERT(Application type()=4D Remote mode)

$session:=Session

Dies ist das Objekt „ $session “:

{
	"storage": {},
	"userName": "Designer",
	"id": "607BC064662C4563B3521E162E8DFB5A",
	"info": {
		"ID": "607BC064662C4563B3521E162E8DFB5A",
		"creationDateTime": "2026-03-12T09:50:45Z",
		"userName": "Designer",
		"state": "active",
		"type": "remote",
		"IPAddress": "localhost",
		"systemUserName": "Marie-Sophie",
		"hostType": "mac",
		"machineName": "Mac mini 1743",
		"persistentID": "97212B60A6294A24AC3BF829E2040888"
	}
}

Die info Eigenschaft ist spezifisch für den Rechner des Benutzers.

das gemeinsam genutzte Speicherobjekt

Da Sie nicht damit rechnen müssen, dass der Befehl „Session“ einen Null-Wert zurückgibt, vereinfacht dies in den meisten Fällen die Programmierung, da Sie keine serverseitige Routine mehr schreiben müssen.

Die einzige Ausnahme bildetdas gemeinsam genutzte Speicherobjekt.

Der Aufruf des Befehls „Session“ vom 4D-Client aus stellt ein gemeinsam genutztes storage Objekt, das lokal auf dem 4D-Client vorhanden ist. Es handelt sich nicht um dieselbe Referenz wie das gemeinsam genutzte Speicherobjekt der Remote-Benutzersitzung auf dem 4D-Server.

Wenn Sie Sitzungsinformationen speichern müssen, die nur für serverseitige Routinen relevant sind (wie die Einschränkung des Datenzugriffs basierend auf dem aktuellen Benutzer ), müssen Sie diesen Code weiterhin auf dem Server ausführen, um das entsprechende Session -Objekt anzusprechen .storage

Nutzen Sie 4D-Sitzungen noch heute, um kontextbezogene oder benutzerspezifische Informationen einfach im Speicher zu zentralisieren und die oben beschriebenen Vorteile voll auszuschöpfen.

Discuss