Oubliez les wrappers côté serveur, utilisez 4D Sessions depuis le client

avril 30, 2026 4 min de lecture

Améliorez l’expérience de vos utilisateurs finaux dans les applications client-serveur en tirant parti des sessions 4D. Natives et créées automatiquement dès qu’un utilisateur ouvre son application client de bureau, les sessions 4D offrent de nombreux avantages.

Le principal ? L’accès aux données peut être facilement restreint en fonction de l’utilisateur actuel.

Aucune configuration n’est nécessaire pour commencer à utiliser les sessions 4D et cela n’entraîne aucun coût de licence supplémentaire. Avec 4D 21 R3, l’utilisation des sessions 4D en mode client-serveur a été encore améliorée.

Poursuivez votre lecture pour découvrir ces améliorations !

HDI_Session_4DClient

Sessions utilisateur à distance

Lorsqu’un client 4D se connecte à une application déployée sur un serveur 4D, une session utilisateur à distance est créée sur le serveur. Les sessions sont idéales pour stocker en mémoire des informations contextuelles ou spécifiques à l’utilisateur, telles que des noms, des sociétés ou la progression actuelle d’un utilisateur dans un workflow.

Plusieurs sessions coexistent sur le serveur : chaque utilisateur dispose de sa propre session dédiée.

De plus, 4D 21 introduit un ensemble complet d’événements ORDA. Ces événements sont toujours déclenchés sur le serveur. Lorsqu’un événement a besoin d’accéder au contexte utilisateur, la session 4D est la solution idéale, notamment pour restreindre l’accès aux données en fonction de l’utilisateur actuel.

Nouveautés de la commande Session

Dans votre code, l’appel de la commande ` Session ` renvoie les informations de la session utilisateur distante sous forme d’objet.

Avant 4D 21 R3, cela devait être effectué côté serveur (au sein d’une méthode de projet dédiée ou d’une fonction de classe ORDA) car l’appel de la commande Session sur le client 4D renvoyait Null.

Avec 4D 21 R3, la commande Session peut désormais être appelée directement depuis le client 4D.

Cela améliore à la fois l’organisation et la lisibilité du code. Lors du développement, vous n’avez plus à vous poser de questions telles que « Où mon code va-t-il s’exécuter ? ».

Exemple

Code s’exécutant sur le client 4D :

var $session : 4D.Session

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

$session:=Session

Voici l’objet ` $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"
	}
}

La info propriété est spécifique à la machine de l’utilisateur.

l’objet partagé de stockage

Comme vous n’avez pas besoin d’anticiper une valeur Null renvoyée par la commande Session, cela simplifie le codage dans la plupart des cas, car vous n’avez plus besoin d’écrire une routine spécifique côté serveur.

La seule exception concernel’objet de stockage partagé.

L’appel de la commande Session depuis le client 4D fournit un storage local au client 4D. Il ne s’agit pas de la même référence que l’objet de stockage partagé de la session utilisateur distante sur le serveur 4D.

Si vous devez stocker des informations de session qui ne concernent que les routines côté serveur (comme la restriction de l’accès aux données en fonction de l’utilisateur actuel ), vous devez tout de même exécuter ce code sur le serveur pour cibler l’objet partagé Session approprié .storage.

Commencez dès aujourd’hui à utiliser les sessions 4D pour centraliser facilement en mémoire les informations contextuelles ou spécifiques à l’utilisateur et tirer pleinement parti des avantages décrits ci-dessus.

Discuss