Différentes configurations sont mappées pendant la migration de configuration produit.
De nombreux scénarios de migration sont possibles. Les outils de migration mappent les objets et les attributs existants de la version à partir de laquelle vous migrez avec les objets et attributs correspondants dans l'environnement de la version plus récente.
Les outils de migration convertissent les paramètres du ligne de commande appropriés en paramètres JVM (Java™ Virtual Machine) dans la définition du processus serveur. La plupart des paramètres sont mappés directement. Certains paramètres ne font pas l'objet d'une migration parce qu'ils n'ont pas de rôle dans la configuration WebSphere ESB version 6.2 ou bien leur rôle a une signification ou une portée différente.
Pour plus d'informations sur la modification des paramètres de définition de processus, consultez la rubrique Paramètres des définitions de processus dans le centre de documentation de WebSphere Application Server Network Deployment, version 6.1. Pour plus d'informations sur la modification des paramètres JVM (Java Virtual Machine), consultez la rubrique Paramètres JVM (Java Virtual Machine) dans le centre de documentation de WebSphere Application Server Network Deployment, version 6.1.
Lors de la migration de tous les fichiers EAR WebSphere ESB vers la version 6.2 à l'aide de l'outil wsadmin, l'outil WBIPostUpgrade utilise, pour installer les fichiers EAR, la taille maximale par défaut (64 Mo) du tas Java.
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError
Augmentez la taille maximale de pile Java et suivez l'exemple ci-après pour installer l'application.
Exemple d'installation d'une application sur WebSphere ESB version 6.2
wsadmin -conntype NONE -javaoption -Xmx###m -c "$AdminApp install C:\\WebSphere\\ProcServer <nom_fichier_EAR> {-nodeployejb -appname nom_app -cluster nom_cluster}"
Vous pouvez migrer un noeud WebSphere ESB version 6.0.x ou 6.1.x qui appartient à une cellule vers un noeud WebSphere ESB version 6.2 sans retirer le noeud de la cellule.
Faites migrer le gestionnaire de déploiement en premier, avant de faire migrer les noeuds de base de la cellule.
Utilisez le même nom de cellule lors de la migration de version 6.0.x ou 6.1.x vers version 6.2. Si vous utilisez un nom de cellule différent, les noeuds fédérés ne peuvent pas migrer vers la cellule WebSphere ESB version 6.2.
Faire migrer un noeud WebSphere ESB de base situé à l'intérieur d'une cellule vers version 6.2 fait également migrer l'agent de noeud vers version 6.2.
La migration copie les fichiers issus des répertoires de version antérieure dans la configuration WebSphere ESB version 6.2.
WebSphere fait migrer tous les fichiers de propriétés qui sont installés avec la version 6.0.x ou 6.1.x en fusionnant les paramètres dans les fichiers de propriétés de la version 6.2.
La migration ne superpose pas les fichiers de propriété.
Les fichiers RAR et JAR qui sont utilisés par des ressources de l'architecture J2EE Connector sont migrés comme suit :
Migration de ressources de niveau cluster
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" name="ims" archivePath="${WAS_racine_installation}\installedConnectors\x2.rar"> ... </resources.j2c:J2CResourceAdapter>
Si vous avez une ressource de niveau cluster, cette ressource doit être au même endroit sur chaque membre du cluster (noeud). Par conséquent, dans l'exemple ci-dessus, pour chaque membre du cluster, le fichier RAR doit être installé à l'emplacement ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} est résolu sur chaque membre du cluster pour obtenir un emplacement exact.
Dans la migration d'un gestionnaire de déploiement, les outils fournis créent les fichiers du cluster sur le gestionnaire de déploiement, y compris les fichiers resourcexxx.xml.
Si vous avez codé en dur un chemin vers un fichier RAR (archivePath="C:/WAS/installedConnectors/x2.rar" par exemple) dans la version 6.0.x ou 6.1.x, les outils de migration de la version 6.2 ne peuvent cependant pas modifier l'attribut archivePath pour en tenir compte sinon tous les autres membres du cluster qui n'ont pas été migrés seraient supprimés.
Pendant la migration d'un profil autonome, aucun exemple de WebSphere ESB n'est migré. Des exemples de version 6.2 équivalents sont disponibles pour tous les exemples de version 6.2.
La sécurité Java 2 est activée par défaut lorsque vous activez la sécurité dans WebSphere ESB version 6.2. Pour utiliser la sécurité Java 2, vous devez avoir des permissions de sécurité explicites.
Plusieurs techniques permettent de définir les différents niveaux de sécurité Java 2 dans version 6.2. L'une d'elle consiste à créer un fichier was.policy en tant que partie de l'application pour activer toutes les autorisations de sécurité. Les outils de migration appellent la commande wsadmin pour ajouter un fichier was.policy existant au répertoire properties de la version 6.2 aux applications d'entreprise lorsqu'elles sont migrées.
C'est la valeur par défaut.
Par exemple, les fichiers de clés (keyfiles) et fichiers de clés certifiées (trustfiles) existants sont supprimés du répertoire SSLConfig et de nouveaux objets de fichiers de clés (keystore) et de fichier de clés certifiées (truststore) sont créés.
Pour conserver les mêmes paramètres de sécurité, vous devez faire migrer les paramètres de sécurité de WebSphere Application Server qui définis pour la version 6.0.2.x. Pour plus d'informations sur la migration de vos configurations de sécurité vers la version 6.2, reportez-vous la rubrique Migration, cohabitation et interopération - Remarques de sécurité dans le centre de documentation de WebSphere Application Server Network Deployment, version 6.1.
Ces répertoires sont généralement situés dans le répertoire d'installation d'une version précédente. L'emplacement par défaut pour stdin, stdout et stderr correspond au répertoire logs de la racine d'installation WebSphere ESB version 6.2.
Les outils de migration cherchent à migrer les répertoires de travail et de passivation existants. Sinon, les valeurs par défaut appropriées de la version 6.2 sont utilisées.
Pour plus d'informations sur les répertoires de passivation, reportez-vous à la rubrique Paramètres du conteneur EJB. Pour davantage d'informations sur les répertoires de travail, voir Paramètres des définitions de processus.
Dans un scénario où plusieurs versions coexistent, l'utilisation de répertoires communs peut générer des incidents.
Les outils de migration font migrer tous les ports. Les outils journalisent un avertissement de conflit de port si un port est déjà défini dans la configuration. Vous devez résoudre tous les conflits de port avant de pouvoir exécuter les serveurs simultanément.
si le paramètre -portBlock est spécifié dans la commande WBIPostUpgrade, une nouvelle valeur de port est attribuée à chaque serveur d'applications migré.
Pour davantage d'informations sur la commande WBIPostUpgrade, voir Utilitaire de ligne de commande WBIPostUpgrade.
Pour davantage d'informations sur les chaînes de transport et les canaux, voir Chaînes de transport.
Vous devez ajouter manuellement les entrées d'alias d'hôte virtuel pour chaque port. Pour davantage d'informations, voir Configuration d'hôtes virtuels.
Le niveau de spécification de J2EE (Java 2 Platform, Enterprise Edition) mis en oeuvre dans WebSphere ESB version 6.0.x ou 6.1.x a nécessité des changements de comportement dans le conteneur Web pour définir le type de contenu. Si un programme d'écriture de servlet par défaut ne définit pas le type de contenu, non seulement le conteneur Web ne l'utilise plus comme valeur par défaut mais retourne en outre l'appel comme étant "null." Cette situation peut amener certains navigateurs à afficher incorrectement les balises de conteneur Web. Pour contourner ce problème, la migration définit l'extension IBM® autoResponseEncoding comme étant vraie pour que les modules Web, à mesure que les applications d'entreprise sont migrées.