Mappage de configuration pendant la migration produit-configuration
Plusieurs applications sont mappées pendant la migration produit-configuration.

Cet article traite de la migration de configuration de profil. Pour faire migrer vos applications vers la dernière version, utilisez le kit d'outils de migration de WebSphere Application Server. Pour plus d'informations, voir Migration Toolkit on WASdev.
sptcfgLa migration implique la copie de votre configuration d'une édition précédente de WebSphere Application Server vers une nouvelle édition.
De nombreux scénarios de migration sont possibles. Les outils de migration mappent les objets et les attributs existant dans la version à partir de laquelle vous migrez vers les objets et les attributs correspondants dans Version 9.0 l'environnement.
Les outils de migration déplacent la valeur de l'ancienne version dans Version 9.0 l'environnement.
Les outils de migration convertissent les paramètres de ligne de commande en paramètres JVM (Java™ Virtual Machine) dans la définition des processus serveur. La plupart des paramètres sont mappés directement. Certains paramètres ne migrent pas étant donné que leur rôle dans la configuration de WebSphere Application Server Version 9.0 n'existe pas, a une autre signification ou une portée différente.
Pour obtenir des informations sur la façon de modifier les paramètres de définition des processus, voir Paramètres de définition des processus. Pour toute information sur la procédure de modification des paramètres JVM, voir Paramètres de machine virtuelle Java.
- Dans la Version 7.0 ou ultérieures, un serveur générique possède son propre type appelé GENERIC_SERVER. La migration effectuera cette conversion, mais elle ne peut pas migrer avec précision les ressources externes référencées par le serveur générique. Une fois la migration des paramètres du serveur terminée, il peut s'avérer nécessaire d'effectuer des tâches supplémentaires. Si l'ancienne ressource qui était gérée par le serveur générique est située sous l'ancienne installation de WebSphere Application Server, procédez comme suit :
Si l'ancienne ressource qui était gérée par le serveur générique n'est pas située sous l'ancienne installation de WebSphere Application Server, aucune autre action n'est requise.
Vous pouvez faire migrer un noeud WebSphere Application Server Version 7.0 ou ultérieures qui appartient à une cellule sans le retirer de la cellule.
Migrez d'abord le gestionnaire de déploiement, avant de migrer les noeuds de base de la cellule.
Important : Utilisez le même nom de cellule lorsque vous migrez WebSphere Application Server, Network Deployment de la Version 7.0 ou ultérieures vers la Version 9.0. Si vous utilisez un nom de cellule différent, les noeuds fédérés ne pourront pas migrer correctement vers la cellule WebSphere Application Server, Network Deployment Version 9.0.La migration d'un noeud de base WebSphere Application Server rattaché à une cellule vers la Version 9.0 entraîne également la migration de l'agent de noeud vers Version 9.0. Une cellule peut posséder des noeuds Version 9.0 et d'autres noeuds au niveau de la Version 7.0 ou ultérieures.
- WebSphere Application Server Version 9.0 procède à la migration de tous les fichiers de règles qui sont installés avec la Version 7.0 ou ultérieures en fusionnant les paramètres dans les fichiers de règles Version 9.0 avec les caractéristiques suivantes :
La procédure de migration copie les fichiers des répertoires de la version précédente dans la configuration de WebSphere Application Server Version 9.0.
WebSphere Application Server Version 9.0 procède à la migration de tous les fichiers de propriétés qui sont installés avec la Version 7.0 ou ultérieures en fusionnant les paramètres dans les fichiers de propriétés Version 9.0 :
Les fichiers RAR référencés par des ressources J2C sont migrés s'ils figurent dans l'ancien répertoire d'installation de WebSphere Application Server. Dans ce cas, ils sont copiés vers l'emplacement correspondant dans le nouveau répertoire d'installation de WebSphere Application Server. Les fichiers RAR de l'adaptateur de ressources relationnelles ne sont pas migrés.
Migration de ressources de niveau cluster :WebSphere Application Server version 6.0 a introduit le concept de ressources de niveau cluster. Ces dernières sont configurées dans les fichiers resourcexxx.xml dans les répertoires du cluster. Exemple :<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar"> ... </resources.j2c:J2CResourceAdapter>
Si vous avez une ressource de niveau cluster, celle-ci doit se trouver au même endroit sur chaque membre (noeud) du cluster. Par conséquent, si l'on reprend l'exemple précédent, le fichier EAR de chaque membre de cluster doit être installé dans ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} est résolu sur chaque membre du cluster pour obtenir l'emplacement exact.
Au cours de la migration d'un gestionnaire de déploiement, les outils migrent les fichiers du cluster sur un gestionnaire de déploiement, y compris les fichiers resourcexxx.xml files.
Durant la procédure de migration d'un noeud fédéré, les outils traitent chaque adaptateur J2C.
Migration de fichiers RAR depuis une version 7.0 vers la Version 9.0 :
La migration depuis la version 7.0 vers la Version 9.0 copie les fichiers tels que les fichiers RAR depuis WAS_INSTALL_ROOT vers WAS_INSTALL_ROOT et depuis USER_INSTALL_ROOT vers USER_INSTALL_ROOT.
Lorsqu'un fichier RAR se trouve dans WAS_INSTALL_ROOT pour la version 7.0. par exemple, les outils de migration ne copient pas automatiquement le fichier de WAS_INSTALL_ROOT vers USER_INSTALL_ROOT. Cela permet de préserver l'intégrité des ressources J2C de niveau cluster.
Toutefois, si vous avez codé en dur le chemin d'un fichier RAR (archivePath="C:/WAS/installedConnectors/x2.rar", par exemple) dans la version 7.0, les outils de migration de la Version 9.0 ne peuvent pas modifier l'attribut archivePath en conséquence car ceci entraverait le fonctionnement de tous les autres membres du cluster n'ayant pas migré.La migration des exemples des versions précédentes n'est pas disponible. Il existe des exemples WebSphere Application Server Version 9.0 équivalents que vous pouvez installer.
La sécurité Java 2 est activée par défaut lorsque vous activez la sécurité dans WebSphere Application Server Version 9.0. La sécurité Java 2 exige que vous octroyiez des droits de sécurité de manière explicite.
Lors de la migration vers WebSphere Application Server Version 9.0, votre décision de préserver ou non la compatibilité des scripts débouche sur l'une des deux situations suivantes :Pour toute information sur la migration de vos configurations de sécurité vers Version 9.0, consultez l'article "Migrating, coexisting, and interoperating – Security considerations" dans la documentation.
Dans WebSphere Application Server for z/OS, les sorties de stdin, stdout et stderr sont dirigées par défaut vers SYSOUT. Si elles sont redirigées vers le répertoire de configuration d'une version antérieure, il peut s'avérer nécessaire de le modifier dans le JCL de la Version 9.0.
Les outils de migration tentent de migrer les répertoires de passivation et de travail. Sinon, des valeurs par défaut appropriées de la Version 9.0 sont utilisées.
Si les ID utilisateur de WebSphere Application Server for z/OS disposent de répertoires de base dans le répertoire de configuration d'une version antérieure, vous devez les mettre à jour avant la migration pour leur affecter un autre emplacement.
Eviter les incidents: Dans un scénario où plusieurs versions coexistent, l'utilisation de répertoires communs peut générer des incidents.gotcha
Les outils de migration migrent tous les ports. Tous les conflits de ports doivent être résolus avant de pouvoir exécuter les serveurs simultanément.
Remarque : Si des ports sont déjà définis dans une configuration devant migrer, les outils de migration corrigent les conflits de port dans la configuration de la Version 9.0 et consignent les modifications pour que vous puissiez les vérifier.Vous devez ajouter manuellement des entrées d'alias d'hôte virtuel pour chaque port. Pour plus d'informations, reportez-vous à l'article relatif à la configuration des hôtes virtuels dans la documentation.
Le niveau de spécification de Java EE (Java Platform, Enterprise Edition) mis en oeuvre dans WebSphere Application Server version 7.0 nécessitait des modifications de comportement dans le conteneur Web pour définir le type de contenu. Si le développeur du servlet par défaut ne définit pas le type de contenu, non seulement le conteneur Web n'utilise pas celui par défaut mais renvoie également la valeur "null" pour l'appel. Cette situation peut entraîner un affichage incorrect par certains navigateurs des balises de conteneur Web générées. Afin d'éviter que ce problème ne se produise, la procédure de migration affecte à l'extension IBM® autoResponseEncoding la valeur "true" pour les modules Web lors de la migration d'applications d'entreprise.