Como migrar proyectos OSB de un ambiente a otro.

¿Qué tal?

Hoy hablaré de un tema muy importante para el desarrollo de proyectos OSB, y es referente a la migración de nuestros desarrollos a otros ambientes y las opciones que tenemos para ejecutar los cambios de ubicación de los recursos. Típicamente usamos ambientes de desarrollo, pruebas, preproducción y producción, dado que las ubicaciones de los servicios y recursos que usamos cambian entre cada uno, debemos ser muy cuidadosos al migrar de ambiente ya que con frecuencia nos pasa que olvidamos modificar todas las referencias y con esto vienen los problemas inmediatos.

Existen varias formas para realizar esta tarea, algunas más rápidas y simples que otras, sin embargo la elección de cómo hacerlo lo determinará la complejidad de los proyectos y nuestra propia experiencia. Es obvio que entre más servicios y recursos utilicemos, más cambios son requeridos y mayor la cantidad de trabajo a realizar, así como la posibilidad de equivocarnos si lo hacemos de forma manual.

Antes de comenzar con las opciones, empecemos con la generación del jar de los proyectos involucrados del ambiente A para importarlos al ambiente B.

1. En la consola de administración del OSB del ambiente A exportamos un proyecto. En la sección System Administration se encuentra la opción Export Resources, seleccionamos el proyecto deseado y después Export.

 
2. Esto debe descargar el archivo jar, por default se llama sbconfig.jar. Salvar dicho archivo en una carpeta en el explorador y verificar que haya finalizado exitosamente.

3. En la consola de administración del ambiente B importamos el archivo. En la sección System Administration se encuentra la opción Import Resources, creamos una sesión, seleccionamos el jar del paso anterior y damos clic en Next.

4. Seleccionamos los proyectos a importar y la opción Import.

 
5. Una vez completada la importación, activar los cambios con el botón Activate y después Submit.

Ahora que ya tenemos el proyecto importado en el ambiente B, los elementos que lo conforman hacen referencia a recursos ubicados en determinados lugares y es necesario modificarlos para redireccionar a las correspondientes al ambiente. A continuación explicaré 4 formas de llevar a cabo esta tarea.

1. Modificación Manual.

   La forma más rústica quizás de hacerlo es modificar manualmente cada endpoint de los recursos, es decir, si tenemos un proyecto pequeño en el cual hay pocas referencias, es fácil editar un Business Service.
  
   i. En nuestro ejemplo, editamos el servicio EjemploBS ubicado en Proyect Explorer, MiEjemplo, BusinessServices. Este proyecto es muy simple y contiene un Proxy Service que redirecciona hacia un Business Service, que a su vez envuelve un servicio BPEL de hola mundo.

  ii. Damos clic en el servicio EjemploBS, creamos una sesión y habilitamos la edición del endpoint con el ícono Edit justo a la altura de la sección Transport Configuration.

 

 iii. En la siguiente pantalla, nuevamente usamos el ícono Edit para poder modificar en la sección Endpoint URI, la nueva ubicación. Una vez modificada damos clic en Update y Last.

  iv. En la pantalla de resumen verificamos que el endpoint es el que deseamos y damos clic en Save, activamos los cambios y damos Submit. El cambio estará aplicado.

2. Modificación por Búsqueda y Reemplazo.

   Esta forma de realizar las modificaciones es similar a la anterior, con la diferencia de que es un poco más rápido y eficiente, si tenemos varios recursos que actualizar y conocemos bien sus ubicaciones.

   i. En el mismo ejemplo anterior, localizamos la sección System Administration, Find & Replace, creamos una sesión para poder reemplezar los valores, si no la creamos solo podremos realizar la búsqueda.

  ii. Introducimos el valor de la ubicación a modificar y realizamos la búsqueda, se muestran opciones para filtrar los resultados, al final del ejemplo está la tabla con todas las opciones que se proveen.

 iii. Cuando se obtiene el resultado de la búsqueda, introducimos el nuevo valor de la ubicación y damos clic en Replace All, finalmente Activate y Submit.

  iv. Verificamos que el cambio se haya aplicado de forma correcta al abrir el servicio EjemploBS en Proyect Explorer, MiEjemplo, Business Service y revisar el valor del Endpoint URI.

3. Modificación por Archivos de Personalización.

   Esta forma de actualizar los cambios es un poco más compleja, sin embargo provee un mecanismo semi automatizado, que es conveniente si la cantidad de proyectos y recursos a modificar es considerable, reduciendo la posibilidad de errores y el tiempo de implementación.

   i. El primer paso es generar el archivo de personalización, en el ambiente B una vez que realizamos la importación del jar con el proyecto, ir a la sección System Administration, Create Customization File, seleccionar el proyecto o los recursos deseados y Create File.

  ii. Guardar el archivo en sistema, por default se llama ALSBCustomizationFile.xml.

 iii. Abrir el archivo para su edición, localizar el Business Service EjemploBS y cambiar las ubicaciones del url por la nueva.

  iv. En la consola de administración del OSB, ir a la opción System Administration, Execute Customization File, seleccionar el archivo modificado y Next.

 

   v. Verificar el resumen de las modificaciones que se realizarán y seleccionar Execute.

  vi. Si la ejecución fue satisfactoria, activar los cambios.

 vii. Para validar que se realizó la tarea, ir al servicio EjemploBS y verificar que el Endpoint URI sea el correcto.



4. Modificación usando WLST(Weblogic Scripting Tool) y Scripts de Ant.

   Por último veremos la forma más compleja pero completamente automatizada de realizar los cambios. Consiste en un conjunto de archivos, entre ellos scripts de Jython(WLST), scripts de Ant, archivos xml y properties, entre otros. La estructura es la siguiente:
  
   * Import.py: Es el script WLST que contiene la secuencia de pasos a seguir para la importación de un proyecto y aplicación de un archivo de personalización.
   * build.xml: Es el scrit Ant que ejecuta a import.py.
   * ALSBCustomizationFile.xml: Archivo de personalización de proyectos OSB, lo pueden generar usando los pasos i, ii y iii del tema anterior, Modificación por Archivos.
   * ant.properties: Archivo de propiedades para la configuración de las ubicaciones de los scripts.
   * import.properties: Archivo de propiedaddes para la configuración de las ubicaciones del admin server, archivos del projecto, archivo de personalización y de los archivos config y key.
   * configfile.secure y keyfile.secure: Sirven para establecer la conexión con el servidor WebLogic usando comandos WLST, almacenan las credenciales encriptadas y el key para descifrarlas.
  
   La idea es tener una estructura de carpetas para cada ambiente, desarrollo, pruebas, preproducción y producción, con sus correspondientes archivos de configuración y scripts. En mi caso yo estoy usando la ruta C:\osb y la carpeta dev para el ambiente de desarrollo. Para ejecutar el ejemplo, es necesario descargar el proyecto de ejemplo, la liga se encuentra al final de este post, y ejecutar los siguientes pasos:

   i. Descomprimir el archivo, de preferencia en C, para no tener que modificar otros archivos, y editar los archivos import.properties e import.cmd, cambiando las rutas de su servidor.

 
   ii. Generar los archivos configfile.secure y keyfile.secure. Abrir una ventana de cmd e introducir los siguientes comandos(cambiando la ubicación de su instalación):
  
      CALL c:/Oracle/OracleHome11115/Middleware/wlserver_10.3/server/bin/setWLSEnv.cmd"

      java weblogic.WLST

      connect(url='t3://localhost:7001')

     ii. Introducir usuario y password de administrador Weblogic y ejecutar la siguiente línea. Al final se habrán generado los dos archivos.
 
      storeUserConfig('configfile.secure','keyfile.secure')

 iii. Copiar los archivos configfile.secure y keyfile.secure recien generados, ubicados generalemente en "C:\Documents and Settings\username", a la ruta C:\osb\build\dev para sobreescribir los que vienen como ejemplo.

  iv. Ejecutar el archivo import.cmd ubicado en C:\osb\build\dev, para comenzar el proceso. Si queremos ver el resultado de la ejecución, abrir el archivo desde una ventana de cmd.

   v. Verificar el resultado de la operación en la consola de administración.

Cualquiera que sea el método que usemos, es importante mantener control sobre los accesos de quien realiza estas actividades en ambientes controlados y es recomendable siempre hacer un respaldo del jar del proyecto antes de realizar las modificaciones.

Espero que éstas opciones sean de utilidad.

 
¡Hasta la próxima!

Descargar archivos y scripts WLST


Sandy
Compartamos para trascender.