Guia de Migración de Módulos
Autor: Javier Pérez Villamizar
Compañia: SET SOFTWARE S.A.S.
Nota:el presente articulo es una traducción del articulo original escrito por Redhuan D. Oon
Un Plan de Migración Para Desarrolladores
¿Por qué Migrar?
Es ampliamente conocido por todos aquellos que estan vinculados a la industria del software, que el principal dolor de cabeza es la gestión de actualizaciónes, de corrección de bugs y de versiones del codigo fuente. Entre mas cambios haya realizado el usuario al codigo fuente de la aplicación o al modelo de configuración de la misma, existe una mayor probabilidad de que se presenten conflictos con las actualizaciones o correcciones realizadas por la casa matriz del software o de la comunidad que este soportando la aplicación. Un ERP puede convertirse facilmente en un mostruo de muchas cabezas, debido a su complejidad y creciente tamaño; es por esa razón que es buena idea tener un nucleo común de la aplicación para la mayoria de los usuarios y que aquellos que necesiten realizar cambios o agregar funcionalidad puedan hacerlo a través del desarrollo de nuevos módulos o como es el caso de IDempiere de modulos encapsulados en Plugins.
El desafio es entonces migrar de manera consistente y segura evitando "romper" la funcionalidad existente. La figura 2 ilustra la labor que deben realizar los usuarios que actualmente utilizan un Sistema A (como ADempiere 3.6) y desean utilizar en el futuro el Sistema B (como Idempiere),que incluye grandes mejoras de arquitectura y mayor funcionalidad; sin emabargo la labor mas delicada es migrar al sistema B, todos los cambios y personalizaciones que el usuario a realizado al Sistema A.
¿Que Migrar?
Las siguientes preguntas que se presentan son:
-¿Qué migrar?-
-¿Se trata solo de codigo?-
La respuesta es si y no. En las aplicaciones basadas en Compiere, como los son ADempiere e IDempiere, los cambios pueden ser tanto codigo como datos. Estos datos son "Metadatos" que permiten configurar el Diccionario de la Aplicación, lo que determina el look and feel, y el modelo de configuración, incluyendo este ultimo elementos como Menús, ventanas, Tablas, Pestañas, Procesos y otras caracteristicas que aunque no estan "quemadas" (Hard Coded) en el codigo fuente, si estan almacenas en la base de datos de manera separada en un formato determinado.
Si miramos con detenimiento el diagrama anterior y tenemos presente lo que acabamos de exponer, entonces cobra sentido el hecho de que esten resaltadas con rojo las palabras AD y CODE.
AD es la sigla de Diccionario de Aplicación, que representa los metadatos mencionados antes. Lo que la figura anterior ilustra es entoces que para migrar a IDempiere los metadatos son enviados a traves de 2Pack y el codigo fuente es enviado como un nuevo plugin desarrollado con la herramienta para el desarrollo de plugins (PDE) de Eclipse.
¿Como realizar la Migración?
El siguiente paso es completar la migración de los metadatos y del codigo de manera exitosa. Tal como lo mencionamos anteriormente, la primera parte la realizamos utilizando 2Pack, que exporta en un archivo ZIP (2pack.zip), que contiene toda la descripción de los cambios realizados al AD en formato XML. La segunda parte consiste entonces en formatear los paquetes JAVA de acuerdo a la estructura de Plugin de Eclipse. Mas adelante veremos con mas detalle cada uno de estos pasos, por ahora examinando la Figura 3 podemos ver de manera clara el proceso de migración del AD a traves de las cajas señaladas por la flecha roja. En otras figuras que presentaremos mas adelante examinaremos en detalle el proceso de migración de codigo, por ahora los representamos solo con la caja de contonrno rojo que dice "Eclipse".
En la figura 3 presentamos tambien nuevos terminos, por un lado podemos ver en el Sistema A de la Izquierda que el codigo anterior Java esta envuelto en el antiguo estilo en la Maquina Virtual Java (JVM) que es una especia de contenedor cerrado que no permite ninguna forma de acceso al mismo. Por otro lado vemos en el lado derecho el Sistema B tiene un Contenedor OSGI que permite "Conectar" nueva funcionalidad al mismo a traves de Plugins Eclipse y ademas permite acceder y monitorear los mismos a traves de Comandos 'SS'.
En el nuevo sistema tambien podemos ver una relacion entre Plugins determinada por el archivo MANIFEST, que se encuentra en la carpeta META-INF.En ese archivo MANIFEST tambien esta descrito su propio "Activador" que detecta automaticamente cualquier archivo 2pack.zip en la carpeta y ejecuta el "Pack In" a la base de datos de la aplicación.
De aqui en adelante veremos como realizar el proceso de un modulo personalizado, ademas en los siguientes enlaces podremos ver los videos (en Ingles) del proceso que detallaremos a continuación:
Pack Out del Modulo
Desarrollo del Plugin en Eclipse
Pack In del Modulo como Plugin
Ademas presentamos la figura 4 en la cual introducimos los elementos sobre los cuales seguiremos analizando mas adelante.
1. El módulo del Plugin.
2. El activador del Plugin llamado en el archivo MANIFEST.
3. El archivo MANIFEST.
4. El codigo "quemado" que llama el archivo 2Pack.zip en la carpeta META-INF.
Migración de un Módulo
A continuación analizaremos un ejemplo de un modulo real de ADempiere el cual migraremos a IDempiere como plugin. Para nuestro ejemplo usaremos el modulo de integración de OpenBravo POS y ADempiere ERP que fue un trabajo que desarrollamos y publicamos el año pasado. Para ese módulo creamos un Menú llamado Integración POS, el cual contiene 3 tres sub items que son 2 procesos llamados Exportar Cola e Importar Cola de Ordenes y una ventana llamada Procesar Ordenes Importadas.
Los Items anteriores no hacen parte de la version estandar de ADempiere o IDempiere, aunque existen diferentes formas en las cuales esos cambios se pueden incorporar a IDempiere. Una de esas formas es a traves del Log de Migración que se guardo cuando la customización se realizó. Otra forma de hacerlo es usando la herramienta 2Pack que ha estado disponible por algunos años en ADempiere. De todas formas es necesario tener en cuenta que Low Heng Sin realizó considerables mejoras al 2Pack de IDempiere asi que no es necesariamente igual a su antigua versión por lo que para usar el Pack In de IDempiere es necesario usar el Pack Out de IDempiere. Como estamos utilizando IDempiere v1.0 usaremos los scripts que se encuetran en el siguiente link
https://sourceforge.net/p/red1/small/101/tree/trunk/POSIntegration/migration/
En el enlace anterior encontrará un listado de scripts SQL como lo ilustra la figura anterior. Lo siguiente es el codigo fuente del modulo, se puede obtener los Scripts de migración, el archivo 2pack.zip y el software de OpenBravoPOS que se utilizará, aunque es importante anotar que en el presente documento nos centraremos solo en el codigo de customización que estamos migrando. En el siguiente enlace podrá descargar el producto completo para usar
http://sourceforge.net/projects/red1/files/Software%20Packages/IntegratedPOSplugin.zip/download
Lanzando IDempiere
Si esta usando ambiente Windows puede instalar IDempiere de forma sencilla en un computador o notebook que no tenga instalado JAVA ni POSTGRES utilizando el Instalador, si lo necesita puede ver la guia escrita de como utilizar el instalador en conjunto con el asistente de actualización. Si esta usando un ambiente diferente a Windows puede ver las instruciones de como desplegar IDempiere en http://wiki.idempiere.org.
Una vez que IDempiere este corriendo, estará listo para aplicar los scripts de migracion y hacer el Pack Out para obtener el archivo 2pack.zip del nuevo plugin. Si necesita ayuda adicional con los scripts de migración puede ir nuestra ayuda en linea. Veamos ahora como realizar el proceso de Pack Out. Para realizar este proceso con sus propias customizaciones es importante asegurarse de que tengan un grupo de menú como es el caso de esta integracion con OpenBravo POS.
