Oracle Forms and Oracle Application Express (APEX) are both technologies used to build data centric applications.
APEX uses the best of the modern web to create native web applications. Oracle Forms uses NPAPI plugins relying on Java technologies to render the page. Whilst we could go on and on describing the advantages of one over the other and believe us, there are strong opinions on both sides. We, as APEX enthusiasts, acknowledge that whilst many a Forms-to-APEX redevelopment project can be a trouble-free experience – there are some Oracle Forms features that makes the redevelopment a bit sticky.
Many of these thorny features are due to browser security vs. a standalone client-server application and some are just old-school features which don’t have an easy equivalent in a web application.
Let’s start with a list of Webutil features which cause a problem within APEX. The vast majority of Webutil features are going to be difficult to overcome in APEX. If you’ve never heard of Webutil, it’s an Oracle Forms Library that was built to provide access to modules which typically interact with the clients PC e.g. file system, environment variables, etc. If you try to think of any web page which tries to move files around, start programs or read information about the client PC well… that sounds a little scary, but luckily due to browser security we are protected. It’s that same browser security which prevents an APEX page from leaping outside of the browser performing those undesirable actions.
Let’s look at our list…
Once again, due to browser security, we are unable to run a host command from a web application, and some Oracle Forms needed it to run simple Microsoft windows apps like a calculator or even execute .bat files as part of their functionality.
Typically functionality includes, creating a folder on the clients HDD, checking if it exists and creating files in that folder. It’s not uncommon to have this functionality within an Oracle Forms application, and would definitely not be the norm within a web page.
We can easily authenticate on an APEX application using Active Directory however the browser cannot easily detect the user currently logged to the OS (without some trickery). The username and other client data are not accessible from the browser.
Within Oracle Forms, you can easily read and write images on the client side without any user interaction.
This feature enables Oracle Forms to open a local copy of Word/Excel on the clients machine, get and set values, and provides many other features including saving and printing. For the same reasons above, your web browser will restrict any OLE2 attempts from APEX; however a typical workaround involves moving that code to the Database and have the Database Server interact with local copies of Word/Excel. (Its not recommended)
In Addition to WebUtil there are some general challenges when comparing a standalone client side application (Forms) to a Web Browser one (APEX).
This takes a picture of your Oracle Form and sends it to the printer; whilst attempting the same in APEX (or any web page) would send a responsive A4 layout version to the printer.
You can probably run java from your apex application, but you need to do additional work to make it work properly. In Oracle Forms this is straightforward with a java beans area.
In Oracle Forms your items are placed at precise x / y coordinates; in APEX/Rest of the web, the layouts are responsive to the screen size and orientation – this is simplified for the APEX developer by using Universal Theme. Even if you can set the height and weight of items in the browser, it can differ between different browsers.
On Forms you can open another form (or even the same form) without closing the previous one.
You probably do not need the mouse to work on a form screen, this makes the user experience quite agile, when you move to a web application you lose the ability create shortcuts using function keys as these are reserved for the browser itself.
From our experience, this is the most challenging thing to replicate in an APEX environment. Some Oracle Form applications, post the data to make it available through different forms or use it to fire some database trigger validations.
With TEXT_IO I can create a file and save it to a local folder. In a web environment, this automatic integration becomes very complicated.
Given the above list, it’s necessary to select the best approach either to replicate that tricky functionality or identify alternatives. There is no simple rule and it is a case of adapting each thorny issue as you encounter them;
A Dynamic Action could be a good or a bad choice to replicate an Oracle Forms Trigger. An Interactive Grid could replace the multi-row data block or you could be in for a world of trouble. There is no tool that takes an Oracle Form and magically creates an APEX page. The approach varies from Form to Form – sometimes two Forms can become one APEX page, and one Form can become many APEX pages.
Absolutely APEX is the best choice to redevelop your legacy Oracle Forms application. Developers can re-apply their SQL & PL/SQL skills to APEX development – making the leap easier. The larger the forms application, the larger the project… naturally. Those thorny issues may cause you to scratch your head; but it’s unlikely that an alternative cannot be found. APEX continues to be the best option for the future direction of your forms application.
Author: Rodrigo Mesquita
Job Title: Oracle APEX Development Consultant
Bio: Rodrigo is an Oracle ACE and APEX Developer Expert certified by Oracle and is an experienced software engineer with emphasis in analysis, design and development of bespoke Oracle applications utilising development tools such as PL/SQL, APEX and Forms for a variety of international businesses. Rodrigo speaks regularly at Oracle community events and enjoys creating APEX plugins and writing blogs.