Mappage de configuration pendant la migration produit-configuration

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

Configurations prises en charge :

Cette rubrique concerne la migration de la configuration de profil. Pour mettre à jour vos applications vers la dernière version, utilisez l' WebSphere® Application Server Migration Toolkit.

La migration implique toujours la migration d'un seul profil vers un autre profil sur le même serveur IBM i. Les outils de migration mappent les objets et les attributs existant dans la version ou l' WebSphere Application Server e à partir de laquelle vous effectuez la migration vers les objets et attributs correspondants dans l'environnement de la version 9.0.

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 effectuez la migration vers les objets et attributs correspondants dans l'environnement de la version 9.0

Port d'amorçage

Les outils de migration transfèrent l'ancienne valeur de version vers l'environnement Version 9.0.

Si le -setPorts paramètre est défini sur generateNew ou sur une valeur de port lors de l'appel à WASPostUpgrade, la valeur de port est toutefois transmise à chaque serveur d'applications migré vers la version 9.0.

Paramètres de lancement

Les outils de migration convertissent les paramètres de ligne de commande appropriés en paramètres de la machine virtuelle Java™ ( JVM ) dans la définition du processus serveur. La plupart des paramètres sont mappés directement. Certains paramètres ne sont pas transférés car leurs rôles dans la configuration d' WebSphere Application Server, version 9.0, n'existent pas, ont une signification différente ou ont une portée différente.

Pour savoir comment modifier les paramètres de définition de processus, consultez la section « Paramètres de définition de processus ». Pour savoir comment modifier les paramètres de la machine virtuelle Java ( JVM ), consultez la section « Paramètres de la machine virtuelle Java ».

Serveur générique

Dans la version 7.0 ou ultérieure, 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 gérée par le serveur générique se trouve dans l'ancienne installation d' WebSphere Application Server, procédez comme suit :

Copiez tous les fichiers connexes vers la nouvelle installation.
Exécutez toutes les configurations nécessaires pour rétablir l'état opérationnel de l'application externe.
Il est préférable de réinstaller la ressource dans le nouveau WebSphere Application Server répertoire. Quelle que soit votre décision, l'étape finale consiste à réinitialiser la référence vers le nouvel emplacement de l'application.

Si l'ancienne ressource gérée par le serveur générique n'est pas installée sous l'ancienne WebSphere Application Server installation, aucune autre action n'est nécessaire.

Migration d'un nœud de version 7.0 ou ultérieure vers un nœud de version 9.0

Vous pouvez migrer un nœud d' WebSphere Application Server, version 7.0 ou ultérieure, appartenant à une cellule sans avoir à le retirer de celle-ci.

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 lors de la migration d' WebSphere Application Server Network Deployment, de la version 7.0 ou ultérieure vers la version 9.0. Si vous utilisez un nom de cellule différent, les nœuds fédérés ne pourront pas migrer correctement vers la cellule « WebSphere Application Server Network Deployment Version 9.0 ».

La migration d'un nœud de base WebSphere Application Server situé au sein d'une cellule vers la version 9.0 entraîne également la migration de l'agent du nœud vers la version 9.0. Une cellule peut comporter certains nœuds de version 9.0 et d'autres nœuds dont la version est 7.0 ou une version ultérieure.

Fichiers de stratégie

WebSphere Application Server La version 9.0 migre tous les fichiers de stratégie installés avec la version 7.0 ou une version ultérieure en fusionnant les paramètres dans les fichiers de stratégie de la version 9.0 présentant les caractéristiques suivantes :

Tous les commentaires figurant dans les fichiers de politique de la version 9.0 seront conservés. Les commentaires figurant dans les fichiers de stratégie de version 7.0 ou ultérieure ne seront pas inclus dans le fichier de version 9.0.
La migration ne fusionne pas les droits ou permissions ; il s'agit d'une migration de type add. Si l'autorisation ou la concession ne figure pas dans le fichier Version 9.0, la migration la transférera.
La sécurité est un élément essentiel; c'est pourquoi la migration ajoute tout élément à la fin des fichiers .policy d'origine, après le commentaireMIGR0372I: Migrated grant permissions follow. Cela permet aux administrateurs de vérifier les modifications apportées aux fichiers de stratégie lors de la migration.

Répertoires de propriétés et de classes

La migration copie les fichiers des répertoires des versions précédentes vers la configuration WebSphere Application Server Version 9.0.

Fichiers de propriétés

WebSphere Application Server La version 9.0 migre tous les fichiers de propriétés installés avec la version 7.0 ou une version ultérieure en fusionnant les paramètres dans les fichiers de propriétés de la version 9.0.

Fichier RAR (Resource adapter archives) référencé par des ressources J2C

Les fichiers RAR référencés par les ressources d' J2C s sont migrés s'ils se trouvent dans l'ancienne WebSphere Application Server installation. Dans ce cas, les fichiers RAR sont copiés à l'emplacement correspondant dans la nouvelle WebSphere Application Server installation. Les fichiers RAR de l'adaptateur de ressources relationnelles ne sont pas migrés.

Migration des ressources au niveau du cluster :

WebSphere Application Server La version 6.0 a introduit le concept de ressources au niveau du cluster. Ces dernières sont configurées dans les fichiers resourcexxx.xml dans les répertoires du cluster. Par 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.

Fichiers RAR lors d'une migration de la version 7.0 vers la version 9.0 :

La migration de la version 7.0 vers la version 9.0 copie les fichiers, tels que les fichiers RAR, du répertoire WAS_INSTALL_ROOT vers WAS_INSTALL_ROOT et du répertoire 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.

Si vous avez défini en dur un chemin d'accès à 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 toutefois pas modifier l'attribut archivePath pour refléter cette modification, car cela perturberait le fonctionnement de tous les autres membres du cluster qui n'ont pas encore été migrés.

Exemples

La migration des exemples des versions précédentes n'est pas disponible. Il existe des exemples équivalents pour la version WebSphere Application Server et la version 9.0 que vous pouvez installer.

Sécurité

La sécurité Java 2 est activée par défaut lorsque vous activez la sécurité dans la version 9.0 d' WebSphere Application Server. La sécurité Java 2 exige que vous octroyiez des droits de sécurité de manière explicite.

Il existe plusieurs techniques permettant de 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 migration exécutent la wsadmin commande pour ajouter un fichier was.policy existant du répertoire properties Version 9.0 aux applications d'entreprise au fur et à mesure de leur migration.

Lors de la migration vers la version 9.0 d' WebSphere Application Server, le fait de choisir ou non de migrer en conservant la compatibilité des scripts entraîne l'un des deux résultats suivants.

Si vous choisissez de migrer vers la compatibilité avec les scripts de support, votre configuration de sécurité est transférée vers la version 9.0 sans aucune modification.
Il s'agit de la valeur par défaut.
Si vous choisissez de ne pas migrer pour prendre en charge la compatibilité des scripts, la configuration de sécurité est convertie en la configuration par défaut pour WebSphere Application Server Version 9.0. La configuration de sécurité par défaut de la version 7.0 ou ultérieure fonctionne presque de la même manière que dans les versions précédentes, mais quelques modifications ont été apportées.
Par exemple, les fichiers tiers de clés et les fichiers dignes de confiance existants sont déplacés hors du répertoire SSLConfig et de nouveaux objets fichier de clés et fichier de clés certifiées sont créés.

Pour plus d'informations sur la migration de vos configurations de sécurité vers la version 9.0, consultez l'article « Migration, coexistence et interopérabilité – Considérations relatives à la sécurité » dans la documentation.

Stdin, stdout, stderr, répertoires de passivation et de travail

Ces répertoires se trouvent généralement dans le logs répertoire situé sous le répertoire de profil WebSphere Application Server. Pour la version 9.0 d' WebSphere Application Server, l'emplacement par défaut des fichiers stdin, stdout stderr , et est le logs répertoire situé dans le répertoire de profil WebSphere Application Server — par exemple, le répertoire des journaux pour le profil par défaut est /QIBM/UserData/WebSphere/AppServer/V80/Base/profiles/default/logs.

Les outils de migration tentent de migrer les répertoires de passivation et de travail. Dans le cas contraire, les valeurs par défaut de l' 9.0 de version sont utilisées.

Évitez les problèmes : dans un scénario de coexistence, l'utilisation de répertoires communs entre les versions peut créer des problèmes.

Modules Web

Le niveau de spécification de l'interface « Java Platform, Enterprise Edition » ( Java EE ), implémentée dans la version 7.0 d' WebSphere Application Server, a nécessité des modifications du comportement du conteneur Web pour la définition du 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. Pour éviter ce problème, la migration définit l'extension autoResponseEncoding IBM® sur « true » pour les modules Web lors de la migration des applications d'entreprise.