En este post trataremos de exponer algunos escenarios posibles al tratar de evolucionar aplicaciones empresariales desarrolladas en Oracle Forms.

Veremos los diferentes frameworks o soluciones que pueden aparecer y cómo podemos reutilizar parte de la lógica PL/SQL que ya tenemos publicándola mediante una capa REST.

Introducción

Oracle Forms cuenta con un nivel de implantación muy alto a nivel mundial y durante muchos años ha sido el software por excelencia, por parte de Oracle, para crear aplicativos back-office o de gestión interna.

En la actualidad la última release de Forms 12c, cuenta con mejoras importantes tanto a nivel de integración como de despliegue. Algunas de estas características ya las comentamos en un post anterior.

Aunque nuestro back-office Forms siga siendo funcional puede que no cubra algunas de las nuevas necesidades de algún departamento o que estemos pensando en modernizar parte o todo del mismo.

En mi opinión, cuando estamos ante un proyecto de modernización de back-office es importante analizar las causas, los motivos que nos presentan la necesidad de hacer cambios en aplicativos que son parte central,core, de la empresa.

En este sentido las causas podrán ser diversas, desde buscar mayores facilidades de integración con terceros, renovación de UX, temas de movilidad, Integración Continua, QA, orientación a servicios, dirección/decisión tecnológica de empresa, etc. Pero en cualquier caso es muy importante tratar de buscar una solución tecnológica que sea satisfactoria a todos los niveles de empresa tanto para negocio, IT, como para los usuarios finales.

Este último grupo, los usuarios, es muy importante, ya que normalmente las soluciones actuales de "migradores mágicos" suelen olvidarse de este ultimo punto y ofrecen al usuario exactamente lo mismo que tenía antes pero en otra tecnología. No hay prácticamente mejora en el día a día de los usuarios.

Por eso vale la pena invertir tiempo en modelar y diseñar los nuevos módulos y no basarse tanto en lo que ya existe, ya que seguramente serán diseños que cubrían una funcionalidad y forma de trabajar de hace muchos años atrás y que no esta alineada con la realidad actual de la empresa.

A continuación podemos ver una imagen de lo que podría ser un back-office desarrollado con ADF, siguiendo RDK o patrones de Alta UI.

Antes de continuar analizando los diferentes escenarios o soluciones que podemos tener en cuenta para una evolución del back-office Oracle Forms, es importante destacar que cada proyecto, empresa y equipo de desarrollo tiene su propias necesidades y realidades, por lo que para cada caso se debería estudiar cual es la mejor solución. No existen soluciones mágicas y generalistas.

A continuación trataré de aportar algunas pautas a considerar.

Una idea seríaa dividir nuestro aplicativo Forms en base a la funcionalidad que cubre. Una división, dicho de antemano muy generalista, de nuestro back-office Forms podría ser el siguiente:

1. Módulos que son puro mantenimiento de datos.
2. Módulos con una fuerte orientación a Interfaz de Usuario o Procesos (o que no lo son y nos gustaría que lo fuesen).
3. Módulos que requieren movilidad.

Para cada uno de estos módulos podríamos apostar por soluciones distintas. Generando un proyecto de evolución hibrida, varios framework o tecnologías conviviendo y formando un back-office, donde teniendo en cuenta la clasificación anterior:

1. Podríamos apostar por APEX o sencillamente dejar ciertos módulos en FORMS, ya que en esos casos seguramente se cubren las necesidades y no se presentan carencias.
2. Esta sería la parte que seguramente tendría más volumen y aquí un framework como ADF nos puede ayudar mucho a orientar nuestras pantallas a procesos y ofreciendo una nueva usabilidad y funcionalidades gracias a su extensa paleta de componentes y su flexibilidad.
3. En el caso de la movilidad podríamos apostar por Oracle JET, toolkit open source modular basado en JavaScript, CSS3 y HTML5

A continuación podemos ver una imagen de un escenario completo donde se combinan varios frameworks y además se añade Oracle ORDS como herramienta para reutilizar, de una forma rápida y sencilla, nuestras reglas de negocio SQL y PL/SQL vía REST.

Respecto al punto 2 es importante hacer un buen análisis a nivel de usabilidad y tener un conocimiento amplio del framework ADF y sus componentes ya que generalmente en escenarios de tipo back-office se suele hacer un uso masivo de componentes comunes como inputs, outputs, botones, combos de selección, tablas, etc. Pero se dejan de lado componentes más modernos como podrían ser el sunburst o el timeLine:

Otro de los puntos fuertes del ecosistema presentado en este post es el nexo común a nivel de componentes entre ADF y JET, ya que tendremos a nuestra disposición una paleta común, incluyendo componentes tan complejos como el Diagrama de Gantt:

Aquí podéis ver, en acción, toda la paleta de componentes de JET y sus diferentes comportamientos en distintos dispositivos.

Otro factor importante es el número de integrantes del equipo de IT, que se encarga del desarrollo y mantenimiento del back-office y sus perfiles o experiencia en lenguajes de programación.

Olvidemos la bala de plata ...

No hay soluciones mágicas y en cada escenario y equipo de IT se deberá estudiar la mejor solución. Además no debemos olvidar que Oracle sigue evolucionando Forms y dando soporte, de forma que podríamos imaginar escenarios donde Forms tuviera mas presencia, o mas integración.

• Nota: Algunas capturas estan obtenidas de las demos online o las paginas de producto  de Oracle

En breve publicaremos una segunda parte explicando un caso práctico en detalle, ¡síguenos en Twitter para que podamos avisarte!