This post kicks off a four-part series of blogs dedicated to Oracle Forms and Reports Modernization. If your company still uses Forms applications, is looking to modernize them, but have not yet found a realistic and reliable solution, then this blog series will be well worth your time.
Forms and Reports Modernization is doable
Forms modernization doesn’t have to be a huge all-at-once undertaking. There are ways to start off small, with a modest budget and timetable and expand from there. Best of all, there is an Oracle technology available now that can make Forms modernization achievable within a reasonable timetable, no matter how many Forms applications you are running.
In this series, we’ll identify the issues with Forms that are holding many companies back in their modernization plans. We’ll then introduce you to Oracle Application Express, a Rapid Application Development platform, we’ll have a detailed look at how Oracle Forms and Oracle APEX work and explain why APEX characteristics make it ideally suited to Oracle Forms and Reports Modernization. Finally, we’ll look at simple and advanced Forms/APEX integrations.
A unique predicament
If your company currently uses Oracle Forms Applications, it is probably facing a unique predicament. On one hand, your Forms apps are likely well-maintained by experienced developers. Forms users are efficient with its features. Data-entry and maintenance is a snap even if the look and feel of its applications are from a bygone era.
On the other hand, the rest of the company likely uses browser-based applications. Much more intuitive, they provide the flow and features that everyone expects from a browser-based experience.
Your company may be able to put up with this incompatibility, but for how long? The growing under-the-hood difference between Forms and current development software is leading many companies to look for an alternative. To understand the cost of keeping forms applications as-is in your system, let’s look at some of the challenges it presents to developers.
Challenges from a Development Standpoint
Forms challenges developers in several ways. When running it within a web-browser, developers must strictly control the browser version and parameters. Not an easy task as browsers are often updated. But, even when updated to its latest compatible version and aligned with a proper browser version, Forms’ performance often falls well below an average user’s expectations. Forms predates web-based technology and simply doesn’t have the page-to-page flow and logic of web applications. When it comes to Web services or Mobile applications, Forms is that much more complicated to develop.
Forms often paired with its brother, a reporting tool called Reports. Compared to later Oracle reporting tools and other data analysis products, it is also getting old. In Reports, adding a view on your data basically means building a new report. This lack of dynamic reporting capability is now almost unheard of.
Why so complex? Oracle Forms was originally based on client-server technology. Although Oracle continues Forms support, its client-server characteristics continue to be an obstacle to efficiency and cost savings. For example, Jinitiator is the Java virtual machine that allows Forms client applications to run inside web browsers. Developers must install Jinitiator on each client computer. Likewise, each developer needs development software installed directly on his computer or alternatively, on a Virtual Machine (VM) somewhere in the cloud, before starting their development work. Then, for deployment, the developer must generate executable files and move them into a centralized production environment. Unlike most software today, it isn’t a matter of developing an application and then making it accessible or downloadable from the web. Developer instances are treated individually during upgrades or patches.
All this represents a big chunk of a developer’s time and increasing costs as the company grows. And, we are not even talking about the complex software and infrastructure required on the web servers to run Oracle Forms on a company’s environments.
Holding back Oracle Forms and Reports Modernization
These significant technical limitations are part of the reason many companies using Forms applications are not connecting them to the web or to web services or even updating them (Yikes!). Without a doubt, they are missing out on what web technologies have to offer.
Another important reason why companies hesitate to move away from Forms is the perception that the undertaking would be massive, drawn-out and expensive. As mentioned earlier, some companies have hundreds of Forms, each with their own particularities. To open and rewrite every one of them would surely be too difficult.
PL/SQL vs Java
This perception may have a lot to do with Oracle’s move from PL/SQL-based programming (which is at the heart of Forms) and Java-based programming. Java object-based programming was brought in to move towards connection to and use of the world wide web for Oracle products in the early 2000s. The move was judicious but Java-based development technology is recognized as complex, particularly for PL/SQL Forms developers. In fact, it is another paradigm altogether.
Over the years, Oracle has proposed a couple of Java-based replacement solutions for Forms users, including a development platform called ADF. It didn’t catch on too well with Forms developers. For a more detailed explanation, see our blog called “Simplified, Cost Effective Development In EBS – Think Oracle APEX”
But Java wasn’t the only complication in the Forms story. Forms and Reports were also included in Oracle’s “CASE tool” based information system generator called Oracle Designer 2000. Designer is a top to bottom business system generation tool. It includes business process modeling, systems analysis modeling, systems design and application development. Forms development in this system contains automation. The resulting Forms applications have several times more code than a manually generated Forms application. What’s more, changing a Form produced with this system means going back to the very beginning of the modeling process. Not many developers still use it.
Web-based development eventually superseded systems like this and Designer 2000 is now de-supported by Oracle. Unfortunately, it leaves companies that developed Forms this way with the additional burden of dealing with that all that extra code if they wish to modernize or migrate away from their Forms applications.
APEX for Oracle Forms and Reports Modernization
Businesses need to know there’s a solution that addresses all these issues. Oracle Application Express (APEX), a Rapid Application Development platform, is firmly rooted in web technology and yet shares many similarities with Forms, not the least of which is that it is PL/SQL based.
Today, thanks to a well-thought-out development plan that includes extensive web-service support and ease of use, as well as continuing (I would even say growing) Oracle support, APEX is now the very best alternative for Oracle Forms and Reports Modernization.
In my next installment, I’ll get into the details about the surprising parallels between Forms and Oracle APEX.