Este documento presenta una guía para migrar aplicaciones Oracle Forms a Oracle Application Express (APEX). Explica los pasos para entender el proyecto y la funcionalidad de la aplicación Forms existente, preparar la conversión creando archivos XML, generar el proyecto de conversión en APEX, revisar y adecuar la aplicación APEX resultante, e implementar informes y generación de PDF.

1. 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

2. 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

3. Entendiendo el Proyecto

4. 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.

5. Entendiendo el Proyecto
• 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?

6. Entendiendo el Proyecto
• 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.

7. Entendiendo el Proyecto
• 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?

8. 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.

9. Entendiendo la Funcionalidad
• 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

10. Entendiendo la Funcionalidad
• 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

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

12. Entendiendo la Funcionalidad
• 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.

13. Entendiendo la Funcionalidad
• 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

14. 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

15. Preparación de la Conversión
• 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

16. Preparación de la Conversión
• 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

17. Preparación de la Conversión
• 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

18. Preparación de la Conversión
• Conversión de Archivos de Reportes

19. Preparación de la Conversión
• Conversión de PLSQL Libraries
– Se realiza con el rwconverter

20. Preparación de la Conversión
• Conversión de PLSQL Libraries
– Se realiza con el rwconverter

21. Preparación de la Conversión

22. Preparación de la Conversión
EL FORMS XML POR DENTRO

23. Preparación de la Conversión
EL FORMS XML POR DENTRO

24. Preparación de la Conversión
EL MENU XML POR DENTRO

25. Preparación de la Conversión
EL REPORT XML
POR DENTRO

26. Preparación de la Conversión
EL PLD
POR DENTRO

27. Preparación de la Conversión
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

28. Creación del Proyecto de Conversión de Forms

29. Creación del Proyecto de Conversión de Forms
• Definición de la Aplicación

30. Creación del Proyecto de Conversión de Forms
•Creación del Proyecto

31. Creación del Proyecto de Conversión de Forms
•Creación del Proyecto
Seleccionamos el primer módulo

32. Creación del Proyecto de Conversión de Forms
•Creación del Proyecto
Levantamos el resto de los módulos

33. Creación del Proyecto de Conversión de Forms
• Creación del Proyecto
Una vez cargados los módulos

34. Creación del Proyecto de Conversión de Forms
• Aplicabilidad, indica cuando un objeto será o no
parte de nuestro proyecto

35. Creación del Proyecto de Conversión de Forms
• Aplicabilidad, indica cuando un objeto será o no
parte de nuestro proyecto

36. • Theme
Creación del Proyecto de Conversión de Forms

37. • 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

38. Planificando el Proyecto
La página de proyecto
Dentro de orders ….

39. Planificando el Proyecto
Orders

40. Planificando el Proyecto
Orders

41. Planificando el Proyecto
Orders

42. Planificando el Proyecto
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

43. Planificando el Proyecto
Triggers

44. Planificando el Proyecto
Para examinar el Trigger
debemos editarlo

45. Planificando el Proyecto
LOVS, serán convertidas en forma automática

46. Planificando el Proyecto
Alerts, pueden ser almacenadas como mensajes de texto
En la Shared Component

47. Planificando el Proyecto
Anotaciones de las componentes
Es una de las más importantes piezas de control

48. Planificando el Proyecto
• 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.

49. 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.

50. Obteniendo la Lógica Correcta
Block Items

51. Obteniendo la Lógica Correcta
Block Items

52. Obteniendo la Lógica Correcta
Original vs Enhanced Query

53. Obteniendo la Lógica Correcta
Triggers, la mayoría necesita ser implementados
En la pos-generación

54. Obteniendo la Lógica Correcta
Triggers, otros en la pre-generación

69. Revisando y Adecuando la Aplicación
Validaciones

70. Revisando y Adecuando la Aplicación
Validaciones

71. Revisando y Adecuando la Aplicación
Validaciones

72. 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

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

74. 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

75. 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

76. 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

77. Preguntas????

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

79. 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