Skip navigation

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…

Running the Host command: 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.

Manipulate client side files: 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.

Read information from the client machine (Tool_Env): 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.

Read and write client side images: Within Oracle Forms, you can easily read and write images on the client side without any user interaction.

Integrate with client side OLE2 (e.g. Word and Excel): 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).

Print Screen: 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.

Java Beans: 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.

Pixel Perfect Positioning: 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.

Multiple Forms Open in the same Run-Time: On Forms you can open another form (or even the same form) without closing the previous one.

Function Keys: 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.

POST: 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.

Text_IO: 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.

Conclusion: 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.

APEX uses the best of the modern web to create native web applications; unfortunately, this also brings modern vulnerabilities that we always need to be aware of. To protect applications, APEX has a number of in-built security features available to prevent SQL Injection and Cross Site Scripting.

Often, important processes in our applications fire when a button is clicked. For UI reasons, if a process can’t be fired, or the users don’t have permission to do it, the button may become inactive or disabled. However, this is only HTML, if the application process is not safe, someone with a minor knowledge of HTML can revert this button back to life and boom! Fire you process!

Let’s first see what is behind a disabled button; if we inspect this button using the chrome console (right click on the button and select “inspect”), something similar to the code below will show.

<div class="t-ButtonRegion-buttons">



   <button onclick="apex.confirm('Are you sure you want to place this order?','PLACE_ORDER');"



   class="t-Button t-Button--hot lto6341306998453375987_0 apex_disabled" type="button" id="SAVE" disabled="">



   <span class="t-Button-label">Complete Order</span></button>





If we remove the property disabled=”” and the class apex_disabled, the button becomes active and clickable again.

So, should I hide the button?
In some cases, it could work, but if you have just an application process on the page that fires when you submit the page, someone can easily call it by using just the JavaScript below:



Therefore, what if I hide the button and add a Server-side Condition in the application process to only fire when the SAVE button is clicked?




Let’s look again to the button HTML”SAVE”, the condition: “only fire when the SAVE button is clicked” means the same as “request = ‘SAVE’”. The would-be hacker just needs to add the request to the JavaScript.



In the next scenario, there is a status item that I set to a value (OK) when the process can be called; can I check this item value before calling the application process? The malicious user may also know the JavaScript below.



We need also insure that each page has access protection, otherwise the hacker can set inject values in the URL.



Available options include:

  • Unrestricted

The page may be requested using a URL, with or without session state arguments, and without having to have a checksum. The URL below includes the RIR request and set the value 1 for the P4_ITEM.

  • Arguments Must Have Checksum

If Request, Clear Cache, or Name/Value Pair arguments appear in the URL, a checksum must also be provided. The URL below includes the RIR request, set the value 1 for the P4_ITEM and include a checksum.–yuRYH8f0RHF6Pcl0HJc1LpyJ6fCOkjAvBY3oeogIf we manually try to change the value, 1 to another one, the user will get the following error.Session state protection violation: This may be caused by manual alteration of a URL containing a checksum or by using a link with an incorrect or missing checksum. If you are unsure what caused this error, please contact the application administrator for assistance.

  • No Arguments Supported

A URL may be used to request the page, but the URL cannot contain Request, Clear Cache, or Name/Value Pair arguments.

  • No URL Access

The page may not be accessed using a URL.However, the page may be the target of a Branch to Page branch type, as this does not perform a URL redirect.Tips:

  1. Avoid by applying conditions to the application process that check page items.
  2. Create page validations to double check using the same rule that made the button disabled.
  3. Use APEX authorization schemes to validate page access. Even if a page is not available on the menu to a specific user, the user can set the page number in the page URL ( and go to the page if there is no authorization is selected. To create authorization schemes, go to Shared Components \ Authorization Schemes and then any that you create will be available in the page properties.




APEX is very safe and used by numerous military and classified agencies around the world, but like most web technologies, the developers needs to know and use the security resources in order to avoid breaches that could make the app vulnerable.