L’hébergement de plusieurs applications 4D Server sur la même machine n’est pas inhabituel, notamment pour les environnements de production et de pré-production. Mais si votre machine héberge des applications serveur fusionnées construites avec des versions 4D différentes, ce qui est le cas si vous utilisez votre serveur de pré-production avec la dernière version 4D, vous pouvez rencontrer des problèmes dus au dossier de structure 4D partagé.
Voyons comment résoudre ce problème.
Lorsqu’elle est lancée, une application serveur fusionnée appelée « myApp » crée un dossier de structure :
Tant que votre application garde le même nom de structure (pour conserver les mises à jour automatiques ou la commande de lancement du service Windows) et évolue avec les différentes versions de 4D, le dossier de structure est le même pour chaque application serveur fusionnée.
Pour éviter de partager ce dossier système entre des applications serveur fusionnées construites avec différentes versions de 4D (comme le montre l’image ci-dessus), vous pouvez maintenant définir le nom du dossier pendant le processus de construction de l’application.
Une nouvelle clé buildApp est à votre disposition pour définir votre propre dossier de structure :
<BuildApp>
<CS>
<ServerStructureFolderName>myApp_v18R5</ServerStructureFolderName>
En conséquence, si vous définissez « myApp_v18R5 » pour votre serveur construit avec 4D v18 R5 et « myApp_v18R6 » pour celui avec 4D v18 R6 pendant le processus d’application de construction, vous aurez des dossiers de structure séparés dans le système :
Déploiements sûrs !