About a year ago I designed and developed a “JDAPI-toolbox” while migrating a medium sized (ca. 600 modules) Oracle Forms 6i application to webforms 10g for a customer in The Netherlands. I started the migration project using the Oracle Forms Migration Assistant. I found out that the tool only covered a small part of the migration problems I was facing so I wrote my own “toolbox” using the JDAPI frame-work in Java. The JDAPI-frame-work is part of the Oracle Development Suite 9i and higher and is a Java API build upon the C-API used to develop Forms modules without using the Forms Developer IDE. The API is also used by Designer to generate Forms modules.
My toolbox covers advanced search, and optionally replace, functionality (search for deprecated build-in’s or replace case); detachment and reattachment of libraries in the proper hierarchial order and with the proper case; creation of compile scripts to compile the application on the server; change of item/block/forms-properties to comfort little changes in look and feel between client/server and webforms; a wrapper over the migration assistant; reporting facillities (csv and xml/html) and even a tool to build in the really cool FJTable designed by Francois Degrelle. More info about my JDAPI-toolbox can be found in the paper I wrote for ODTUG 2005, titled Practical JDAPI.
Today I am again facing another migration project for another customer. On this project I have to analyse the future problems the application is giving the developmetn team while migrating to webforms and how much it will cost to rewrite deprecated build-ins, user-exits and OLE2 stuff, maybe incorporating webutil for these. I was a little sceptic about using my old toolbox wondering if it still would work on my new development environment: I moved from the original Development Suite 9i to a Dev. Suite 10.1.2. and to a newer JDeveloper (JDeveloper is used to start the toolbox), and more important the current application is totally different from the original one. But I was amazed to see that it still worked like a charm!
In fact the only things that had to be adapted were both the toolbox-property and the FORMS_PATH environment variable to point them to the Forms application sources and made sure I had a proper defined output directory to save all reporting files and that’s all. Within 15 minutes I managed to create a fairly complete impact analyses report of deprecated build-in’s, user-exits and OLE2 stuff of the whole application.
To give you an image of the generated report, see the sample below. The report (DHTML) gets it input from Apache’s Log4j (hence the INFO
level), in XML format. The log4j-XML is then included in an XSQL file
with can be browsed from any web browser.
Now, seeing all those OLE2 and text_io build-in’s, I guess there is enough work to do for the development team rewriting this with webutil.