What to think about when you move from Oracle Forms to Oracle ADF?
Your Oracle Forms applications don’t just suddenly stop working. That means that if your applications run, you don’t need to update, right?
The implicit premise behind the above assumption is that everything else stays the same. And it doesn’t. If you are happy to run 10-year-old hardware with Windows XP, you’ll be correct that your Oracle Forms applications would still run. But since you are continually upgrading many other parts of the platform beneath your Forms applications (operation system, Java, browsers), you will eventually run into a situation where you have to consider the future of your Oracle Forms applications.
Additionally, your users are probably not impressed with the overloaded screens and the gray retro-nineties of your application.
You have three options:
- Pure version upgrade
You might decide to do a pure version upgrade. You’ll need to move to Forms 11gR2, because Forms 11gR1 runs out of premier support June 2015. If you are coming from 10g, you’ll have to start using the Oracle WebLogic application server. That’s a new skill to learn for your application server administrator, but if you are only running Oracle Forms, you only need to know very basic WebLogic.
For many, a good option is to modernize. You can give your Oracle Forms application a makeover using the same tricks you see in house makeover TV shows: Remove most of the furniture, and paint everything white. In Oracle Forms terms, this means creating some screens that are not crammed full of every field that every user could possibly need, changing the background to white, and replacing the gray standard buttons with graphical image buttons. This will improve the visual appearance of your Forms application dramatically. Finally, you can choose to migrate your Forms application to Oracle APEX, Oracle ADF or something else. The rest of this article is about migrating to Oracle ADF.
Manufacturing companies know that their machines will eventually be worn out and have to be replaced. Most IT organizations haven’t grasped this concept and just run projects with big budgets when implementing new systems. In these organizations, it always comes as a huge surprise to management when a ten or fifteen year old system has to be replaced.
Facing the reality that the organization has not saved up for a replacement (or even budgeted for it), we need to prove some business value in our migration project. A good way to harvest the low-hanging fruit and prove value to the business is this six-step process:
- New Application
- High Value Add
- Stepwise migration
After the Triage step, you know now many Forms you have to migrate. After the pushdown step, your application is ready for migration, but still works the same, and you know how many code elements you have to migrate.
During the Crimean war in 1853-56, army surgeons overwhelmed by the number of casualties coming into the field hospitals instituted a procedure known as “Triage.” The word is French and means to divide something into three sections or types.
After a battle, casualties will be divided into:
- The mortally wounded, who will die no matter what is done.
- The seriously wounded, who will die unless they are given immediate attention
- The lighter wounded, who will not die right away and whose injuries can wait
Army surgeons will focus on the middle category first: Those who need immediate attention.
Your Oracle Forms modules are not in danger of dying, but you are still faced with a big task and limited resources. Therefore, you should also perform a triage on your Forms modules. Divide them by business impact into:
- Not important
There are two ways to gather the data for this triage: A qualitative one and a quantitative one. The qualitative approach involves asking the users: “Which screens are most important to the task you do?” Make sure to ask a representation sample of actual users who have a login and work with the application. If your application is used by truck drivers, admin assistants and logistics planners, ask several members of each group.
Do not schedule any interviews with team leaders and managers. If they insist on providing input, that’s fine, but unless they are actually using the application, their input should not carry much weight in your triage.
The quantitative approach is driven by hard data: How many times are the individual Oracle Forms modules actually opened? If you don’t have this data, immediately start building a maintenance release with a PRE-FORM trigger in every module that logs every invocation to a database table. When you have this data, order your modules by usage. You will typically see a distribution like this:
Once you have both the qualitative and quantitative data, you can determine which Forms Modules are truly crucial to your users. These are the ones that you work on first, and the ones that receive complete test coverage.
Most organizations will initially claim that they do not have any Forms modules that are not important. They are wrong. Your qualitative analysis will show which modules are being invoked. In a typical application, between 20 and 30 percent of all Forms modules will be invoked zero times in a month, and many others only once or twice. Some Forms applications have grown over decades and contain many pieces of functionality that are no longer relevant to the business or that have been taken over by other systems.
All of these are candidates to be left out of the new application. Inspect each of these and ask the users to make sure that they do not have some seasonal meaning (“end-of-year close” or similar). If your users tell you they are crucial (but were just forgotten in the initial interview), move them to that category. If the user confirms that they are being used regularly, but they are not crucial, they go into the “important” category.
Sidebar: Do You Really Need to Maintain Reference Data?
I want to challenge the notion that you need a screen to maintain every reference data table in your application. Initially, you need some way of getting data into the application, but a modern database development tool like SQL Developer or Oracle APEX makes it trivial to load data from an Excel spreadsheet into a table. And in truth: When was the last time reference data was changed?
Some of your reference data is going to be more dynamic – things like products or branch offices. By all means consider building a screen to handle these. But most of your reference data is going to be static: Lists of countries, product types, and status codes. These do not need a screen.
Important: Having identified crucial and not important Forms modules, the remainder falls into the group called important. These modules will be migrated eventually, but not in the first release. Because testing resources are always limited, and the business is clamoring to get the complete new application as soon as possible, these modules will typically receive only partial testing.
Pushdown: Once you have identified the modules that need to be migrated (i.e. the crucial and important ones), you need to go through the business logic in all the Forms triggers and PL/SQL libraries that contain your own code.
Each block of code will fall into one of the following five categories:
- DB Logic
- UI Logic
Make a list of all code elements (Forms triggers, PLL procedures and functions) and which category it falls into. This will give you an idea of the amount of code migration you need to do.
It makes sense to do code pushdown no matter if you decide to migrate your application or keep it running as it is. If you decide to migrate, you will have made the task easier, and if you decide to let your Forms application continue running as it is, it will perform better when data logic is pushed into the database.
Dead: In an application developed over time, some of your code elements are likely to be completely dead code that is never executed or does not have any function. You might find triggers where all the content has been commented out, or functions that simply return a hardwired TRUE or FALSE. All of these do not need to be migrated.
Irrelevant: In addition to the dead elements, you might find code blocks that only invoke Forms-specific functionality (e.g. set :SYSTEM.MESSAGE_LEVEL). Because the functionality they implement will be handled differently (possibly automatically) by Oracle ADF, these elements also do not need to be migrated.
DB logic: Code elements that only contain database logic should be pushed down into the database. SQL statements are a good example of this.
If you have code blocks that simply perform an INSERT, UPDATE, or DELETE, create a corresponding procedure in your database and modify your trigger or PLL to call this procedure. In this way, you get the same functionality,
Other examples are triggers that query something from the database based on a value in a Forms field, makes some kind of decision and then executes SQL or calls a stored procedure or function. These should also be converted into store procedures that take the necessary parameters, and your trigger should be modified to simply call the procedure.
UI logic: Elements that only address the User Interface are considered UI logic. Examples of this would be triggers and procedures that set properties on Form fields, or elements that calculate values based on other fields. Make a note of these – they will have to be re-implemented in Java in Managed Beans in your ADF application.
Hybrid: Hybrid elements are those that contain a mixture of the above categories. Each part of this code should be handled in accordance with the above guidelines, i.e. the dead or irrelevant code should be removed, and the DB logic pushed down into the database. After this, your hybrid block should contain only UI logic.
Rethink: After the Triage and Pushdown steps, you have a clearer idea about the task you are facing.
Now is the time to rethink your application to add business value. You might already have a backlog of user requests or ideas that have never been implemented because it was too hard in Oracle Forms. Have a look at this list and ask someone who knows ADF well whether any of these can be easily implemented in ADF.
There are a number of typical Forms-to-ADF improvements you should consider as part of your rethink process:
- Better workflow support
- Better tables
- Information hiding
- Details on demand
- Graphical representation
One of the important new features that you get with Oracle ADF is better workflow support through ADF Task Flows. These are sequences of screens that guide a user through the tasks that he or she has to do, and are a big improvement over Forms applications where you typically have to know which screens contain the data you need, and in which order to use them.
Another improvement is the ADF table component. I’ve envied PowerBuilder developers their DataWindow components for more than a decade, and now I finally have a powerful table component where the end user can filter, sort, and re-order columns.
ADF also supports better information hiding through collapsible panels and splitters. This allows you to provide more information to the user, and at the same time allow the user to remove some of the information in order to see more rows or columns.
A related feature is details on demand. With powerful and easy-to-use popups and mouseovers, you can show the user much more information whenever they need it.
Finally, ADF offers us great visual components for graphs, pie charts, gauges, radar plots, etc. If you threw away Oracle Graphics in disgust back in the 90’s, know that Oracle has made up for that mistake in ADF.
After the rethinking phase, it is time to build start building application code in Oracle ADF. There are a number of initial tasks whenever you start building an ADF application – this article will not cover these, but you can refer to my book Oracle Enterprise Application Development Made Simple for more information.
Building the Shell
In this initial iteration of the application, you build an ADF outer shell with a menu and one simple page for every crucial and important Forms module in your application. This page should simply contain your Oracle Forms module inside an <af:frame> tag. This tag is the ADF equivalent of an HTML <IFRAME> tag, i.e. it allows you to allocate part of the browser screen to a completely separate session.
In the menu, you create menu items for every Forms module and add the logic to navigate to the page that contains that module. This gives you an application with the same functionality as the old Forms application, but now inside an Oracle ADF shell.
As already mentioned, your Forms can be spruced up after the manner of your typical TV house makeover shows:
- Remove most of the furniture
- Paint everything white
In an Oracle Forms application, you first remove a lot of the screen furniture. All Forms applications tend over time to gravitate towards “the one screen to rule them all.” This screen is crammed full of every field that every user could possibly need, using every last pixel of screen area. However, if you actually observe the users or add logging of individual elements to your Oracle Forms module, you will find that 80% of the time, your users are only using 20% of the elements on the screen. Create a copy of this massive screen where you remove all of the fields, checkboxes and buttons that are rarely used and make this the default screen. Then have an Advanced Mode button or separate menu item to invoke the overfilled screen.
Second, you change the color scheme. If your application is still using a retro-gray background like we did in the 80’s and 90’s, change the background color to white. Also, replace all your default Oracle Forms buttons with graphical image buttons with rounded corners and a modern look. Together, these two simple things will improve the visual appearance of your old Forms application dramatically.
At this point, you will have to face the fact that authentication is done differently in ADF than in Oracle Forms. In an ADF application, you have to log on to the application server that runs the application. This can happen automatically, if your users are already logged on to some authentication provider (e.g. Windows), and you configure your WebLogic server to accept the credentials from that authentication provider.
If you have already enabled your Forms application for Single Sign-On (SSO), you can simply connect the WebLogic server where your ADF application is running to the same SSO server and will only get one login prompt. If your Forms application is authenticating against the database, i.e. all users are logging on to the database, you need to make a decision:
- Either you accept that the user will have to log on to the ADF application once (possibly automatically) and once onto the Forms application
- Or you decide to implement SSO in your Forms application so your users will only be prompted to log on to the application server once. If you have set up your WebLogic server to accept the Windows login, the user automatically logged on.
High Value Add
You would normally not show this initial version 0.0.1 of your application to the end users. After all, it works just like the old one with a new wrapper and a slightly different menu. But it serves as the basis for the next phase: The High Value Add.
The result of your Rethink phase will probably be several workflows that can be better supported in ADF, as well as individual screens that can be re-invented with the new, more capable components available in ADF. In the High Value Add phase, you implement some or all of these in order to prove business value.
Once you have done this, you are ready to show version 1.0 of the application to the business. This is an important decision point for the migration process: If you can demonstrate business value, you will be given the funding to continue with the last phase. But if you cannot, the business might decide to shut the project and go back to your old Forms application.
If you manage to convince the business, you then start a stepwise migration process. In accordance with modern application development methodology, this should be done in short cycles and fixed release dates.
From your Triage and the analysis in the Pushdown phase, you know what you need to do. The business decides the your priorities, and you implement first the crucial and then the important functionality in that order. Each release should show several Forms modules replaced with their equivalent functionality in Oracle ADF, until you have migrated or discarded every part of your old Forms application.
You need to decide what you want to do with your existing Oracle Forms applications. Oracle will support the product for many years yet, but if you decide to migrate to modern technology, you should use this six-step approach to maximize the business value from the migration and make sure that you provide this value as quickly as possible. The business will thank you.
** The original article was posted by Oracle Ace Sten Vesterli in one of his blog. All views expressed in above article are Douwe personal opinion.
BrightStar is an Oracle Consulting house specializing in Oracle Fusion Apps, Oracle EBS R12 & EPM/BI. Kindly visit http://www.bslion.in to know more about us.