En tant qu’éditeur, vous souhaitez parfois dupliquer une application client fusionnée pour connecter chacun d’entre eux à leur serveur 4D dédié. Voyons comment procéder.
Lorsque vous êtes éditeur de logiciels, certains de vos clients disposent parfois de nombreuses instances de votre application serveur fusionnée, par exemple une application serveur fusionnée pour chaque société d’un groupe. Dans ce type d’architecture de déploiement, les responsables de votre client vous demandent souvent d’installer sur leur ordinateur une application client fusionnée pour chaque application serveur fusionnée, car ils veulent utiliser le logiciel pour chaque société.
Puisque l’adresse de l’application serveur fusionnée n’est plus stockée dans le fichier EnginedServer.4DLink à l’intérieur du paquetage de l’application client fusionnée (pour ne pas le modifier), toutes les applications client fusionnées partagent la même adresse de serveur stockée dans le dossier des préférences de l’utilisateur.
Désormais, vous disposez d’une nouvelle clé buildApp pour que chaque application client fusionnée dupliquée utilise son propre dossier de préférences utilisateur (en fonction du chemin d’accès de l’application) :
<BuildApp>
<CS>
<ClientUserPreferencesFolderByPath>True</ClientUserPreferencesFolderByPath>
Rappelez-vous simplement que pour contourner la diffusion automatique sur le réseau et faire en sorte que chaque application client fusionnée se connecte à son dernier Serveur, il faut publier chaque application serveur fusionnée sur un port autre que celui de la norme 4D (19813) et sur un port autre que celui défini lors de buildApp.
Bien entendu, lorsque ce comportement est activé, les touches Folder et Get 4D Folder renvoient toujours le dossier correct pour chaque application client fusionnée.
Cerise sur le gâteau, si vous utilisez le paramètre étoile magique de la commande Open form window les fenêtres de chaque application client fusionnée retrouveront leur propre taille et position, en fonction de l’organisation du bureau des utilisateurs.
La même architecture peut également être utile pour les développeurs ou les testeurs qui souhaitent se connecter à un serveur de test, un serveur de pré-production ou un serveur de production. De cette façon, ils peuvent avoir des applications clientes fusionnées dupliquées et connectées à leur serveur dédié.
Exemple de
Un groupe utilise le logiciel myCRM pour gérer les clients de ses entreprises. Chaque entreprise dispose de son propre serveur myCRM. Pour éviter qu’une application client fusionnée ne se connecte automatiquement à la première application serveur trouvée sur le sous-réseau, chaque application serveur est publiée sur un numéro de port différent de 19813 et défini lors de buildApp.
Les managers du groupe peuvent facilement se connecter au serveur qu’ils souhaitent en dupliquant les applications clientes fusionnées.
Au premier lancement, il suffit de maintenir la touche ALT enfoncée sur le clavier pour afficher le dialogue de connexion standard 4D. Saisissez ensuite les informations d’identification du serveur appropriées et connectez l’application client au serveur. Les informations d’identification du serveur sont ensuite stockées dans un dossier lié au chemin de l’application client fusionnée.
Après cela, chaque application client fusionnée se connectera automatiquement à son application serveur dédiée !
