Client-serveur – Une nouvelle façon d’exécuter la logique sur le serveur

En mode client-serveur, votre logique nécessite souvent des ressources hébergées sur le serveur. Pour exécuter du code sur le serveur, vous avez l’habitude d’écrire des méthodes de projet dédiées ou des fonctions du modèle de données ORDA.

Cela peut entraîner un grand nombre de méthodes de projet ou de fonctions du modèle de données ORDA qui ne sont pas toujours justifiées. 

Avec 4D 21 R3, certaines singletons peuvent désormais exécuter des fonctions sur le serveur. 

Poursuivez votre lecture pour découvrir comment améliorer l’organisation de votre code !

HDI_ServerKeyword_Singletons

Dans vos applications de bureau, certaines parties du code doivent être exécutées sur le serveur car elles lisent ou mettent à jour des données qui doivent être partagées par tous les clients 4D connectés. Par exemple, pour partager des données en mémoire entre tous les clients connectés, vous utilisez actuellement le stockage sur le serveur. 

Votre logique peut également nécessiter des ressources hébergées sur le serveur (par exemple, l’interrogation de données).

Pour exécuter du code sur le serveur, vous aviez l’habitude d’écrire :

• une méthode de projet avec la propriété Exécuter sur le serveur activée
• une commande Exécuter sur le serveur
• une fonction du modèle de données ORDA (qui s’exécute par défaut sur le serveur)

Désormais, certains singletons peuvent disposer de fonctions qui sont toujours exécutées sur le serveur.

Le mot-clé « server » pour les singletons partagés et de session

Les fonctions des singletons partagés et de session prennent désormais en charge le server .

Lorsqu’une fonction est déclarée avec ce mot-clé d’ server, elle est toujours exécutée sur le serveur, même si le singleton est instancié sur un 4D Client.

Exemple

Dans l’exemple ci-dessous, le singleton partagé Administration définit une server fonction qui exécute la commande Process activity(). 

Ce singleton est instancié sur un 4D Client, et la fonction est appelée à partir de là. Elle renvoie l’activité du serveur (processus + sessions).

Le singleton partagé Administration:

shared singleton Class constructor

// This function is executed on the server
server Function processActivity() : Object
return Process activity()

// This function is executed locally
Function localProcessActivity() : Object
return Process activity()

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

var $localActivity; $serverActivity : Object
var $administration : cs.Administration


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

// The Administration singleton is instantiated on the 4D Client
$administration:=cs.Administration.me

// Get the processes running on the 4D client
$localActivity:=$administration.localProcessActivity()

ASSERT($localActivity.sessions=Null)

// Get the processes + sessions running on 4D Server
$serverActivity:=$administration.processActivity()

ASSERT($serverActivity.sessions.length>=1)

Aller plus loin avec le singleton de session

Dans ce contexte, le singleton de session offre un avantage majeur. Un singleton de session dispose d’une instance partagée unique pour tous les processus au sein d’une session.

Dès lors qu’un singleton de session peut exécuter de la logique sur le serveur, il peut étendre efficacement les capacités de la commande Session .

Exemple

Si vous stockez vos utilisateurs dans une table Users et implémentez une authentification personnalisée, vous pouvez utiliser un singleton de session à cette fin.

Dans l’exemple ci-dessous, le singleton de session UserSession dispose d’une fonction checkUser() exécutée sur le serveur. L’ID utilisateur est stocké dans l’objet partagé de la session storage .

server Function checkUser($credentials : Object) : Boolean
	
var $user : cs.UsersEntity
var $result:=False
	
If ($credentials#Null)
	$user:=ds.Users.query("Email === :1"; $credentials.identifier).first()
		
	If (($user#Null) && (Verify password hash($credentials.password; $user.Password)))
		Use (Session.storage)
			Session.storage.userInfo:=New shared object("userId"; $user.ID)
		End use 
			
		$result:=True
	End if 
End if 
	
return $result

Pour fournir l’utilisateur actuel à tous les clients 4D, le singleton de session expose une propriété calculée user récupérée depuis le serveur.

session singleton Class constructor()

server Function get user() : cs.UsersEntity
	return ds.Users.get(Session.storage.userInfo.userId)

Exécutez le HDI joint pour découvrir des exemples concrets. L’étape suivante consiste à mieux organiser votre code en plaçant la logique pertinente dans la classe appropriée et… n’attendez pas pour commencer à travailler avec les sessions 4D !