Migacion forms apex

Migración de Oracle Forms a APEX
Daniel Bozzolo
Daniel.bozzolo@logos.com.uy
APEX TOUR 2012
5,7 y 8 de Noviembre de 2012

Agenda
• Entendiendo el Proyecto
• Entendiendo la Funcionalidad
• Preparación de la Conversión
• Creación del Proyecto de Conversión de
Forms
• Generación de la Aplicación
• Revisando y adecuando la Aplicación
• Reportes
– Generación de PDF

Entendiendo el Proyecto
• Razones para la conversión
– Funcionales
• Para comprender por qué hacemos este proyecto de
conversión, tendremos que investigar los problemas,
dificultades o restricciones no deseadas que los
usuarios están teniendo con la aplicación actual.
• De esta forma, seremos capaces de comprender cómo
la nueva aplicación debe funcionar después de la
conversión, cómo debe lucir, y que es lo que tiene que
hacer.

• Debemos hacernos una serie de preguntas
– La aplicación convertida debe ser accedida desde
fuera de la empresa?
– Debe ser integrada con otras aplicaciones web?
– Debe ser utilizada por nuevos usuarios?
– Se necesita alguna funcionalidad que forms no
provee?

• Otra de las razones funcionales para la
conversión es el layout, y esta podría ser una
de las más importantes. Esto es porque
cuando usamos APEX, podemos usar el diseño
gráfico que la empresa utiliza para su sitio web
o sitio de intranet e integrarlo completamente
a la aplicación.

• Razones para la conversión
– Técnicas
• La conversión es realizada para recortar costos
operativos?
• Se quiere modernizar el ambiente y look and feel?
• Se quiere tener aplicaciones completamente basadas
en browsers?

Entendiendo la Funcionalidad
• Debemos conocer que hace la aplicación y por
qué
• Debemos conocer un diseño funcional que ha
sido escrito durante la creación de la
aplicación.
• Debemos utilizarla para saber que es lo que
hace.
• Debemos tener una mirada más profunda en
la aplicación y en el proceso de negocio.

• Se debe utilizar la aplicación con un usuario
experto que permita la comprensión de ésta.
• Se deben aprender los procesos del negocio,
como los usuarios trabajan, los roles que
cumplen y por que hace uso el usuario de la
aplicación durante su trabajo

• La interacción del usuario en la aplicación original es
esencial para la construcción de la nueva aplicación
• Diferencias grandes entre Forms y APEX
– En Forms los usuarios están acostumbrados a interactuar
con los datos en forma muy rápida, incluso la validación es
al instante
– En APEX para lograrlo se debe utilizar JAVASCRIPT y
AJAX(Dynamic Actions , plug-ins)
• Conocer los diferentes roles y procesos de negocio y
que roles deben ser asociados a que procesos

• Componentes de un proyecto en Developer
Suite
– Forms
– Reports
– Menues
– Libraries (pll, objects)
• Hacer lista de los componentes
• Conocer la funcionalidad de éstos

• Arquitectura
– Debemos conocer la arquitectura de la aplicación
– Donde está la lógica?
• En el forms mismo
• En la BD
– No es lo mismo convertir un form que tiene muchísimo
plsql en sus bibliotecas o en sus triggers que aquel que
llama store procedures.
– Es bueno conocer lo que hace cada parte de la aplicación,
para eso utilizamos Forms y Reports Builder.

• Alguna lógica será difícil de convertir y deberá ser reescrita en
el proyecto de convesión
• También habrá partes no convertibles, por ejemplo algunas
pantallas de form, las cuales deberemos hacer nosotros
mismos.
• A estas partes se les hará un seguimiento durante el proyecto
• La mayoría de esas partes serán las Canvases, Windows,
Visual Attributes y otras componentes de Forms que no
estarán en la conversión porque APEX no las puede usar
• Cuando encontramos estos elementos debemos ajustar el
look and feel en el propio APEX

Preparación de la Conversión
• Debemos estar seguros que no existen más
desarrollos en algún otro componente que los
que seleccionamos para la conversión
• Colocar todos los últimos fuentes en un
directorio seguro

• Necesitamos los siguientes archivos para la
conversión
» Forms Modules: extensión FMB
» Object Libraries: extensión OLB
» Forms Menus: extensión MMB
» PL/SQL Libraries: extensión PLL
» Report Files: extensiones RDF, REX, o JSP

• Creación de archivos XML
– Requiere de tres componentes del Developer
Suite
• Forms Builder
• Reports Builder
• Forms2xml
– frmf2xml [option] file [file]
– Si hay imágenes en los módulos creará las imágenes en
archivos TIF

• Creación de archivos XML (Forms2xml)
– Los archivos XML serán creados y almacenados en
el mismo directorio desde el cual llamamos el
comando
– Los nombres asociados serán
» formname.fmb formname_fmb.xml
» libraryname.olb libraryname_olb.xml
» menuname.mmb menuname_mmb.xml

• Conversión de Archivos de Reportes

• Conversión de PLSQL Libraries
– Se realiza con el rwconverter

EL FORMS XML POR DENTRO

EL MENU XML POR DENTRO

EL REPORT XML
POR DENTRO

EL PLD
POR DENTRO

El siguiente paso es crear el schema y migrar toda la información
a el nuevo schema asociado a APEX
• Export de Oracle
• Export de herramientas de terceros
• Generación de scripts y ejecución desde sqlplus,
herramientas de 3eros o desde el mismo APEX

Creación del Proyecto de Conversión de Forms

• Definición de la Aplicación

•Creación del Proyecto

Seleccionamos el primer módulo

Levantamos el resto de los módulos

• Creación del Proyecto
Una vez cargados los módulos

• Aplicabilidad, indica cuando un objeto será o no
parte de nuestro proyecto

• Theme

• En la página del proyecto veremos los diferentes
componentes y su estado de completitud
• Los componentes más importantes serán resaltados
y veremos la posibilidad de hacerles cambios
• Las anotaciones serán utilizadas para setear el
estatus de completitud y la asignación a
desarrolladores. Son utilizadas para darnos una idea
de las tareas pendientes.
Planificando el Proyecto

La página de proyecto
Dentro de orders ….

Orders

Triggers
• Son quizá la parte más compleja de la conversión
• Debemos utilizar mucho tiempo investigandolos
• La lógica del trigger puede ser incorporada a APEX como una
computation,validation o proceso plsql en la fase de
posgeneración
• El post-query puede ser incorporado como parte de la
generación del Enhanced Query

Triggers

Para examinar el Trigger
debemos editarlo

LOVS, serán convertidas en forma automática

Alerts, pueden ser almacenadas como mensajes de texto
En la Shared Component

Anotaciones de las componentes
Es una de las más importantes piezas de control

• La página del proyecto nos ayuda diciendo acerca de la cantidad de componentes y
la realización de las diferentes partes.
• La pantalla de detalles de Forms nos dice qué hacer con ciertos componentes
dándonos consejos en los detalles de implementación.
• La pantalla de detalles nos dice cuántas partes de los componentes hay y
cuál es su situación.
• Los detalles de los componentes nos da en los resúmenes de todos los
componentes que tenemos en un Módulo.
• En la pantalla de detalles de los componentes específicos, podemos echar un vistazo
al fuente y hacer los cambios en la anotación de este componente.
• Las anotaciones nos da algunas herramientas para el control de la página.
Podemos hacer o deshacer la aplicabilidad de un componente y asignar un componente
a alguien en nuestro equipo.

Obteniendo la Lógica Correcta
Data Blocks
• Los bloques de construcción de nuestras páginas APEX son los bloques y,
por supuesto, los reportes
• Los bloques que se generan son los basados en tablas
• La forma en que los bloques se generarán se determina por APEX
en función del contenido, el número de elementos en el bloque, y,
lo más importante, el número de registros que aparecen.

Block Items

Original vs Enhanced Query

Triggers, la mayoría necesita ser implementados
En la pos-generación

Triggers, otros en la pre-generación

Revisando y Adecuando la Aplicación
Validaciones

FORMS y APEX
Oracle Forms Oracle APEX
Alerts Text messages en la Shared Components y/o Validaciones
a nivel de la Aplicación o la Página.
Blocks Blocks serán generados como Regiones en APEX.
Canvases Son ignoradas en APEX durante la conversión.
Editors Editor HTML.
Lists of Values El record group asociado será incluído en la conversión.
Una lista de Valores puede ser desarrollada después de la
generación
Program Units Program Units deben ser implementados luego de la
generación como elementos PL/SQL.
Triggers En APEX no se conoce este elemento. Sin embargo hay
algunas cosas que pueden implementarse tales como Post-
Query Triggers

Reportes
• Estandar
• Interactivos
• Generación de planillas
• Impresión de PDF, RTF, XLS…

Impresión PDF
• APEX requiere un print server externo
• EL motor de APEX genera los datos del reporte
en XML y un template en XSL-FO o RTF

Soluciones
• Apache FOP
–Solo PDF (herramienta de diseño de
templates WYSIWYG FO-Designer)
• Apache Cocoon (Carl Backstrom)
–Agrega RTF
• Apache Cocoon (Robert Stefanov)
–Agrega XML, XLS y HTML
• Oracle BI Publisher
–Diseño en MS Word

Soluciones
• Soluciones basadas en URL
–Oracle Reports
–Crystal Reports
–Jasper Reports
• Integración con Jasper Reports (Dietmar
Aust) (Diseñando con iReports)
–URL
–Utilizando la BD como proxy (via UTL_HTTP)
solución más segura
–Generando un blob

Referencias
• Oracle Application Express Forms Converter
A migration guide using the APEX conversion
utility
Douwe Pieter van den Bos

Referencias
• http://carlback.blogspot.com.br/2007/03/ape
x-cocoon-pdf-and-more.html
• http://www.java4less.com/fopdesigner/fodesi
gner.php?info=apex
• http://rste.blogspot.com.br/2008/07/excel-
export-from-apex-cocoon.html
• http://www.opal-
consulting.de/tools/jasper_integration

Migacion forms apex

Más contenido relacionado

La actualidad más candente

Similar a Migacion forms apex

Último

Migacion forms apex