Correlación de las configuraciones durante la migración de configuraciones de producto
Durante la migración de las configuraciones del producto se correlacionan diferentes configuraciones.

En este artículo se describe la migración de la configuración de perfil. Para migrar sus aplicaciones a la versión más reciente, utilice WebSphere Application Server Migration Toolkit. Para obtener más información, consulte Migration Toolkit en WASdev.
sptcfgLa migración implica la copia de la configuración de un release anterior de WebSphere Application Server en un nuevo release.
Existen muchos escenarios de migración posibles. Las herramientas de migración correlacionan objetos y atributos existentes en la versión o en la versión desde la que está realizando la migración con los objetos y atributos correspondientes del entorno de la Versión 9.0.
Las herramientas de migración transportan el valor de release anterior al entorno de la Versión 9.0.
Las herramientas de migración convierten los parámetros de línea de mandatos apropiados en valores JVM (Java™ Virtual Machine) en la definición de proceso de servidor. La mayoría de valores se correlacionan directamente. Algunos valores no se migran porque sus roles en la configuración de WebSphere Application Server Versión 9.0 no existen, tienen significados diferentes o tienen ámbitos diferentes.
Para obtener información sobre cómo cambiar los valores de definición de proceso, consulte Valores de definición de proceso. Para obtener información sobre cómo cambiar los valores de JVM, consulte Valores de la máquina virtual Java.
- En Versión 7.0 o posterior, un servidor genérico tiene su propio tipo, denominado GENERIC_SERVER. La migración realizará esta conversión, pero la migración no puede migrar con precisión los recursos externos a los que hace referencia el servidor genérico. Cuando la migración termine de migrar los valores del servidor genérico, es posible que deba realizar tareas adicionales. Si el recurso antiguo que estaba gestionando el servidor genérico está en la instalación anterior de WebSphere Application Server, realice las siguientes tareas:
Si el recurso antiguo que el servidor genérico estaba gestionando no está instalado bajo la instalación antigua de WebSphere Application Server, no es necesario realizar nada más.
Puede migrar un nodo de WebSphere Application Server Versión 7.0 o posterior que pertenece a una célula sin eliminar el nodo de la célula.
Migre primero el gestor de despliegue antes de migrar los nodos base de la célula.
Importante: Utilice el mismo nombre de célula cuando migre WebSphere Application Server, Network Deployment de Versión 7.0 o posterior a Versión 9.0. Si utiliza otro nombre de célula, los nodos federados no se migrarán correctamente a la célula de WebSphere Application Server, Network Deployment Versión 9.0.Al hacer la migración de un nodo de WebSphere Application Server base que está dentro de una célula a la Versión 9.0 también se migrará el agente de nodo a la Versión 9.0. Una célula puede tener algunos nodos de la Versión 9.0 y otros nodos que estén en los niveles de la Versión 7.0 o posterior.
- WebSphere Application Server Versión 9.0 migra todos los archivos de políticas que se han instalado con Versión 7.0 o posterior fusionando los valores en los archivos de políticas de la Versión 9.0 con las características siguientes:
La migración copia archivos de los directorios de versiones anteriores en la configuración de la Versión 9.0 de WebSphere Application Server.
La WebSphere Application Server Versión 9.0 migra todos los archivos de propiedades que se han instalado con Versión 7.0 o posterior fusionando los valores en los archivos de propiedades de la Versión 9.0.
Los RAR a los que se hace referencia en los recursos J2C se migran si esos RAR están en la instalación antigua de WebSphere Application Server. En este caso, los RAR se copian en la ubicación correspondiente en la nueva instalación de WebSphere Application Server. Los RAR del adaptador de recursos relacional no se migrarán.
Migración de recursos a nivel de clúster:La versión 6.0 de WebSphere Application Server introducía el concepto de recursos de nivel de clúster. Estos se configuran en los archivos recursoxxx.xml bajo los directorios de clúster. Por ejemplo:<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar"> ... </resources.j2c:J2CResourceAdapter>
Si tiene un recurso de nivel de clúster, este recurso debe estar en la misma ubicación de cada miembro de clúster (nodo). Por lo tanto, utilizando el ejemplo anterior, cada miembro de clúster debe tener el archivo RAR instalado en la ubicación ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} se resuelve en cada miembro del clúster para obtener la ubicación exacta.
En la migración de un gestor de despliegue, las herramientas migran los archivos de clúster del gestor de despliegue, incluidos los archivos recursoxxx.xml.
En la migración de un nodo federado, las herramientas procesan cada adaptador J2C.
Migración de los archivos RAR de una versión 7.0 a la Versión 9.0:
La migración de la versión 7.0 a la Versión 9.0 copia los archivos como RAR desde WAS_INSTALL_ROOT a WAS_INSTALL_ROOT y desde USER_INSTALL_ROOT a USER_INSTALL_ROOT.
Por ejemplo, si tiene un archivo RAR en la variable WAS_INSTALL_ROOT de la versión 7.0, las herramientas de migración no copian el archivo automáticamente de WAS_INSTALL_ROOT a USER_INSTALL_ROOT. Esto mantiene la integridad de los recursos J2C de nivel de clúster.
No obstante, si ha codificado una vía de acceso en un archivo RAR (por ejemplo, archivePath="C:/WAS/installedConnectors/x2.rar") de la versión 7.0, las herramientas de migración de la Versión 9.0 no pueden modificar el atributo archivePath para reflejarlo, ya que esto rompería todos los demás miembros de clúster que no se han migrado.No hay disponible ninguna migración de los ejemplos de versiones anteriores. Existen ejemplos equivalentes de la Versión 9.0 de WebSphere Application Server que se pueden instalar.
La seguridad de Java 2 se habilita de forma predeterminada cuando se habilita la seguridad en la Versión 9.0 de WebSphere Application Server. La seguridad de Java 2 requiere que los permisos se otorguen de manera explícita.
Al migrar a WebSphere Application Server Versión 9.0, la opción de si desea o no migrar para dar soporte a la compatibilidad de scripts da un resultado de los dos diferentes.Para obtener más información sobre cómo migrar las configuraciones de seguridad a la Versión 9.0, lea el artículo "Migración, coexistencia e interoperatividad – Consideraciones sobre seguridad" en la documentación.
En WebSphere Application Server para z/OS, las salidas para stdin, stdout y stderr se dirigen a SYSOUT de forma predeterminada. Si se redirigen al directorio de configuración de una versión anterior, es posible que necesite modificar esto en el JCL de la Versión 9.0.
Las herramientas de migración intentan migrar los directorios de desactivación y de trabajo existentes. De lo contrario, se utilizan los valores predeterminados correspondientes de la Versión 9.0.
Si los ID de usuario de WebSphere Application Server para z/OS tienen directorios iniciales en el directorio de configuración de una versión anterior, deberá actualizarlos antes de migración para que residan en otra ubicación.
Avoid trouble: En un caso de ejemplo de coexistencia, la utilización de directorios comunes entre versiones puede ocasionar problemas.gotcha
Las herramientas de migración migran todos los puertos. Debe resolver cualquier conflicto de puerto antes de que pueda ejecutar servidores a la vez.
Nota: Si ya se han definido puertos en una configuración que se está migrando, las herramientas de migración arreglan los conflictos de puerto en la configuración de la Versión 9.0 y anotan cronológicamente los cambios para que el usuario los verifique.Debe añadir manualmente entradas de alias de host virtual para cada puerto. Para obtener más información, lea el artículo "Configuración de hosts virtuales" en la documentación.
El nivel de especificación de Java Platform, Enterprise Edition (Java EE) implementado en WebSphere Application Server Versión 7.0 requería cambios de comportamiento en el contenedor web para establecer el tipo de contenido. Si un grabador de servlets por omisión no establece el tipo de contenido, el contenedor web no sólo deja de tomar ese valor predeterminado, sino que devuelve la llamada como "nula". Esta situación puede hacer que algunos navegadores muestren incorrectamente los distintivos de contenedor web resultantes. Para evitar que se produzca este problema, la migración establece la extensión autoResponseEncoding de IBM® en "true" para los módulos web cuando migra aplicaciones de empresa.