The short answer is don’t.

A lot of organisations are wanting to modernise their Forms applications and give them a more modern look and feel. That is all well and good but you ought to view it as a “conversion” as opposed to a “migration.

A Forms application is a client server application. APEX is a web application. They are not the same and are not developed in the same way

The fundamental difference is that Forms retains a persistent and distinct database session. APEX, since it is a web application does not do this. When a page in APEX needs to retrieve data from a table, it use a pool of connections to make the connection to the database. As soon as the data is retrieved, the page no longer has a direct connection to the database. It has returned the connection to the shared pool to make it available to other processes.

Likewise, after a user has updated values and they are ready to be sent to the database, APEX grabs a connection from the pool, performs the update returns it to the pool. More about this later.

You should not try and take a screen from Forms and replicate it in APEX. The representation of the Forms screen in APEX may actually be represented as one or more pages   Instead you need to identify the business process be represented by the Forms screen and replicate that in your APEX app.

The components used on a Forms will not end up being the same components in APEX application. That is exactly what you wanted. You wanted a more modern look and feel to your application.

Typically a Forms screen will contain a lot of business logic within triggers and program units. We will want to move that business logic to the database where it can be more efficient and can handle new logic requirements.

A properly built APEX application, unlike Forms, will not directly access a table. Instead it will make use of views and APIs that you will create in the database. This way your application is simply a thin layer presenting the business logic to the user rather than performing it.

There are some things in Forms that you will not try and replicate in APEX. For instance cross application validations and would be especially hard to replicate.  Validations and post query logic just don’t make sense in an APEX application.

If you have a very large Forms application that has expanded over the years, I would strongly recommend that the APEX application not become equally unwieldy. You may want to think about dividing the application into smaller modules in APEX that can be easily managed.

For your users, working with an APEX screen will be quite different than in Forms. Generally they will be comfortable with the web page as they deal with web pages all the time. However, an agile approach here may be very useful. In you can release something as a small chunk you can start to respond to user feedback and use that for guidance in developing future pages. You will likely build user enthusiasm for the project.

Designing the APEX application upfront is absolutely critical. You need to think about the business logic coming from the Forms and consider how and where it will exist in the APEX application

It is best to start with a relatively small form for the conversion. Pick a form that is simple and that represents the main business need being addressed by the application. This will establish some of the mayor components that will exist in the APEX application.

Move the form’s program units and other form logic into the database as packages and procedures. Some of references will need to be changed where they reference specific items on form. Try and group the logic into specific functions and code those as individual packages. Make things as reusable as possible This will be a continual process throughout the conversion project. Sometimes a horizontal development approach can be helpful here. One or two of your developers can work on the packages in the database and respond to the requirements of the other members of the project team.

You may actually not want to convert all of your forms to APEX. Sometimes the pure data entry screens used in back office processes can better be handled by Forms. Using strict keyboard actions to enter data is much easier in Forms as opposed to a web application. Forms is not going anywhere soon, and some things are just better handled in Forms.

Depending on the size of your Forms applications the conversion to APEX is not a quick and simple process. As an organisation you need to be committed to the timeline and to doing things the right way. Quick and dirty just does not work here and your project will surely be a failure if you try and do this. How long will it take? It depends on how much careful planning you do up front.

You need to keep consistency across all of the APEX pages. In many ways Forms did this for you. But in APEX you need to make sure that your developers do certain things the same way. Users ought to be able to understand where to find controls on each page. In other words the buttons and their labels should be in the same position of every page. Creating a UI plan that all developers follow can achieve this. There is another article in this series that can help you understand this better.

While creating a page in Apex is much faster than in Forms, your developers need to work as a close team and need to be managed by a very strong AAPEX lead. In the beginning it may be best to bring in an APEX consultant to fulfil this role so that things get established correctly and later your developers will have the knowledge to do this themselves.                                                                                                                

There is no quick way to move your Forms application into Apex. There are a few tools that try and do this but most of them just try and convert all screen elements into their counterparts in Apex. It is not an approach that will result in a fully functional web application.

If your Forms application has been around for a while, there are likely screens that are no longer used. Try and identify these screens and eliminate them from the conversion project. This way your Apex application will truly reflect the current business requirements.

Go slow. Seek business feedback. Create modules rather than one big application. Don’t try and convert everything at once. And, most importantly remember that you are building a web application rather than a client server application. Commit to the project and commit to build the application the right way.

Pin It

Contact Us

Please let us know your name.
Please let us know your email address.
Invalid Input
Please write a subject for your message.
Please let us know your message.
Invalid Input

Contact Us

Our Address

AppLinks (Pty) Limited
20 Wildebees Street
Alberton, South Africa
+27 (0) 11 902 3688
+27 (0) 83 276 3315