Aspects du développement d'applications pour Windows TSE

Laurent Dardenne

Cet article aborde quelques règles simples à respecter lors du développement d'application Windows devant être exécutées dans un environnement multiutilisateur Windows Terminal Serveur ou Metaframe de Citrix.

Cet article ne décrit pas le fonctionnement ni les API spécifiques à ces plateformes. ♪

- Titre : Aspects du développement d'applications pour Windows TSE

- Auteur : Laurent Dardenne

- Parution : 4 août 2004

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2004 Laurent Dardenne. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Préconisations générales

- I-A. Base de registre

- I-B. Fichiers INI

- I-C. Chemins d'accès

- I-D. Identification du client

- I-E. Exécution multiple

- I-F. Gestion de la mémoire

- I-G. Utilisation Hardware

- I-H. Regional Settings

- II. Préconisations particulières

- II-A. Objets NT4

- II-B. Fin de l'application

- II-C. Objets Animés

- II-D. Imprimantes

- II-E. Scripts de compatibilité

- III. Validation et homologation

I - Préconisations générales

Vous trouverez ici les contraintes les plus courantes liées au développement et à l'intégration d'applications dans un environnement multiutilisateur TSE/Metaframe.

Terminal Server Edition, Microsoft.
Metaframe, Citrix ( surcouche pour TSE ).

voir « Using and Developing Applications Compatibility Scripts with Windows NT® Server 4.0, Terminal Server Edition ».

I-A - Base de registre

Les applications doivent utiliser correctement les clefs HKEY_LOCAL_MACHINE et HKEY_CURRENT_USER de la base de registre.

- L'application doit utiliser la clef HKEY_LOCAL_MACHINE uniquement pour stocker des informations globales, communes à tous les utilisateurs.

- L'application doit utiliser la clef HKEY_CURRENT_USER uniquement pour stocker des informations propres à l'utilisateur.

Tout développement doit tenir compte que dans un environnement TSE, une machine n'est pas équivalente à un utilisateur.

I-B - Fichiers INI

Pour fournir les fonctionnalités multiutilisateurs, le système TSE gère les fichiers INI de manière à ce que chaque utilisateur ait ses propres fichiers (utilisation du répertoire Windows dans le %HOMEPATH% de l'utilisateur).
Pour accéder aux fichiers INI, l'application doit utiliser les API Win32 spécifiques à la gestion de ces fichiers et ne doit surtout pas utiliser des fonctions classiques d'ouverture, de modification de fichier (par exemple les fonctions de type « fopen » ne doivent pas être utilisées pour manipuler les fichiers .INI).

I-C - Chemins d'accès

Aucun chemin d'accès ne doit être codé en dur dans l'application, exemple C:\Path. En particulier si l'application utilise des fichiers temporaires il est impératif que le répertoire de travail soit pris dans l'environnement de l'utilisateur par exemple en utilisant la variable d'environnement %TEMP%.

I-D - Identification du client

Dans le cas d'une application client/serveur, l'application ne doit pas utiliser l'adresse IP comme identifiant du client. Sur un système TSE (Microsoft )/METAFRAME (Citrix) tous les utilisateurs accèdent au réseau avec la même adresse IP. Il est recommandé d'utiliser soit un fichier INI avec l'identifiant de l'utilisateur soit les variables %USERNAME% et/ou %CLIENTNAME%.

%USERNAME% retourne le nom de login NT de l'utilisateur.
%CLIENTNAME% retourne le nom du poste client de l'utilisateur, cette variable n'est disponible que dans l'environnement TSE/METAFRAME, les applications doivent alors prendre en compte cette remarque si le code utilisé doit fonctionner sur un poste classique et sur un serveur TSE/METAFRAME.

I-E - Exécution multiple

Si l'application gère la communication IP, il faut s'assurer que les sockets privées sont allouées dynamiquement. Cette technique doit permettre d'exécuter plusieurs instances de la même application.
Sur un poste local, il doit être possible de lancer plusieurs instances de l'application. Si ça n'est pas le cas l'application ne peut pas être installée sur un système TSE/METAFRAME.

I-F - Gestion de la mémoire

Il est évident que l'application doit gérer correctement l'allocation et la libération des espaces mémoire. Sachez que la consommation anormale de mémoire est ici amplifiée par le fait que l'application sera lancée plusieurs fois sur le serveur.

I-G - Utilisation Hardware

Les applications qui utilisent des ports de communication (PARALLÈLE ou SÉRIE) doivent utiliser l'environnement système pour retrouver la configuration des ports disponibles et les fonctions du système NT pour piloter ces ports.

Il est vivement déconseillé d'accéder à ces ports directement par des codes d'interruption DOS.

I-H - Regional Settings

Toute application faisant usage des « regional settings » (paramètres régionaux) doit le faire de manière à s'adapter aux « regional settings » en vigueur dans l'implantation ou le groupe d'utilisateurs concernés.

Par exemple, une application susceptible d'être déployée à l'étranger ne peut imposer d'utiliser des formats de dates issus des regional settings « french » alors que les « regional settings » en vigueur des sessions utilisateurs des sites à l'étranger peuvent être « english ».

Note : ces précautions sont identiques que l'on soit dans une session utilisateur TSE/Metaframe ou que l'on soit dans une session NT Workstation.

II - Préconisations particulières

II-A - Objets NT4

Il faut vérifier que l'outil de développement utilisé construit les applications avec les objets Microsoft NT4 (exemple : boite de dialogue d'ouverture de fichier).

L'application ne doit pas forcer le rafraîchissement des menus par des fonctions qui désactivent et activent l'affichage complet de l'application. Ces méthodes ont pour effet de provoquer un réaffichage complet de l'interface ce qui est coûteux en ressources réseau dans le cas d'un client distant.

II-B - Fin de l'application

Pour Citrix
Lorsque l'application est destinée à être utilisée au travers de la publication ICA, il est nécessaire que la gestion de la fin d'exécution soit gérée correctement.
Si l'utilisateur termine l'application par un clic sur la croix en haut à droite de la fenêtre ou en sélectionnant la fonction Close (Alt-F4) il faut que le programme gère cette fin de programme comme si l'utilisateur quittait l'application par le menu 'Quitter'.

II-C - Objets Animés

Tous les objets animés de type écran de veille ou horloge sont à proscrire de tous les écrans d'une application, car chaque mise à jour de l'écran, répercutée sur le poste client, a un coût réseau important.
Par ailleurs les fonds d'écran doivent être le plus simple possible, les fonds de type photo en haute résolution sont déconseillés.

II-D - Imprimantes

Tous les pilotes d'imprimantes ne sont pas forcement supportés par le système TSE/METAFRAME.
Il est important de vérifier que l'application n'exige pas une imprimante particulière (caractéristiques spécifiques à cette imprimante). Si tel est le cas, il faut vérifier que le pilote de l'imprimante est supporté sur TSE/METAFRAME, le site du constructeur de l'imprimante peut fournir ce renseignement ou le site du support de CITRIX contient des informations sur les pilotes déjà référencés comme n'étant pas supportés sur TSE/METAFRAME.

II-E - Scripts de compatibilité

Pour compléter l'installation et la configuration d'une application, il est possible de créer des scripts de compatibilité qui vont assurer la distribution de fichiers et la configuration de l'environnement pour chaque utilisateur.
Des scripts sont déjà disponibles pour les applications standards telles que MS Office. Ces scripts sont stockés dans le répertoire « Application Compatibility Scripts » et peuvent être utilisés comme base pour configurer une application particulière.

III - Validation et homologation

Dans un premier temps la validation des points précédents permet d'enclencher la phase d'homologation technique celle-ci déclenchant l'homologation fonctionnelle.

Ensuite il vous reste à étudier les points suivants :

- volumétrie des impressions, en ayant à l'esprit le goulet d'étranglement qu'ils représentent dans cet environnement ;

- impacts pour les aspects dimensionnement des capacités réseau ;

- tests de faisabilité et de dimensionnement des serveurs TSE ;

- tests de montée en charge ;

- recensements des informations à fournir auprès du support technique/Hot-line ;

- procédures de livraisons spécifiques.

Bien sûr, selon votre architecture d'autres points peuvent être contrôlés. Sachez que l'intégration d'une application peut prendre d'une 1/2 journée à trois semaines selon les difficultés techniques et/ou organisationnelles rencontrées.