Gestion Client/Serveur

Les applications 4D Desktop peuvent être utilisées dans une configuration Client/Serveur, en tant qu'applications client/serveur fusionnées ou en tant que projets distants.

• Les applications client/serveur fusionnées sont générées par le Générateur d'application. Elles sont utilisées pour les déploiements d'applications.

• Les projets distants sont des fichiers .4DProject ouverts par 4D Server et accessibles avec 4D en mode distant. Le serveur envoie une version .4dz du projet (format compressé) au 4D distant, donc les fichiers de structure sont en lecture seule. Cette configuration est généralement utilisée pour les tests d'application.

La connexion à un projet distant à partir de la même machine que 4D Server permet de modifier les fichiers du projet. Cette fonctionnalité spécifique permet de développer une application client/serveur dans le même contexte que le contexte de déploiement.

Ouvrir une application client/serveur fusionnée

Une application client/serveur fusionnée est personnalisée et son démarrage est simplifié :

• Pour lancer la partie serveur, l’utilisateur double-clique simplement sur l’application serveur. Il n’est pas nécessaire de sélectionner le fichier projet.
• Pour lancer la partie cliente, l’utilisateur double-clique simplement sur l’application cliente, qui se connecte directement à l’application serveur.

Ces principes sont détaillés dans la page du Générateur d'application.

Ouvrir un projet distant

La première fois que vous vous connectez à un projet 4D Server via un 4D distant, vous utiliserez généralement la boîte de dialogue de connexion standard. A chaque fois que 4D effectue une action Enregistrer tout depuis l'environnement de développement (explicitement depuis le menu Fichier ou implicitement en passant en mode application par exemple), 4D Server recharge de manière synchrone les fichiers du projet.

Pour vous connecter à distance à un projet 4D Server :

1. Effectuez l'une des opérations suivantes :
   • Sélectionnez Se connecter à 4D Server dans la boîte de dialogue de l'Assistant de bienvenue
   • Sélectionnez Ouvrir > Projet distant... à partir du menu Fichier ou du bouton Ouvrir de la barre d'outils.

La boîte de dialogue de connexion à 4D Server apparaît. Cette boîte de dialogue comporte trois onglets : Récent, Disponible et Personnalisé.

Si 4D Server est connecté au même sous-réseau que le 4D distant, sélectionnez Disponible. 4D Server inclut un système de diffusion intégré qui, par défaut, publie le nom des projets 4D Server disponibles sur le réseau. La liste est triée par ordre d'apparition et est mise à jour dynamiquement.

Pour vous connecter à un serveur de la liste, double-cliquez sur son nom ou sélectionnez-le et cliquez sur le bouton OK.

Si le projet publié n'est pas affiché dans la liste Disponible, sélectionnez Personnalisé. La page Personnalisé vous permet de vous connecter à un serveur publié sur le réseau en utilisant son adresse réseau et en lui attribuant un nom personnalisé.

• Nom du projet : définit le nom local du projet 4D Server. Ce nom sera utilisé dans la page Récent pour faire référence au projet.
• Adresse réseau : L'adresse IP de la machine sur laquelle le 4D Server a été lancé.
  • Si deux serveurs sont exécutés simultanément sur la même machine, l'adresse IP doit être suivie de deux points et d'un numéro de port, par exemple : 192.168.92.104:19814.
  • Par défaut, le port de publication d'un 4D Server est 19813. Ce numéro peut être modifié dans les paramètres du projet.

L'option Activer le mode développement ouvre la connexion à distance dans un mode lecture/écriture spécial et nécessite d'accéder au dossier du projet depuis le 4D distant (option de compatibilité).

Une fois que cette page attribue un serveur, cliquez sur le bouton OK pour vous connecter au serveur.

Une fois la connexion au serveur établie, le projet distant sera répertorié dans l'onglet Récent.

Mettre à jour des fichiers de projet sur le serveur

4D Server crée et envoie automatiquement aux machines distantes une version .4dz du fichier de projet .4DProject (non compressé) en mode interprété.

• Une version .4dz mise à jour du projet est automatiquement produite lorsque cela est nécessaire, c'est-à-dire lorsque le projet a été modifié et rechargé par 4D Server. Le projet est rechargé :
  • automatiquement, lorsque la fenêtre de l'application 4D Server arrive à l'avant de l'OS ou lorsque l'application 4D sur la même machine enregistre une modification (voir ci-dessous).
  • lorsque la commande RELOAD PROJECT est exécutée. L'appel de cette commande est nécessaire lorsque, par exemple, vous avez extrait une nouvelle version du projet depuis la plateforme de contrôle de version.

Mettre à jour des fichiers de projet sur les machines distantes

Lorsqu'une version .4dz mise à jour du projet a été produite sur 4D Server, les machines 4D distantes connectées doivent se déconnecter et se reconnecter à 4D Server afin de bénéficier de la version mise à jour.

Utiliser 4D et 4D Server sur la même machine

Lorsque 4D se connecte à un 4D Server sur la même machine, l'application se comporte comme 4D en mode monoposte et l'environnement de développement permet d'éditer les fichiers du projet. Cette fonctionnalité vous permet de développer une application client/serveur dans le même contexte que le contexte de déploiement.

Lorsque 4D se connecte à un 4D Server sur la même machine, le mode développement est automatiquement activé, quel que soit l'état de l'option Activer le mode développement.

A chaque fois que 4D effectue une action Enregistrer tout depuis l'environnement de développement (explicitement depuis le menu Fichier ou implicitement en passant en mode application par exemple), 4D Server recharge de manière synchrone les fichiers du projet. 4D attend que 4D Server termine le rechargement des fichiers du projet avant de continuer.

Veillez cependant aux différences de comportement suivantes, comparées à l'architecture projet standard :

• le dossier userPreferences.{username} utilisé par 4D n'est pas le même que celui utilisé par 4D Server dans le dossier projet. Au lieu de cela, il s'agit d'un dossier dédié, nommé "userPreferences", stocké dans le dossier système du projet (c'est-à-dire au même emplacement que lors de l'ouverture d'un projet .4dz).
• le dossier utilisé par 4D pour les données dérivées n'est pas le dossier "DerivedData" du dossier projet. Il s'agit plutôt d'un dossier dédié nommé "DerivedDataRemote" situé dans le dossier système du projet.
• le fichier catalog.4DCatalog n'est pas édité par 4D mais par 4D Server. Les informations du catalogue sont synchronisées à l'aide des requêtes client/serveur
• le fichier directory.json n'est pas édité par 4D mais par 4D Server. Les informations du répertoire sont synchronisées à l'aide des requêtes client/serveur
• 4D utilise ses propres composants internes et plug-ins au lieu de ceux de 4D Server.

Il n'est pas recommandé d'installer des plug-ins ou des composants au niveau de l'application 4D ou 4D Server.

Sessions utilisateur distant

Sur le serveur, la commande Session renvoie un objet session décrivant la session utilisateur courante. Cet objet est géré via les fonctions et les propriétés de la classe Session.

Articles de blog sur le sujet

Objet session distante 4D avec connexion Client/Serveur et procédure stockée.

Utilisation

The session object allows you to handle information and privileges for the remote user session.

Vous pouvez partager des données entre tous les processus de la session utilisateur en utilisant l'objet partagé session.storage. Par exemple, vous pouvez lancer une procédure d'authentification et de vérification de l'utilisateur lorsqu'un client se connecte au serveur, impliquant la saisie d'un code envoyé par e-mail ou SMS dans l'application. Ensuite, vous ajoutez les informations de l'utilisateur au storage de session, ce qui permet au serveur d'identifier l'utilisateur. De cette façon, le serveur 4D peut accéder aux informations de l'utilisateur pour tous les process clients, permettant l'écriture de code personnalisé en fonction du rôle de l'utilisateur.

You can also assign privileges to a remote user session to control access when the session comes from Qodly pages running in web areas.

Disponibilité

L'objet session de l'utilisateur distant est disponible depuis :

• Les méthodes projet qui ont l'attribut Exécuter sur serveur (elles sont exécutées dans le process jumeau du process client),
• Les Triggers,
• Les fonctions du modèle de données ORDA (sauf celles déclarées avec le mot-clé local,
• Les méthodes base On Server Open Connection et On Server Shutdown Connection.

info

Toutes les procédures stockées sur le serveur partagent la même session utilisateur virtuelle. Pour plus d'informations, consultez cette page sur doc.4d.com.

Sharing the session with Qodly pages in Web areas

Remote client sessions can be used to handle Client/Server applications where Qodly pages are used for the interface, running on remote machines. With this configuration, your applications have modern CSS-based web interfaces but still benefit from the power and simplicity of integrated client/server development. In such applications, Qodly pages are executed within standard 4D Web areas.

To manage this configuration, you need to use remote client sessions. Actually, requests coming from both the remote 4D application and its Qodly pages loaded in Web areas need to work inside a single user session. You just have to share the same session between the remote client and its web pages so that you can have the same session storage and client license, whatever the request origin.

Note that privileges should be set in the session before executing a web request from a Web area, so that the user automatically gets their privileges for web access (see example). Keep in mind that privileges only apply to requests coming from the web, not to the 4D code executed in a standard remote session.

Shared sessions are handled through OTP tokens. After you created an OTP token on the server for the user session, you add the token (through the $4DSID parameter value) to web requests sent from web areas containing Qodly pages so that the user session on the server is identified and shared. On the web server side, if a web request contains an OTP id in the $4DSID parameter, the session corresponding to this OTP token is used.

Related blog post

Share your 4D remote client session with web accesses

Exemple

var $otp : Text

// Some privileges are put in the remote user session on the server for a further web access
ds.resetPrivileges("basic")

// An OTP is created on the server for this remote client session
$otp:=ds.getOTP()


// The user has already the required privileges for a web access
// and the same session is shared between this remote user and the web Qodly app
WA OPEN URL(*; "Welcome"; "http://127.0.0.1/$lib/renderer/?w=People&$4DSID="+$otp)

resetPrivileges() function in the Datastore class:

// This function is run on the server
// and puts some privileges in the session for a further web access

Function resetPrivileges($priv : Text) 
	
	Session.clearPrivileges()
	Session.setPrivileges($priv)

getOTP() function in the Datastore class:

// This function is run on the server 
// and generates an OTP able to retrieve this remote user session 

Function getOTP(): Text 
	
	return Session.createOTP()