Génération d'applications C/S : Clients, Plug-ins, Licences

4D 2004 propose un nouveau générateur d'applications Client/Serveur personnalisées, multiplateformes, avec possibilité de mise à jour automatique des parties clientes. Cette génération peut être effectuée soit via un dialogue accessible depuis le mode structure soit via un projet utilisant des clés XML et proposant beaucoup plus d'options. L'objectif de cette note technique est de vous expliquer certains mécanismes mis en jeu par ce nouveau générateur d'applications Client/Serveur et de vous proposer un ensemble de conseils et d'astuces techniques.

Il est vivement recommandé de consulter la documentation de 4D relative à la génération d'applications ainsi que la note technique 4D-200411-31-FR « Mise à jour automatique du 4D Client (4D 2004) » réalisée par Jonathan LE.

Le troisième onglet « Client/Serveur » du dialogue de génération d'applications vous permet, entre autres, de choisir le 4D Client Mac et le 4D Client Windows à utiliser pour générer les parties clientes. Lorsque vous activez le paramètre « Dossier 4D Client Win » vous devez sélectionner le chemin d'accès du dossier contenant l'application 4D Client windows. En revanche, pour inclure le paramètre « Dossier 4D Client Mac », il vous faudra sélectionner le chemin au package du 4D Client (4D Client.app) et non pas le chemin d'accès au dossier contenant le package. Ceci est valable quelle que soit la plateforme de génération d'application (Macintosh ou Windows). Ci-dessous une copie d'écran montrant un exemple de paramétrage du Client-Serveur :

Il n'est malheureusement pas possible de générer une application cliente double cliquable Windows (4D Client Engine) sous Macintosh et inversement. En effet, vous ne pouvez construire que la partie cliente double cliquable correspondante à la plateforme de génération de l'application. Sur une plateforme Macintosh, vous ne pouvez construire que la partie cliente Macintosh et sur une plateforme Windows vous ne pouvez construire que la partie cliente Windows. Les raisons sont purement techniques. Le système d'exploitation Windows est incapable de manipuler un package au sens Macintosh du terme. Il ne sait pas lire ou écrire les informations ou les ressources spécifiques (Info.plist…) d'un package. Inversement, un système Apple ne sait pas manipuler un exécutable «.exe» au sens Windows ou lire sa composition interne (les ressources, les icônes, etc.).

Après la compilation et la génération d'un 4D Client Engine (exécutable), le fichier « EnginedServer.xml » est absent du dossier « 4D Extensions ». Ce fichier permettrait la connexion automatique sur le serveur sans avoir à saisir l'adresse IP et le numéro de port spécifique. En effet, une génération via le dialogue ne permet pas de spécifier l'adresse IP et le numéro de port du 4D Serveur visé. Dans ce cas l'adresse du serveur qui sera utilisée est l'adresse locale de la machine de génération. Un contournement à ce problème consiste à créer manuellement ce fichier dans le dossier 4D Extensions. Voici un exemple du contenu de ce fichier.

   <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
   <Connection>
      <IPAdress>192.68.91.10,19815</IPAdress>
   </Connection>

Le numéro de port est facultatif. S'il n'est pas spécifié, c'est le numéro de port par défaut 19813 qui sera utilisé.

L'absence du fichier « EnginedServer.xml » est sans doute un manque à combler dans le dialogue, mais il est toutefois possible d'utiliser les clés adéquates dans un projet XML et de lancer la génération par programmation via la commande GENERER APPLICATION. L'exemple ci-après montre une partie des clés à insérer dans le projet de génération (BuilApp.XML) relatif à l'adresse IP et le numéro du port :

   <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
   <Preferences4D>
      <BuildApp>
         <CS>
            <BuildServerApplication>True</BuildServerApplication>
             <BuildCSUpgradeable>True</BuildCSUpgradeable>
             <CurrentVers>2</CurrentVers>
             <HardLink>Mabase_CS_Engine</HardLink>
             <IPAddress>192.68.10.10</IPAddress>
             <PortNumber>19815</ PortNumber >
          </CS>
       </BuildApp>
   </Preferences4D>

Par ailleurs, lorsque vous cochez les options « Dossier 4D Client Mac » et « Dossier 4D Client Win », vous générez dans le sous-dossier nommé Upgrade4Dclient une archive de l'application cliente au format Mac « archive.mac » et une archive au format Windows « archive.win ». Ceci est valable également, quelle que soit la plateforme de génération. Les archives générées sont utilisées lors de la mise à jour automatique des applications clientes. La copie d'écran suivante montre le contenu d'un dossier Upgrade4Dclient :

Note 1

Une application Client/Serveur personnalisée fonctionne uniquement avec une base de données compilée. Cela veut dire que vous ne pouvez pas utiliser cette nouveauté pour déployer un environnement de développement en Client/Serveur.

L'utilisation des clés XML vous permet de mieux personnaliser votre application C/S et d'automatiser la création des nouvelles versions destinées au déploiement. Nous vous proposons un exemple plus complet d'un projet de génération d'une application client/serveur. Pour utiliser ce projet, il convient d'appeler la commande GENERER APPLICATION en lui passant comme paramètre le chemin d'accès à ce projet (Monprojet.XML). Cette commande lance automatiquement la compilation si la base n'a pas été compilée.

Cet exemple fait appel à plusieurs clés XML pour gérer les caractéristiques suivantes :

• adresse IP du serveur visé ;
• numéro de port du serveur visé (s'il est différent de celui par défaut « 19813 ») ;
• icônes spécifiques de 4D Serveur Windows et des 4D clients (Mac et Windows) ;
• gestion de versions (version minimale, version maximale et version courante) ;
• gestion des plug-ins ;
• gestion des licences Client/Serveur de type OEM.

Note 2

Notez que les noms des clés suivantes ont changé depuis la version 2004.1. La chaîne de caractères « FolderIsValid » a été remplacée par « IncludeIt » pour plus de clarté.

/Preferences4D/BuildApp/SourcesFiles/RuntimeVL/RuntimeVLFolderIsValid
/Preferences4D/BuildApp/SourcesFiles/CS/ServerFolderIsValid
/Preferences4D/BuildApp/SourcesFiles/CS/ClientWinFolderIsValid
/Preferences4D/BuildApp/SourcesFiles/CS/ClientMacFolderIsValid

Elles doivent être nommées comme suit :

/Preferences4D/BuildApp/SourcesFiles/RuntimeVL/RuntimeVLIncludeIt
/Preferences4D/BuildApp/SourcesFiles/CS/ServerIncludeIt
/Preferences4D/BuildApp/SourcesFiles/CS/ClientWinIncludeIt
/Preferences4D/BuildApp/SourcesFiles/CS/ClientMacIncludeIt

Note 3 

Il est fortement conseillé de renommer vos projets et/ou de les placer dans d'autres endroits que celui par défaut «\Preferences\BuildApp », car toute génération via le dialogue d'interface depuis le mode structure recrée le projet par défaut « BuilApp.XML » et par conséquent, fait perdre son ancien contenu.

   <?xml version="1.0" encoding="UTF-8" standalone="no" ?> 
   <Preferences4D>
      <BuildApp>
         <BuildCompiled>False</BuildCompiled> 
         <BuildApplicationSerialized>False</BuildApplicationSerialized> 
         <BuildApplicationLight>False</BuildApplicationLight> 
         <SourcesFiles>
            <RuntimeVL>
               <RuntimeVLIncludeIt>False</RuntimeVLIncludeIt> 
            </RuntimeVL>
            <CS>
               <ServerIncludeIt>True</ServerIncludeIt> 
               <ClientWinIncludeIt>True</ClientWinIncludeIt> 
               <ClientMacIncludeIt>True</ClientMacIncludeIt> 
               <ServerWinFolder>F:\PC\4D Server\</ServerWinFolder> 
               <ClientWinFolderToWin>F:\PC\4D Client\</ClientWinFolderToWin> 
               <ClientMacFolderToWin>F:\Mac\4D Client.app\</ClientMacFolderToWin>
               <ServerIconWinPath>F:\PC\pc\Server.ico</ServerIconWinPath> 
               <ClientWinIconForWinPath>F:\PC\pc\Client.ico</ClientWinIconForWinPath> 
               <ClientMacIconForWinPath>F:\PC\Mac\client.icns</ClientMacIconForWinPath> 
            </CS>
         </SourcesFiles>
         <BuildApplicationName>Mabase_CS_Engine</BuildApplicationName> 
         <BuildWinDestFolder>F:\TEST_CS_ENGINE\Application_Cible\</BuildWinDestFolder>
         <CS>
            <BuildServerApplication>True</BuildServerApplication> 
            <BuildCSUpgradeable>True</BuildCSUpgradeable> 
            <RangeVersMin>1</RangeVersMin> 
            <RangeVersMax>5</RangeVersMax> 
            <CurrentVers>2</CurrentVers> 
            <HardLink> Mabase_CS_Engine </HardLink>
            <IPAddress>192.68.10.10</IPAddress>
            <PortNumber>19815</ PortNumber >
         </CS>
         <ArrayExcludedPluginName>
            <ItemsCount>1</ItemsCount> 
            <Item1>4D View</Item1> 
         </ArrayExcludedPluginName>
         <ArrayExcludedPluginID>
            <ItemsCount>1</ItemsCount>
            <Item1>13000</Item1> 
         </ArrayExcludedPluginID>
         <Licenses>
            <ArrayLicenseWin>
               <ItemsCount>1</ItemsCount> 
               <Item1>E:\Documents and Settings\All Users\Application Data\4D\Licenses\4SDE80....html</Item1>
            </ArrayLicenseWin>
            <ArrayLicenseTarget>
               <ItemsCount>1</ItemsCount>
               <Item1>1</Item1>
            </ArrayLicenseTarget>
         </Licenses>
      </BuildApp>
   </Preferences4D>

L'option « Permettre la mise à jour automatique de l'application cliente » du dialogue de génération d'applications provoque la mise à jour de toutes les parties clientes lors de leur première connexion après installation de la nouvelle version du serveur. On peut également utiliser la clé XML <BuildCSUpgradeable> pour l'activer (True) ou la désactiver (False) dans le projet XML de génération.

Par exemple la clé XML suivante active l'option :

   <BuildCSUpgradeable>True</BuildCSUpgradeable>.

Cette nouveauté de mise à jour de 4D Client vous permet d'automatiser le contrôle de correspondance de versions de 4D Client et 4D Serveur et vous dispense de passer sur toutes les machines de votre réseau pour effectuer toutes les mises à jour manuellement. Lors de cette opération, le serveur envoie son archive de mise à jour au Client. Ce dernier construit son successeur avant de le lancer. Le nouveau 4D Client supprime l'ancien 4D Client et se connecte automatiquement au serveur.

Le mécanisme de mise à jour mérite d'être analysé et compris afin de pouvoir résoudre les éventuels problèmes que vous pourriez rencontrer. Le début de ce mécanisme est géré par l'ancien 4D Client. Ensuite le script « upgclnt.bat » sous Windows ou le script « upgclnt.sh » sous Macintosh prend la relève pour terminer le processus de mise à jour. Ces scripts se trouvent dans le dossier « 4D Extensions » du nouveau 4D Client.

Dans le tableau suivant nous listons, dans l'ordre de leur exécution, toutes les actions entreprises depuis la tentative de connexion du 4D Client jusqu'à la connexion du nouveau 4D Client correctement mis à jour sur la machine de l'utilisateur :

Le dialogue de génération des applications permet de désigner chaque plug-in que l'on souhaite intégrer à l'application Client/Serveur (ou 4D Runtime volume licence). Par défaut tous les plug-ins chargés par 4D Monoposte sont inclus. Il est du ressort du développeur de désélectionner les plug-ins dans la liste affichée dans le troisième onglet du dialogue ou de spécifier les plug-ins à exclure en utilisant les clés <ArrayExcludedPluginName> et <ArrayExcludedPluginID> en cas de génération de l'application par programmation. Dans le projet XML précédent, vous pouvez noter que seul le plug-in 4D View ayant l'ID 13000 sera éliminé au moment de la génération.

Pour intégrer des plug-ins dans l'application C/S générée, vous pouvez les placer dans trois emplacements différents :

• dans le dossier « plugins » du 4D qui sert pour la compilation et la génération de l'application ;
• dans le dossier « plugins », « Mac4dx » ou « Win4dx » de la base source ;
• dans le dossier « plugins » de 4D Serveur.

Note 4

En cas de conflit entre deux versions différentes du même plug-ins, la priorité revient toujours aux dossiers « plugins » du 4D Serveur.

Nous vous proposons un scénario afin de mettre en évidence les mécanismes d'intégration des plug-ins. Soit la liste suivante des plug-ins (A) placés dans le dossier « plugins » du 4D mono servant à la création de l'application Client/Serveur :

Ensuite, on suppose que le dossier « plugins » de 4D Serveur contient les plug-ins (B) suivants :

Enfin, le dossier « plugins » de la base source contient le plug-in 4D open (C) :

Bien entendu, il n'y aura que les plug-ins (A) et (C) qui seront chargés par l'environnement du développement comme le prouve la copie d'écran suivante :

Notez que le plug-in 4D View a été désélectionné afin de l'exclure de la génération l'application. Après compilation et création, voici le contenu du dossier « plugins » de l'application Client/Serveur finale :

Notez la présence de tous les plug-ins (A) , (B) et (C) à l'exception de 4D View qui a été retiré volontairement avant la génération. Il est également important de préciser que les plug-ins 4D Internetcommands.bundle et 4D Pack.bundle sont les plug-ins venant du dossier « plugins » de 4D Serveur à cause de la priorité énoncée plus haut. Par ailleurs, à ce scénario d'intégration des plug-ins correspondent les simples clés XML suivantes :

      <ArrayExcludedPluginName>
         <ItemsCount>1</ItemsCount>
         <Item1>4D View</Item1>
      </ArrayExcludedPluginName>
      <ArrayExcludedPluginID>
         <ItemsCount>1</ItemsCount>
         <Item1>13000</Item1>
      </ArrayExcludedPluginID>

Note 5

Si un plug-in existe en double sous deux noms différents, un conflit d'ID sera détecté au lancement de 4D Serveur vous signalant que votre plug-in est installé deux fois et qu'il faudra en omettre un. Après l'affichage de ce message d'alerte 4D Serveur Quitte.

La gestion des licences des applications Client/Serveur exécutables est identique à celle de 4D Serveur standard et s'effectue toujours via la boîte de dialogue de mise à jour des licences sur le poste serveur. L'onglet « Licenses » du dialogue de génération d'applications concerne, plus particulièrement, les applications Client/Serveur exécutables de type OEM ou les applications de type « 4D Runtime Volume license ».

Pour une application Client/Serveur exécutable, cette option permet :

• de copier votre fichier de licences dans le nouveau dossier « Licenses » placé à côté de l'application exécutable (Windows) ou dans le progiciel (MacOs) ;
• d'insérer dans le projet de Build les clés XML relatives au licences.

Pour ajouter une licence 4D Server Developer Edition, cliquez sur le bouton « + » situé en bas de la fenêtre du quatrième onglet :

Le projet « BuildApp.XML » créé après la génération contient les clés XML supplémentaires suivantes :

   <Licenses>
      <ArrayLicenseWin>
         <ItemsCount>1</ItemsCount>
         <Item1>E:\Documents and Settings\All Users\Application Data\4D\Licenses\4SDE80....html</Item1>
      </ArrayLicenseWin>
      <ArrayLicenseTarget>
         <ItemsCount>1</ItemsCount>
         <Item1>1</Item1>
      </ArrayLicenseTarget>
   </Licenses>

Ces clés doivent être utilisées lors d'une deuxième génération via le langage. En effet, le projet XML ainsi créé doit être retravaillé afin d'insérer d'autres clés XML indispensables pour une régénération via la commande GENERER APPLICATION de l'application Client/Serveur exécutable OEM sérialisée. La clé la plus importante est sans doute « IsOEM » . Cette clé doit respecter l'arborescence suivante :

   <Preferences4D>
      <BuildApp>
         <SourcesFiles>
            <CS>
               <IsOEM>True</IsOEM >
            </CS>
         </SourcesFiles>
      </BuildApp>
   </Preferences4D>

La clé « IsOEM » permet de prendre en compte ou non les licences de déploiement OEM pour l'application client/serveur générée. Si cette clé contient la valeur True, l'application intégrera les licences de déploiement OEM. Si elle contient la valeur False ou est omise, l'application n'intégrera pas les licences de déploiement OEM. Dans ce cas, l'application sera générée en mode évaluation. À noter que l'emploi même de cette clé requiert également une licence OEM. De plus, après la génération de l'application Client/Serveur OEM finale, les licences copiées par 4D dans le dossier « Licenses » seront cryptées pour des raisons évidentes de confidentialité. Elles seront également indépendantes de la machine et liées par un lien fort (Hardlink) à l'application générée. C'est-à-dire qu'elles seront spécifiques à l'application et ne pourront pas être utilisées pour le déploiement d'une autre application Client/Serveur de type OEM ou non.

Pour plus d'informations, nous vous recommandons de consulter le manuel de 4D spécifique aux clés XML et qui fait, à lui seul, une cinquantaine de pages.

Dans cette présente note technique, nous vous avons détaillé certains mécanismes utilisés pendant la génération des applications Client/Serveur exécutables et la mise à jour automatique des parties clientes. Nous avons étudié en particulier la gestion des plug-ins, la gestion des licences et l'algorithme de mise à jour de 4D Client à partir de son archive qui se trouve sur le serveur. Un ensemble de conseils et d'astuces vous ont été également préconisés.