Cette nouvelle fonctionnalité améliore la gestion des ressources locales des applications fusionnées de 4D Client exécutées avec les services Windows Remote Desktop. Voyons comment.

Les services Windows Remote Desktop permettent aux utilisateurs d’ouvrir une session Windows ou une RemoteApp, à l’intérieur et à l’extérieur du réseau de l’entreprise. De cette manière, les utilisateurs peuvent se connecter à leurs applications depuis n’importe où grâce à une connexion Internet. Lorsque l’application n’est pas optimisée pour l’utilisation de la bande passante Internet, les services Bureau à distance sont souvent utilisés pour la limiter : aucune donnée n’est échangée entre l’application et le serveur, mais seulement des changements d’écran.

L’architecture STANDARD

Lorsqu’une application fusionnée 4D Client se connecte à une application fusionnée 4D Server, un contrôle est effectué pour vérifier que le code source de l’application (code compilé, formulaires, ressources externes, etc., généralement appelé « ressources locales ») du côté Client est le même que celui du côté Serveur. Si nécessaire, le code source de l’application est ensuite téléchargé du serveur 4D par l’application fusionnée 4D Client et stocké dans le dossier de l’utilisateur :
\Users\{UserAccount}\AppData\Local\{ApplicationName}\{ServerInformation}_ClientFolderSignature\\
Par exemple, C:\Users\John Doe\AppData\Local\myApp\myApp_192_168_2_134_19813_157\

Ainsi, lorsque plusieurs utilisateurs ouvrent la même application fusionnée 4D Client sur un serveur Windows avec les services Bureau à distance, les ressources locales sont téléchargées par chaque utilisateur dans son propre dossier utilisateur. Il y a alors une copie des mêmes fichiers dans chaque dossier utilisateur.

Une nouvelle architecture à votre disposition

Pour améliorer le stockage et le transfert des données locales, 4D a développé une nouvelle option pour les projets dans le processus BuildApp afin de permettre la mutualisation des ressources locales. Elle est activée par cette nouvelle clé XML BuildApp :
/Preferences4D/BuildApp/CS/ShareLocalResourcesOnWindowsClient

L’ancien comportement prévaut si la nouvelle clé a une valeur « False » ou est absente.
Et si cette nouvelle clé a une valeur « True », l’application fusionnée 4D Client utilisera les ressources locales placées dans ce chemin commun :
\ProgramData\{ApplicationName}\{ServerInformation}_ClientFolderSignature\\\_
par exemple C:\Program Data\myApp\myApp_192_168_2_134_19813_157\_.

Notez que le dossier des logs est toujours placé dans le dossier utilisateur pour éviter les écritures simultanées.

Processus de mise à jour

Les administrateurs des Services Windows Remote Desktop sont souvent faciles avec le processus de mise à jour des applications, mais nous voulions rappeler les meilleures pratiques pour effectuer les mises à jour. Un administrateur doit :
1. Déconnecter tous les utilisateurs exécutant l’application fusionnée 4D Client à mettre à jour.
2. Interdire aux utilisateurs l’accès à l’application fusionnée 4D Client.
3. Mettez à jour l’application fusionnée 4D Server.
4. Si une mise à jour automatique du client est activée : dans la session Administrateur, lancer l’application fusionnée 4D Client et valider le processus de mise à jour automatique. A la fin du processus, l’application fusionnée 4D Client sera lancée, connectée à l’application fusionnée 4D Server, et les mises à jour automatiques des ressources locales seront effectuées dans le dossier partagé.
5. Si la mise à jour automatique du client est désactivée : dans la session Administrateur, mettez à jour manuellement l’application fusionnée 4D Client et lancez-la pour vous connecter à l’application fusionnée 4D Server et effectuer les mises à jour automatiques des ressources locales dans le dossier partagé.
6. Autorisez les utilisateurs à accéder à l’application fusionnée 4D Client.
Cette procédure permet de s’assurer que les utilisateurs ne lancent pas plusieurs instances de l’application fusionnée 4D Client, évitant ainsi les écritures simultanées sur les ressources locales partagées ou les erreurs de droits d’écriture.

A retenir

Ce n’était pas une bonne pratique d’ajouter/modifier/supprimer des fichiers ou dossiers dans le dossier des ressources locales à cause des mises à jour automatiques du serveur. Ceci est encore plus vrai avec ce nouveau comportement car le dossier des ressources locales est partagé entre les utilisateurs et souvent en lecture seule pour les utilisateurs standards ! Il vaut mieux utiliser le dossier Documents de l’utilisateur ou, éventuellement, le dossier des préférences de l’utilisateur 4D.