Amélioration de l’utilisation des licences client 4D avec Qodly Studio for 4D

Ceux d’entre vous qui ont commencé à utiliser Qodly Studio for 4D savent déjà à quel point ce nouvel outil est puissant pour développer des applications web professionnelles. Si vous ne l’avez pas encore fait, vous trouverez ici plus d’informations sur la façon de commencer.

Les applications réalisées avec Qodly Studio for 4D s’appuient sur les API REST. 4D 20 R5 est livré avec une nouvelle fonctionnalité très intéressante : Le mode « Force Login ».

Avec ce mode, une licence 4D Client n’est consommée que lorsque les utilisateurs se connectent avec succès et commencent à travailler avec les données et la logique de votre application.

Poursuivez votre lecture pour en savoir plus ! Et n’oubliez pas de télécharger notre démo pour la voir à l’œuvre !

Démo Quitter la session

Qu’est-ce que le mode de connexion forcée ?

Les formulaires web Qodly ne sont pas en HTML. En effet, Qodly Studio for 4D décrit votre formulaire comme un fichier JSON, rendu ensuite dans le navigateur web de l’utilisateur final comme du HTML.

Pour qu’un formulaire Qodly soit rendu dans le navigateur web de l’utilisateur final, une requête REST est déclenchée à partir du navigateur pour télécharger le JSON du formulaire à partir du serveur.

D’autres actions de l’utilisateur final sur le formulaire déclencheront également des requêtes REST pour traiter les données et appeler les fonctions des classes du modèle de données ORDA sur le serveur.

Avant 4D 20 R5, comme pour toutes les autres requêtes REST, le serveur crée et maintient une session web pour héberger le stockage de la session et les privilèges de la session, et une licence 4D Client est consommée en même temps.

Par conséquent, si vous mettez en œuvre un formulaire d’authentification simple (login + mot de passe) avec Qodly Studio for 4D, dès que l’utilisateur final accède à ce formulaire, une licence 4D Client est consommée avant même que le processus d’authentification n’ait commencé.

La licence client 4D consommée n’est libérée que lorsque la session web est fermée après un délai d’inactivité d’au moins une heure (ou un redémarrage du serveur). Cela peut conduire à un manque de licences client 4D disponibles pour permettre aux utilisateurs de travailler avec votre application.

Nous sommes conscients que ce comportement pourrait être amélioré, voici pourquoi :

Avec 4D 20 R5, vous pouvez utiliser le nouveau mode « Force login » lorsque vous travaillez avec les API REST.

Ce mode bénéficie grandement à Qodly Studio pour les applications 4D car il améliore ce processus. Il vous aide à contrôler la consommation des licences client 4D, et vous pouvez maintenant libérer une licence client 4D lorsque l’utilisateur a fini d’utiliser l’application.

En résumé

Avec le mode Force Login, les licences ne sont consommées que lorsque les utilisateurs commencent à travailler avec les données et la logique de votre serveur REST. Cela signifie que :

• Réduction de la consommation de licences : Les formulaires de connexion ne consomment plus de licences.
• Amélioration de l’expérience utilisateur : Les utilisateurs peuvent tenter de se connecter sans que cela ait un impact sur les licences disponibles.
• Une meilleure gestion des ressources : La licence est libérée dès qu’un utilisateur quitte l’application.

Libérer une licence 4D Client à tout moment

La session peut être quittée en déclenchant simplement l’action standard Logout, et une licence 4D Client peut être libérée.

Il s’agit d’une amélioration significative, alors plongeons dans les détails pour apprendre comment vous pouvez bénéficier de cette fonctionnalité.

Comment activer le mode connexion forcée

L’activation du mode connexion forcée est simple. Il suffit de se rendre dans la section Rôles et privilèges et de l’activer.

Le fichier roles.json de votre projet est alors mis à jour en conséquence.

{
"permissions" : {
"allowed" : [
]
},
"privileges" : [
],
"roles" : [
],
"forceLogin" : true
}

Analyse détaillée du comportement

Une fois ce mode activé :

1. Les requêtes REST descriptives(c’est-à-dire les requêtes telles que rest/$catalog ou rest/$getWebForm pour rendre un formulaire web) ne consomment pas de licence.
2. Les autres requêtes REST(par exemple, les requêtes manipulant des données ou appelant des fonctions de classes de modèle de données ORDA) sont rejetées jusqu’à ce que l’authentification soit réussie.
3. Vous devez implémenter une fonction dont le nom doit être authentify() dans la classe datastore. Cette fonction gère l’authentification. Il s’agit de la seule requête REST descriptive acceptée sans authentification réussie.

Une fois l’authentification réussie, toutes les demandes REST sont acceptées et une licence client 4D est consommée.

Une authentification réussie signifie l’appel de la fonction Session.setPrivileges().

Voici la chronologie de ce processus :

Exemple : Application pour les vendeurs

Cet exemple présente une application que les vendeurs utilisent pour travailler avec les dossiers de leurs clients.

L’utilisateur final rend un formulaire web avec une source de données de type sélection d’entité (classe de données Clients) avec la valeur initiale All.

Cette erreur est reçue parce qu’aucune authentification n’a encore été effectuée avec succès :

Cependant, l’utilisateur final peut rendre ce formulaire web simple qui ne traite pas de données et n’appelle aucune fonction lorsqu’il est chargé. Aucune licence 4D Client n’est consommée pour le moment.

Lorsque l’utilisateur final clique sur le bouton Go, la fonction authentify() est appelée. Elle a été implémentée dans la classe datastore.

exposed Function authentify($credentials : Object) : Text
	
var $salesPersons : cs.SalesPersonsSelection
var $sp : cs.SalesPersonsEntity
	
$salesPersons:=ds.SalesPersons.query("identifier = :1"; $credentials.identifier)
$sp:=$salesPersons.first()
	
If ($sp#Null)
	If (Verify password hash($credentials.password; $sp.password))
		Session.clearPrivileges()
		Session.setPrivileges("")
		return "Authentication successful"
	Else 
		return "Wrong password"
	End if 
Else 
	return "Wrong user"
End if 

Cet appel est accepté.

Si l’authentification échoue, la fonction Session.setPrivileges() n’est pas appelée. Ainsi, aucune licence n’est consommée et aucune demande REST descriptive n’est rejetée.

Si l’authentification est réussie, la fonction Session.setPrivileges() est appelée. Ainsi, une licence client 4D est consommée, et toute demande REST est désormais acceptée. Vous pouvez alors commencer à travailler efficacement avec vos données.

Remarque : dans cet exemple, une chaîne vide est transmise à la fonction Session. Use the setPrivileges() pour s’authentifier en tant qu’invité. Bien entendu, les privilèges correspondant à l’authentification des utilisateurs peuvent être définis.

En outre, vous pouvez offrir à vos utilisateurs finaux une fonction de déconnexion grâce à l’action standard de déconnexion mentionnée ci-dessus. La session sera vidée de ses privilèges, et l’utilisateur final se retrouvera dans l’état « non authentifié » : seules les requêtes REST descriptives sont acceptées, et il doit s’authentifier à nouveau pour travailler avec les données.

Conclusion

Avec le mode Force Login dans 4D 20 R5, vous pouvez optimiser la consommation de licences client 4D dans vos applications web Qodly Studio for 4D. Cela améliore l’expérience de l’utilisateur et la gestion des ressources du serveur. Laissez-nous savoir ce que vous pensez de cette fonctionnalité sur les Forums 4D !