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 siempre implica migrar un perfil individual a otro perfil individual en el mismo servidor IBM i. Las herramientas de migración correlacionan objetos y atributos existentes en la versión o WebSphere Application Server desde donde está realizando la migración a los objetos y atributos correspondientes del entorno de la Versión 9.0.
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.
Sin embargo, si el parámetro -setPorts se establece en generateNew o un valor de puerto durante la llamada a WASPostUpgrade, el valor de puerto se asigna a cada servidor de aplicaciones que se migra a 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.
Existen varias técnicas que puede utilizar para definir diferentes niveles de seguridad de Java 2 en la Versión 9.0. Una consiste en crear una archivo was.policy como parte de la aplicación para habilitar todos los permisos de seguridad. Las herramientas de migración llaman al mandato wsadmin para añadir un archivo was.policy existente en el directorio properties de la Versión 9.0 a las aplicaciones de empresa a medida que se migran.
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.
La ubicación de estos directorios es generalmente el directorio logs bajo el directorio de perfil de WebSphere Application Server. Para WebSphere Application Server Versión 9.0, la ubicación predeterminada para los archivos stdin, stdout y stderr es el directorio logs ubicado en el directorio de perfil de WebSphere Application Server; por ejemplo, el directorio logs para el perfil predeterminado es /QIBM/UserData/WebSphere/AppServer/V80/Base/profiles/default/logs.
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.
Avoid trouble: En un caso de ejemplo de coexistencia, la utilización de directorios comunes entre versiones puede ocasionar problemas.gotcha
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.