Process Serveur

Voici la troisième note d'une série de notes techniques qui ajoute de nouvelles fonctionnalités à notre base exemple. Cette note technique montre comment démarrer, gérer et exécuter des process qui sont gérés sur un 4D Client, mais exécutés sur le 4D Server. Par un effet secondaire du mode de fonctionnement de 4D (et avec quelques Si dans le code), il est aussi possible de faire exécuter ces process sur un 4D Client ou un 4D monoposte si besoin.

Cette note utilise la même base exemple que la note « Formulaire de sortie modifiable par l'utilisateur » (référence 4D-200604-10-FR).

Je ne décrirai ici que la partie du code qui concerne les process, pour plus de détails sur les autres tables, formulaires et méthodes, merci de vous référer aux précédentes notes techniques.

Dans cet exemple de code, je vais montrer comment un process peut être lancé pour être exécuté sur le serveur (ou un client ou un 4D mono) de manière permanente. Cela signifie qu'une fois que le process est défini et que la base l'exécute, à intervalle fixé par l'utilisateur, il va chercher dans le dossier A_IMPORTER s'il y a des documents à importer, exécuter le code d'import, puis envoyer un email ou un message d'alerte comme spécifié. Le document est ensuite déplacé dans le dossier IMPORT_TERMINE et la boucle recommence.

Comme dans les précédentes notes techniques, trois utilisateurs sont définis dans cette base exemple : Designer, Administrator et Test User. Seul le Designer a un mot de passe (pour forcer l'affichage de la fenêtre de login et permettre le changement d'utilisateur) et ce mot de passe est : designer.

Dans cette base, il y a trois tables [Personnes], [Sociétés] et [xPreferences]. Les tables [Personnes] et [Sociétés] ne servent pas beaucoup dans cette note technique, elles font juste partie du développement de la base. Regardez les notes précédentes pour plus d'information sur leur utilisation.

Nous créons une nouvelle méthode, un nouveau formulaire et un nouveau process pour gérer les process serveur (et leurs préférences), de manière complètement séparée des préférences utilisateur. Ceci nous permet de contrôler les process serveur sans causer de problèmes lors de la mise à jour de préférences utilisateur.

Cet exemple utilise trois méthodes de gestion des préférences. L'une (xPreferences_Users) est appelée par le menu Edition et ouvre un formulaire qui permet l'édition des préférences utilisateurs. L'autre (xPreferences) gère toutes les données de préférences écrites ou lues dans la base. La séparation en deux méthodes n'était pas obligatoire, mais le code est beaucoup plus propre ainsi. La troisième méthode (xPreferences_Processes) est aussi appelée depuis le menu Edition et ouvre le formulaire « [xPreferences]Prefs_Processes » qui permet l'édition des préférences de process.

Comme ce process « serveur » est habituellement exécuté sur le serveur ou sur un seul client à la fois, toutes ses valeurs de préférences sont stockées, non sous le nom de l'utilisateur courant, mais sous le nom « Processes ». Il y a un seul enregistrement pour ces valeurs de préférence (pour cette action « People Import »), à la différence des enregistrements de préférences utilisateur, dont il existe un enregistrement par utilisateur (Designer, Administrator, Test User) qui peut se connecter à la base et par type de préférences utilisateur (Startup view = affichage au démarrage, Data Entry = valeurs par défaut).

Il y a juste quelques méthodes qui concernent spécifiquement cette note technique. La première (xFileNameHandler) est très semblable à l'exemple de code de la documentation 4D (pour les documents système). Elle est utilisée pour trouver le nom du fichier ou le chemin d'accès de l'application 4D ou de la structure en cours d'exécution. Mais la partie centrale de cette note est la méthode projet People_ImportProcess. C'est là, et dans le formulaire « [xPreferences]Pref_Processes » et sa méthode formulaire que tout se passe et c'est de cela dont cette note technique va parler, pour l'essentiel.

Ce formulaire est ouvert par la méthode xPreferences_processes. Il permet à l'utilisateur d'éditer les options disponibles pour le process « People Import » (import de personnes). Ces options sont :

• le lancement du process au démarrage ;
• le lancement du process sur le serveur ou sur le client (en client/serveur seulement, sinon la boîte à cocher est masquée) ;
• le nombre de minutes d'attente entre deux vérifications des documents à importer ;
• l'envoi d'un email à la fin de l'import, le destinataire, l'expéditeur, le serveur de messagerie à utiliser ;
• l'affichage d'un message d'alerte à la fin de l'import.

Il y a aussi un bouton de démarrage et d'interruption de l'import.

Si le process « People Import » est exécuté sur un client ou sur le serveur, toutes les variables de la fenêtre seront inactivées jusqu'à l'arrêt du process. Si le process est exécuté sur le serveur, tous les clients pourront l'interrompre. Si c'est sur un client, seul le client sur lequel il est exécuté pourra l'interrompre et tous les autres clients auront ce bouton inactivé. Dès que le process est lancé ou arrêté, un message est envoyé à tous les clients pour leur faire activer ou désactiver les variables concernées.

C'est la méthode du formulaire décrit dans le paragraphe précédent. Il ne s'y passe pas grand-chose, c'est juste le lieu où sont éditées les préférences de l'import de personnes. C'est très semblable au formulaire « [xPreferences]Pref_Users » qui a été présenté dans la précédente note technique. Le point essentiel à remarquer est l'utilisation de l'événement formulaire Sur appel extérieur.

Sur chargement▲

Sur appel extérieur▲

Sur libération▲

C'est l'essentiel du code pour cette note technique. Il aurait pu être remplacé par plusieurs méthodes, mais j'aime bien regrouper des éléments de code qui se correspondent dans un grand Au cas ou. C'est plus facile à lire pour moi qu'un grand nombre de méthodes séparées.

: (Nombre de paramètres=0)

Appelée sans paramètres, cette méthode va démarrer un nouveau process (« People Import ») qui utilise la méthode People_ImportProcess en lui passant le paramètre « NewProcess ».

Un seul process People Import est créé, et s'il est rappelé, un nouveau process ne sera lancé que si le premier est fini.

Le process est créé, soit sur le serveur, soit sur le poste utilisateur en monoposte, par la fonction Executer sur serveur. S'il tourne sur un client et que la variable cbPrefPeopleImportRunOnServer est à Faux, alors le process sera créé sur ce client. La variable cbPrefPeopleImportRunOnServer est une variable de préférence qui a été chargée avant le lancement de la méthode.

Le point à noter ici est que les fonctions Executer sur serveur et Nouveau process sont très semblables. En version monoposte, les deux fonctions ont la même action, comme il n'y a pas de serveur, le process est exécuté sur le poste utilisateur. En client-serveur, Executer sur serveur exécute le process sur le poste serveur. Sur le poste client ou en monoposte, Nouveau process l'exécute sur ce client ou ce poste.

: ($command= "RunProcess")

Ce process est lancé par le code ci-dessus et commence par lire les préférences de l'import des personnes, puis démarre une boucle qui vérifie la présence de nouveaux fichiers à importer, puis, s'il en existe, les importe, envoie les emails ou alertes requis, déplace les fichiers importés et recommence toute la boucle Tant que.

Les points à remarquer dans cette partie du code :

1) Ce code ne doit contenir aucune alerte ni dialogue ni aucune commande 4D qui ne puisse pas être exécutée sur le serveur. C'est très important d'y penser en écrivant vos propres process serveur ;

2) L'instruction suivante est utilisée à plusieurs endroits :

EXECUTER SUR CLIENT (sPrefPeopleImportClientMsgName ; "People_ImportProcess" ;"UpdateWindow")

Cette instruction dit au client, ET NON au serveur, d'exécuter la partie UpdateWindow de la méthode People_ImportProcess. Encore une fois, cela se passe sur le client, pas sur le serveur ;

3) Au début de la boucle Tant que, il y a une boucle Repeter. C'est dans cette boucle Repeter que la méthode est mise en attente pour le délai fixé par l'utilisateur dans le dialogue (15 minutes dans cet exemple) avant de commencer sa recherche d'un fichier à importer. Si nous utilisions la commande ENDORMIR PROCESS avec un délai de 15 minutes, le process ne pourrait pas savoir que l'utilisateur a demandé son interruption avant la fin de sa mise en sommeil. Au lieu de cela, nous calculons le nombre de secondes pour boucler (60*15 ou 60 fois le nombre de minutes de délai), entrons dans la boucle Repeter et faisons un ENDORMIR PROCESS pour une seconde. Après une seconde, si l'utilisateur n'a pas modifié la variable <>cbPrefPeopleImportOn sur ce client ou n'importe quel autre, nous retournons dans la boucle Repeter jusqu'à ce que le nombre de secondes prévu soit atteint. Cela fait, nous vérifions s'il y a un fichier à importer. Une fois la vérification faite, ainsi que l'import si besoin, nous recommençons la boucle Tant que jusqu'à ce que quelqu'un l'interrompe ;

4) Lorsque nous en venons à la section où l'import doit s'effectuer, nous devons calculer le chemin d'accès aux dossiers d'import, vérifier leur existence et, si besoin, les créer. Comme ce code doit pouvoir s'exécuter sur toute application 4D, nous devons vérifier si nous sommes sur un client ou non. Si l'exécution a lieu sur un client, la commande PROPRIETES PLATEFORME ne retournera que le nom de la structure 4D, et non son chemin d'accès complet ou son emplacement. Exécutée sur le serveur ou sur un 4D monoposte, la commande renvoie le chemin d'accès complet à la structure. C'est pourquoi, en cas d'exécution sur un client, nous utilisons l'emplacement de l'application client elle-même, pour un serveur ou un monoposte, nous utilisons l'emplacement du fichier de structure.

Ce sont les points principaux de cette partie du code ; toutes les autres lignes de codes sont commentées dans le source.

: ($command="UpdateWindow")

Lorsque la méthode RunProcess doit mettre à jour les clients, elle exécute cette section de code sur tous les clients à l'aide d'une seule commande EXECUTER SUR CLIENT. Chaque client en ligne, lorsqu'il est sollicité, effectue cette tâche par un APPELER PROCESS à sa méthode xPreferences_Processes qui s'exécute localement. Si la fenêtre de xPreferences_Processes n'est pas ouverte sur ce client, il ne se passe rien. Si elle est ouverte, la commande APPELER PROCESS déclenche le Sur appel extérieur de la méthode formulaire, lequel recharge les valeurs des préférences et met à jour la fenêtre, comme requis.

:($command="ShowAlert")

Une fois de plus, comme le serveur ne peut pas ouvrir de fenêtres ou afficher des alertes, lorsque nous voulons afficher une alerte sur tous les clients depuis une méthode exécutée sur le serveur, nous appelons cette méthode avec un EXECUTER SUR CLIENT. Le client affiche alors un simple message d'alerte. Pour une exécution en monoposte, lors de l'appel de cette méthode, le code de RunProcess reste en attente d'un clic utilisateur sur le bouton de l'alerte. Vous pouvez avoir besoin d'afficher cette alerte dans un autre process dans une base monoutilisateur packagée.

:($command="UserInterface")

Cette partie est exécutée uniquement sur le client ou le poste monoutilisateur et sert uniquement à fixer les options d'interface utilisateur du formulaire, s'il est affiché. Cela servira aussi à masquer la boîte à cocher « Exécuter sur le serveur » pour une exécution en monoposte.

:($command="OnStartUp")

Cette partie est appelée uniquement depuis la méthode base Sur ouverture ou Sur démarrage serveur et si la variable cbPrefPeopleImportRunAtStartup a été initialisée et, dans ce cas, tente de lancer un nouveau process « People Import ». Son comportement est légèrement différent selon que le code s'exécute sur un client ou sur un serveur/monoposte.

Quelques remarques sur de subtiles différences dans la dénomination et le fonctionnement des commandes 4D qui suivent.


Nouveau process

Fonctionne à l'identique sur un client et en monoposte. Démarre un nouveau process sur la machine qui l'exécute.


Exécuter sur serveur

Lance un nouveau process sur le serveur lorsqu'elle est exécutée sur un client. Lorsqu'elle est exécutée sur un monoposte, elle démarre un nouveau process sur ce poste de la même manière que la commande Nouveau process.


EXECUTER SUR CLIENT

Lance une méthode, et non un process, sur chaque client prévu pour gérer la commande EXECUTER SUR CLIENT dans la fenêtre des préférences 4D ou par l'utilisation de la commande INSCRIRE CLIENT. Veillez à ce que la méthode appelée ne consomme pas trop de temps ou de mémoire ; cela peut vous poser des problèmes. Ne fait rien en monoposte : ni erreur, ni fonctionnement, rien.


INSCRIRE CLIENT / DESINSCRIRE CLIENT

La commande INSCRIRE CLIENT fonctionne comme les préférences 4D sauf que vous pouvez donner aux clients le nom que vous voulez, ce n'est pas le système qui l'attribue. Ces commandes vous permettent d'activer / désactiver la fonction EXECUTER SUR CLIENT.
Cette note technique les utilise avec la valeur « AdminClient », mais on pourrait leur passer n'importe quelle valeur.


LIRE VARIABLE PROCESS

Lit les variables passées par le serveur, mais ne peut pas recevoir une variable locale comme variable source.


VARIABLE VERS VARIABLE

Envoie les variables passées au serveur, mais ne peut pas envoyer une variable locale comme variable destination.


ECRIRE VARIABLE PROCESS

Envoie certaines variables au serveur. Vous ne pouvez pas passer de tableaux, de pointeurs ou de variables locales.
VARIABLE VERS VARIABLE est l'opposé de LIRE VARIABLE PROCESS.
ECRIRE VARIABLE PROCESS n'est PAS l'opposé de LIRE VARIABLE PROCESS.

Avec cette note technique, nous avons traité plusieurs points :

1) Échanger des données entre les process Clients-Serveur pour mettre à jour des variables et des fenêtres ;

2) Permettre l'exécution de process sur le serveur, le client ou en monoposte avec le même code ;

3) Montrer comment certains outils simples d'interface utilisateur peuvent servir à limiter l'édition de variables ou de process ;

4) Étendre les fonctionnalités de la table xPreferences (introduites dans la précédente note technique). Nous pouvons maintenant fixer des préférences pour un process indépendamment de la personne qui l'exécute et du contexte ;

5) Compléter les notes techniques précédentes « Formulaire de sortie modifiable par l'utilisateur et « Préférences utilisateur ».

Tous les éléments mentionnés dans cette note technique ont de nombreux commentaires associés aux formulaires et aux méthodes.

Télécharger la base exemple.