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 toujours de migrer un seul profil vers un autre profil sur la même machine ou sur une autre machine. Parmi les exemples figurent la migration d'un gestionnaire de déploiement WebSphere Application Server Version 7.0 vers un gestionnaire de déploiement de la Version 9.0 et la migration d'un serveur d'applications version 7.0 vers un Version 9.0 serveur d'applications autonome.
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.
Si le paramètre -setPorts est réglé sur generateNew ou une valeur de port lors de l'appel à WASPostUpgrade, cependant, la valeur de port est attribuée à chaque serveur d'applications qui est migré vers Version 9.0.
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.
Lors de la migration de tous les fichiers EAR WebSphere Application Server Version 7.0 ou ultérieures vers la Version 9.0 à l'aide de l'outil wsadmin, l'outil WASPostUpgrade utilise la valeur de taille de segment de mémoire Java maximale fixée par défaut à 64 Mo pour installer les fichiers EAR.
Si un fichier EAR Version 7.0 ou ultérieures ne parvient pas à s'installer lors de la migration car la taille de segment de mémoire Java n'est pas assez élevée, un message semblable au suivant s'affiche :java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError
Augmentez la taille de segment de mémoire Java maximale et suivez l'exemple pour installer l'application.
Exemple d'installation de l'application sur WebSphere Application Server Version 9.0
Hypothèses :- C:\WebSphere\AppServer
- Nom du fichier EAR
- Nom de l'application
- Nom du serveur sur lequel le fichier EAR est installé
- Nom du noeud sur lequel le serveur est configuré
wsadmin -conntype NONE -c "$AdminApp install C:\\WebSphere\\AppServer\\installableApps\\ EAR_file_name {-nodeployejb -appname app_name -server server_name -node node_name}"
Exemple d'installation de l'application sur WebSphere Application Server, Network Deployment Version 9.0
Hypothèses :- C:\WebSphere\ Manager
- Nom du fichier EAR
- Nom de l'application
- Nom du cluster sur lequel le fichier EAR doit être installé
wsadmin -conntype NONE -c "$AdminApp install C:\\WebSphere\\ Manager\\installableApps\\ EAR_file_name> {-nodeployejb -appname app_name -cluster cluster_name}"
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.
Vous pouvez recourir à plusieurs techniques pour définir différents niveaux de sécurité Java 2 dans la Version 9.0. L'une d'entre elles consiste à créer un fichier was.policy dans l'application pour activer tous les droits de sécurité. Les outils de la migration appellent la commande wsadmin pour ajouter le fichier was.policy du répertoire properties de Version 9.0 dans les applications d'entreprise au cours de leur migration.
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.
En règle générale, ces répertoires se trouvent dans le répertoire d'installation de la version précédente. L'emplacement par défaut de stdin, stdout et stderr est le répertoire logs de la racine d'installation de WebSphere Application Server 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.
Eviter les incidents: Dans un scénario où plusieurs versions coexistent, l'utilisation de répertoires communs peut générer des incidents.gotcha
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.