What’s in our (Oracle) Forms? October 27
Though this blog typically contains how-to’s and editorials and Java and ADF related topics, it is supported by my company, Vgo Software, and so I occasionally need to plug one of our products. This post is one of those, so read it at your own risk. However, if you are working in a company that works with Oracle Forms in addtion to Java or ADF, I encourage to read it, you may find it of use to you. If you have no idea what I’m talking about, feel free to skip it.
Many of our customers over the years have asked us that very question about their Oracle Forms applications. As a provider of tools and services to help customer modernize their forms applications we took the opportunity to develop a product that would help answer this question.
Forms is a 4GL developed by Oracle that has been around for many years. I first started working with Forms in version 3.0 about 15 years ago. At that time I was working in the IT department of a chain of supermarkets. All of their accumulated data was stored on a mainframe, of course, but each store had a couple systems running on IBM servers that ran an Oracle database and Oracle Forms. Part of my job consisted of making fixes and enhancements to those applications.
What I found, as did many others, was that Oracle Forms was a very easy way to create applications that were based on an Oracle database. As a developer I could create a Block based on a database table, provide some validation triggers and a couple of buttons, and voila!, a user could now input validated data into a table. Master-detail relationships were also simple to create. Interaction with other systems was more difficult and typically done via Oracle Pro*C programs run by shell scripts. One application I worked on synced data from a handheld device to the store’s database using a C program, that was probably one of the more interesting applications I worked on then.
As I moved on in my career, I lost touch with Forms, but came back to it many years later. In a later job, I was asked to research communicating with a Java server-side application from a Forms Client/Server application. If I remember correctly, the implementation included creating an Active-X control (or was it COM back then, I can’t remember?) that was embedded in the form and could make a call to an EJB on a Weblogic server.
Forms has come a long, long way since those 3.0 character-mode days, and even from those Client/Server days. As Oracle Forms has evolved, so have the applications that customers have created with them. Working in the business that I am now, modernizing forms applications, I have seen plenty of forms applications ranging from relatively simple applications that consisted mostly of Blocks based on tables, to incredibly complex applications that never tie a block directly to a table but instead us a Control Block to capture user input and then run some complex logic on it both in the form itself and on the database server through complex stored procedures and functions.
What we found when we first started out, was that everyone has their own idea of what is simple and what is complex. In order to deal with that and improve our ability to estimate the amount of work required to complete a project, we developed into our modernization tool a function that analyzed what we perceived to be the complexity of any given Oracle Form. As we did more of these projects we realized that there are many customers out there with Forms applications that have existed for so long and been developed by so many different people that they themselves have no idea of what those forms consist of.
Evo ART is a product that we started about a year ago. It is an Analysis and Reporting Tool for Oracle Forms applications. It is written in Java and so requires having a JRE verison 1.5 or higher installed. It helps those customers that are wondering what is inside their Forms applications. It has itself evolved from consisting of only a complexity analysis to providing many details about the application that would take a developer potential months to discover on their own.
From being able to see the dependencies within the form modules and their libraries, to the dependencies on database objects, ART is able to show all of that at a glance. If you are interested in upgrading from a Client/Server version of forms to a web version of forms, ART can show you where you are going to run into trouble in the guise of functions that aren’t going to be available anymore. If you are interested in modernizing to a completely new multi-tiered web architecture, ART can show you where you are going have problems finding equivalents and may require a re-design. Want to know how much of your code in your forms is redundant, ART can show you that, too. You’d be surprised how much cutting and pasting went on in those PL/SQL-based applications.
The other cool thing about ART, in my opinion, is that like our Evo tool, its output is customizable. Have a PLL-based function that you know you want to redesign and want to know what forms out of your 500 form application are calling it? A new report can be easily added to ART to show you that. Want to create a report that only shows which forms will be impacted by a certain table-change? ART can do that too.
So if you are one of those unfortunate enough to have inheritied a large Oracle Forms system and you are unsure of what it contains or how complex it is take a look at how ART may help you.
Sorry for the product plug, more informational posts will follow, I promise.
