Enmilocalfunciona

En este post trataremos un tema muy concreto como son las actualizaciones de entornos APEX. Pero, ¿qué es APEX?: lo podríamos resumir en una herramienta de desarrollo productivo de aplicaciones web sobre una base de datos Oracle.

En la propia web de la herramienta podremos ver de forma rápida qué podemos llegar a desarrollar con APEX. Pero si que es importante adelantar, que no solo es PL/SQL ya que desde hace bastante tiempo APEX esta evolucionando con un enfoque a REST, JavaScript, etc. muy claro.

APEX desde mi punto de vista, puede ser un claro acelerador o pieza a tener en cuenta en el engranaje de lo que seria un gran proyecto de migración Oracle Forms hacia arquitecturas y desarrollos mas actuales.

Uno de los puntos en los que primero destaca APEX es en su productividad. Pero es cierto que al no tener servidor de aplicaciones y tener gran parte de nuestras aplicaciones basadas en toda una serie de metadatos almacenados en la BBDD, una vez ya hemos desarrollado nuestra primera o primeras aplicaciones nos empiezan a surgir toda una serie de preguntas referentes a la migración y actualización de las aplicaciones:

• Pases entre los diferentes entornos que podamos tener Desarrollo, Test, Pre, Producción, etc.
• Posibles actualizaciones, ya que la actualmente se ha lanzado una nueva versión (18.1) con toda una serie de novedades importantes.

Con el objetivo de cubrir ambas preguntas, vamos a suponer que tenemos nuestra aplicación en un entorno con APEX 5.1 y queremos moverlo a un entorno distinto, donde además tendremos instalada la ultima versión de APEX,18.1.

Lo ideal será tener estos entornos dockerizados. Para entornos de pruebas o básicos es relativamente sencillo crearse un dockerfile con una instalación de APEX, basándose en alguna de las imágenes Docker oficiales de BBDD de Oracle.

Lo primero será exportar nuestra aplicación. Hay que tener en cuenta que el proceso debe tener en cuenta varias partes.

Exportación de la aplicación APEX

Dentro de nuestra aplicación, tenemos la opción Import/Export. En este caso, el proceso de exportación, es via GUI y muy sencillo:

Esto nos creara un fichero .sql que posteriormente podremos importar en nuestro entorno destino.

Exportación de los datos de BBDD de la aplicación

Por otro lado tenemos que hacer un export de la base de datos de la que hace uso la aplicación. Es decir, un export de la BBDD de la aplicación: tablas, vistas, procedimientos, secuencias, etc.

Exportación de ficheros estáticos

Deberemos hacer un export de todos aquellos ficheros externos que se han añadido en la aplicación como librerías JS, CSS, imágenes, etc. Estos se pueden descargar en formato zip, de manera conjunta.

Además, según el grado de personalización que tenga nuestra aplicación podremos tener cambios en plantillas, etc.

Proceso de importación

Una vez realizado el export. Tendremos que hacer el proceso de inverso de Import en nuestro entorno APEX destino:

Y cargar el/los scripts de BBDD, según el proceso realizado de export, del punto anterior (Exportación de ficheros estáticos).

Dependiendo del estado de la BBDD y si hacemos usos de ciertas llamadas a servicios, etc. es posible que también necesitemos adaptar los permisos vía ACL para el usuario APEX.

En este post hemos expuesto lo que sería el proceso básico y manual de exportación/importación de una aplicación APEX. Lo ideal sería que este proceso fuera lo más automatizado posible, para ello contamos con herramientas dentro de APEX como APEXExportSplitter y APEXExport que nos permitirán hacer una exportación vía línea de comandos y además dividir la exportación en ficheros.

Adicionalmente para la instalación podemos hacer uso de la API APEX_APPLICATION_INSTALL

También es importante destacar que cada aplicación tiene sus particularidades y puede hacer que los procesos sean más o menos complejos. De todos modos, si que es importante tener una separación los más clara posible entre lógica de negocio y la capa de presentación. Este enfoque hará que estos procesos sean siempre más sencillos.

Con las últimas versiones de APEX, con ORDS, su integración con JavaScript y lógicamente la capa de negocio que podemos tener en BDDD, esta diferenciación es cada vez más sencilla.

En posteriores posts trataremos de exponer alguna de las diversas opciones que tenemos en APEX para trabajar en equipo de manera gestionada con un sistema de control de versiones como podría ser Git. El objetivo será incluir nuestras aplicaciones APEX en nuestros circuitos de IC.