Ce document de référence décrit les règles techniques et de sécurité à respecter lors de la création d'une application liée HATS/WebFacing.
Les applications liées HATS/WebFacing doivent respecter un certain nombre de règles techniques et de sécurité. En général, toute limitation imposée à une application HATS ou WebFacing autonome s'applique également à un projet lié HATS/WebFacing. En outre, vous devez prendre en compte les informations qui suivent lors de la conception et du déploiement de vos propres projets.
Certaines modifications effectuées sur les applications HATS et WebFacing individuelles ne toucheront pas le projet lié HATS/WebFacing. En particulier, après la création du projet, les options de configuration indiquées dans l'assistant de création de projet lié HATS/WebFacing (comme le nom d'hôte ou le port, la page de codes et la taille de l'écran) ne peuvent être changées que via la modification du fichier wfhats.xml ou le redémarrage de l'assistant de création de projet. La modification des paramètres de connexion après la création du lien dans le projet HATS ou WebFacing ne touche pas le projet lié.
La touche de fin de zone est gérée différemment dans HATS et dans WebFacing. Dans HATS, le formatage et la validation des données sont réalisés à l'exécution. Mais dans WebFacing, le formatage et la validation des données sont effectuées côté client dans le navigateur. Le raccourci-clavier par défaut pour la touche de fin de zone dans HATS et dans WebFacing est Ctrl+Entrée. Voir Providing documentation for users pour connaître les autres raccourcis-clavier disponibles dans les projets HATS.
Les macros de connexion HATS s'exécutent lorsque l'on accède à l'application HATS pour la première fois (à l'entrée initiale dans l'application liée ou à l'accès à un écran hôte qui n'a pas été converti par WebFacing). C'est pourquoi vous ne devez pas créer une macro de connexion destinée à l'écran de connexion si votre application liée doit démarrer à partir de WebFacing. Les macros de déconnexion ne s'exécutent que si l'application liée est arrêtée à partir de l'environnement d'exécution HATS.
Les événements Start et Connect définis dans un projet HATS s'exécutent lorsque l'on accède à l'application HATS pour la première fois. Si l'application liée est démarrée à partir de WebFacing, les actions définies dans ces événements ne seront exécutées que lorsque l'utilisateur aura accédé à un écran hôte qui n'a pas été converti par WebFacing. C'est pourquoi vous ne devez pas, par exemple, lancer une macro destinée à l'écran de connexion dans l'événement Connect si votre application liée doit démarrer à partir de WebFacing.
Si vous utilisez la console d'administration de HATS pour modifier les paramètres de la licence en étant en mode Exécuter sur le serveur, vous devez redémarrer votre application liée pour que ces modifications s'appliquent. Si vous utilisez la console d'administration de HATS pour modifier les paramètres de la licence en étant en mode Déboguer sur le serveur, les modifications ne s'appliqueront pas à l'application liée. En effet, la console d'administration HATS modifie le fichier runtime-debug.properties pendant une exécution en mode Débogage et l'application liée utilise le fichier runtime.properties pour définir ses paramètres de licence. Notez également qu'en mode Déboguer sur le serveur, il est recommandé de vérifier que les paramètres de licence du fichier runtime.properties correspondent à ceux du fichier runtime-debug.properties.
Pour les projets liés HATS/WebFacing, le seul serveur d'applications pris en charge pour le déploiement est IBM WebSphere Application Server.
Le seul navigateur client pris en charge pour une application liée HATS/WebFacing est Microsoft Internet Explorer.
Une application liée HATS/WebFacing doit être composée d'un projet activé HATS/WebFacing et d'un projet Web HATS. Les autres types de projet WebFacing (Web et portlet) et les projets HATS (projets de client enrichi, projets de portail et projets Enterprise JavaBeans) ne peuvent pas être liés.
L'applet HATS n'est pas prise en charge pour les applications liées HATS/WebFacing. Ne configurez pas votre projet pour qu'il utilise cette applet.
Toute personnalisation d'écran réalisée avec HATS restera sans effet si cet écran est également converti avec WebFacing. En effet, c'est la conversion WebFacing qui sera utilisée au moment de l'exécution.
Lorsque vous exécutez une application liée HATS/WebFacing, le regroupement de connexions HATS n'est pas utilisé, même s'il est configuré dans le projet HATS.
Lorsque vous exécutez une application liée, la connexion est persistante. Les fonctions non-persistantes, comme la reprise en ligne, ne fonctionnent pas correctement.
La prise en charge de l'ID poste de travail n'est pas disponible pour les applications liées HATS/WebFacing. Vous pouvez lier une application HATS qui est configurée pour un ID poste de travail spécifique ; cependant, ce paramètre ne sera pas pris en compte à l'exécution.
Les projets HATS peuvent avoir à la fois une connexion de transformation principale et d'autres connexions d'arrière-plan, à un même hôte ou à des hôtes différents. Les caractéristiques d'un projet lié et les paramètres de connexion ne s'appliquent qu'à la connexion de transformation principale.
Pour utiliser un profil avec des fonctions limitées, vous devez démarrer l'application liée à partir de l'interface HATS.
Si vous mettez à jour la racine de contexte d'un projet après l'avoir lié à l'autre, vous devrez mettre à jour le fichier wfhats.xml pour que ces changements soient pris en compte. Ce fichier est situé dans le dossier principal du projet lié HATS/WebFacing.
Vous ne pouvez pas accéder simultanément à de multiples applications liées dans la même instance du navigateur. Par exemple, si vous ouvrez le navigateur et que vous lancez l'application A et que vous créez une fenêtre enfant dans le navigateur, vous ne pouvez pas accéder ensuite à l'application B dans cette fenêtre enfant. Une fenêtre enfant est une fenêtre ouverte par la commande Ctrl-N ou Fichier->Nouveau->Fenêtre dans Internet Explorer. La même règle s'applique aux onglets d'Internet Explorer version 7. En outre, si vous souhaitez accéder à l'application A, puis à l'application B dans le même navigateur, vous devez tout d'abord vous déconnecter correctement et quitter l'application A avant d'accéder à l'application B. Cela n'est valable que si les applications A et B ont la même racine de contexte.
Vous risquez d'obtenir des résultats inattendus en accédant à une application liée HATS/WebFacing si vous utilisez les boutons Actualiser et Précédente du navigateur. Consultez la foire aux questions HATS pour plus d'informations.
Bien que les outils de développement HATS vous permettent de créer des macros qui naviguent dans des écrans DDS convertis pour WebFacing, ces macros ne pourront pas fonctionner si l'application essaie d'afficher les écrans convertis pour WebFacing. Les macros ne peuvent pas gérer les écrans convertis pour WebFacing si leurs fichiers d'affichage ont été ouverts avant le lancement de la macro. L'application s'arrête alors en générant une erreur.
preserve-base-href = yes
Créez toutes les jonctions avec le paramètre -j pour permettre à WebSEAL de fournir un cookie d'identification de jonction au navigateur.
Pour plus d'informations sur ces options, reportez-vous à la documentation de Tivoli Access Manager.