Customer Case Study
TREMBLING ON THE THRESHOLD OF CONVERSION:
PLANNING FOR SUCCESSFUL ORACLE9I FORMS PROJECTS
A P Clarke, LogicaCMG
INTRODUCTION
When one has finished building one's house, one suddenly realizes that in the process one has learned something that one really
needed to know in the worst way - before one began.
Friedrich Nietzsche
If you are planning to upgrade a recently written Forms 6i application, a small, simple query and update application,
then you can probably stop reading this paper right now. You will have little or no trouble porting it to Oracle9i
Forms. If, however, you are faced with the prospect of moving a complex suite of legacy code that started out in
Forms 4.5 (or earlier), one with lots of interaction with other applications then you should keep reading.
I recently worked as a technical lead on a project that migrated a suite of Forms 4.5 applications to Oracle9i Forms.
This paper is a distillation of the things the project manager would have liked to have known before we started the
work. It is not a technical solutions paper - there are plenty of technical resources around (if you know where to
look). Rather this is intended as an aide to the project planning process. I assume readers will have some basic
familiarity with the Oracle Developer Suite.
BACKGROUND
In O9iDS Oracle withdrew support for the client/server mode of deployment. This means that customers are faced
with a choice between moving their existing client/server applications to the web and going out of support. Both of
these options seem scary. The purpose of this paper is to show that the migration of client/server applications need
not be a daunting prospect. Its suggestions are a combination of what we think we got right and what we wish we
had done instead.
THE PROJECT
The project migrated an enterprise application comprising three interrelated systems. All three systems were old,
having been developed by three different sets of contractors and over the years had accreted lots of code fixes and
enhancements. Furthermore, all three systems were richly featured with lots of client-side, OS specific interaction.
These attributes presented us with some challenges over the course of the project. When we started the project we
were working with the goal of changing as little code as possible to achieve the same functionality on the new
platform. The basis of this decision was an entirely pragmatic one: we were pioneering so we chose to limit the scope
of change to the interfaces within our systems and leave the core functionality untouched. You may make the
opposite decision and elect to move your application entirely on to the application server. This paper is still relevant,
because its aim is to raise consciousness of the issues rather than prescribing solutions.
TOP TIP #1: THIS IS NOT A WEB PROJECT
Although Oracle9i Forms uses web technology to deploy Forms it is easier not to think of it as a web project. In all
likelihood your migrated system will still have most of its existing client-side functionality on the client1. It therefore
remains a client/server application. It is a fundamentally different proposition from building the next Amazon web
site.
1
Unless you have opted to implement the migrated application as a thin client project, of course.
Paper # 36625
Customer Case Study
PLANNING IN EIGHT EASY STEPS
Some of these steps will run in parallel. Others may need to be revisited over the course of the project. The list starts
with Step 0, because it an ideal world you will already have all this information to hand, so you can skip it.
STEP 0: KNOW YOUR APPLICATION
First you need to establish the magnitude of the task ahead. With most software upgrade projects the bulk of the
work lies in regression testing, to make sure that the new version of the product has not introduced fresh bugs.
However, moving client/server applications to 9iDS is not like other software upgrade products. There is,
potentially, a large amount of functionality that will work differently – or may not work at all – when the application
runs in web-deployed mode2.
The areas that may cause problems include:

integration with other systems;

use of bespoke external libraries;

use of third party software;
 interaction with the desktop environment, for example registry settings or floppy disk drive.
For example, authentication of database accounts using IDENTIFIED EXTERNALLY instead on passwords does not
work with web-deployed Forms. This will be a particular pain if your application crosses database boundaries,
because you need to keep the database account passwords in sync with each other.
Try to identify all client-side and operating system-specific interaction. Such activity is indicated by the use of the
following Forms built-ins:

Host

Text_IO

OLE2

DDE

Get_File_Name

Tool_Env

ORA_FFI

Read_Image_File and Write_Image_File
 Calls to the D2KWUTIL library.
Establish what areas of your system are not documented. Be honest! You may have particular problems with “black
box” DLL files, the ones that have not been touched in years. Nobody quite knows how these libraries work but they
do. Migrating such files so they continue to function in the new environment might require a lot of experimentation.
TOP TIP #2: AVOID MISSION CREEP
You must limit the scope of this project to the existing functionality you have identified in this stage. Resist the
temptation to include enhancements or bug fixes. You must apply regression tests on the migrated application
against a known set of functionality; if you include additional work in this project you have muddied the water when it
comes to isolating the cause of test failures.
This is because the 9i Forms application runs as a Java applet in the browser, and the default Java security model prevents code
run by applets communicating with the desktop environment outside the browser. You can find a more detailed explanation in
the Oracle white paper mentioned in Step 7.
2
Paper # 36625
Customer Case Study
STEP 1: PLAN YOUR APPROACH
Once you know what you have got you are in a position to find out what you need to do. There are some useful
resources on the web (see Step 7) that will give you an insight into the problems of enabling client-side interaction in
Oracle9i Forms. You then need to run a triage on all your client-side functionality.
(1) WHAT CAN BE MOVED TO THE SERVER
There are two types of function that can be moved to the application server. There are functions that can
run on the server without meaningful change and those that can be moved to the server but only with
significant change. In the former category would be things such as a pure C library that requires nothing
more than recompilation to run on the server. In the latter category fit items such as a third party software
tool that has a Visual Basic interface for use on a PC and a Java API for use with a server-based installation.
This requires some work, because the tool-facing code has to be rewritten to use ORA_JAVA instead of
ORA_FFI. Of course there may be changes in behaviour as well.
(2) WHAT MUST REMAIN ON THE CLIENT
This is pretty much everything that doesn’t fall into category (1). It includes everything that has an
unbreakable client-side dependency. An example is reading or writing files on a floppy disk. If you have a
Windows client environment and a Unix server platform this category is likely to be quite large and will
include things such as using OLE to talk to Word or Excel and DLL files that use code from the Microsoft
Foundation Classes. The problem is that nothing in this category will work in Oracle9i Forms without some
intervention. Do not despair; there are tools and techniques available to re-enable the client-side interaction
(see Step 7).
(3) WHAT CAN BE DISCARDED
This is likely to be a very small set of the current functionality. There are very few things for which there is
absolutely no remedy. However, the work required, for instance rewriting an OCX control as a PJC, may
simply be more effort than the functionality deserves. Then you have to agree a simpler alternative with the
users. Ask whether you can drop the functionality altogether: there may be some menu options that the
users may never use, some reports that they never run.
Remember to include in your triage exercise not just the client-side functionality but the de-supported Forms and
Reports functions as well. For instance, the RUN_PRODUCT built-in is no longer supported, so you need to replace all
those calls with either RUN_REPORT_OBJECT or WEB.SHOW_DOCUMENT.
Client-side interaction can occur not just in Forms modules. The trigger code of Reports can contain D2KWUTIL calls
as well as some of the other built-in packages listed above. There may even be some in the database PL/SQL; for
instance, the USERENV(‘TERMINAL’) function will return the application server’s name rather than the name of the
client PC.
Finally, you need to check for server-based activity in your client-side programs. For instance, a DLL file that uses
Pro*C to execute SQL against the database may no longer work.
Document these decisions in a Plan of Approach document and ensure that all your developers read it before they
start work on the migration. Produce a checklist of all the things developers need to watch for in migrated Forms
and Reports.
STEP 2: DRAW UP TIME SCALES AND ESTIMATES
Migrating to 9iDS is a straightforward proposition if you have a straightforward system. Having completed the
surveys in Step 0 and Step 1 you now know whether you have a straightforward system.
There are very few issues with pure Forms and Reports. Some rework is needed to resolve de-supported features, for
instance replacing RUN_PRODUCT when calling Reports from a Form. Nevertheless, the basic migration process can
be estimated quite accurately, using your skill and judgment.
The real headaches come from the external applications and client-side interactions. Almost inevitably these will
require some change, and possibly total redevelopment. Estimates for these areas of functionality should treat the
Paper # 36625
Customer Case Study
project as a development project and assume development time scales. This is also the area where overruns are likely
to occur. True, you are not developing an entire application but you are likely to find yourself redeveloping the glue
that binds the disparate parts of your system together. The good old 80:20 rule applies here.
TOP TIP #3: STUFF HAPPENS
Unless you are fortunate enough to have developers who have already undertaken such a migration this project is
likely to be a voyage of discovery for all concerned. Remember to allow time in the estimates for research,
experimentation and overcoming the obstacles that impede any sizeable development project.
STEP 3: PREPARE YOUR USERS
The chances are the users will not see any enhancement of their experience of the system: they are unlikely to regard
ease of deployment as a benefit to them. Indeed, they may experience slower performance in some tasks and even lose
some functionality. In other words, there will be a lot of effort being undertaken for little appreciable benefit to
them, beyond remaining on a supported platform.
Your users (one way or another) are paying for this project. It is therefore crucial to ensure that you set the
expectations of your user representatives upfront.
TOP TIP #4: THIS IS NOT AN UPGRADE
Normally we call moving to a new version of the software an “upgrade”. Try to avoid using this term when talking
with your users about this project. Upgrade has connotations of delivering improvement, and as I have just said, that
is unlikely in this case. We used “migration” as the preferred term, because it suggested transformation without
implying enhancement.
STEP 4: ASSEMBLE YOUR TEAM
A successful migration of an application to Oracle9i Forms requires a mixture of talents. You are unlikely to have
many people who have all the necessary skills, so you need to assemble a balanced team, like the Magnificent Seven
(or the Dirty Dozen – take your pick).
MEMBERS OF THE CURRENT SUPPORT TEAM
These people know the current state of the system and are familiar with its complexities. They are also using
Forms and Reports on a daily basis so they will be attuned to that as a working environment.
MEMBERS OF THE ORIGINAL DESIGN/DEVELOPMENT TEAM
If available (and they are not gaga), these people will form a valuable repository of knowledge about why
certain aspects of the system were implemented the way they were. This information may prove crucial when
it comes to unpicking some of the client-side interactions and other system integrations.
PEOPLE WITH EXPERIENCE OF THE NEW TECHNOLOGY
The most important aspect of the new technology is O9iAS. This is the application server that actually
delivers the web forms to the browser at runtime. This is a complicated tool, which requires a lot of
administration and configuration. Client/server applications do not have an analogous role, so this is a new
person you need to find (unless you already have some other web Forms applications). Not having at least
one experienced O9iAS administrator on your team is a serious threat to your project. Cross-training a DBA
or systems administrator will not be sufficient (unless you have a very comfortable time scale).
Having developers with prior experience of web Forms (versions 6.0 or 6i) will be useful. These people will
understand some of the issues involved and will be familiar with the new environment. The differences
between Forms 6i and Oracle9i Forms are fairly trivial compared to the differences between client/server
and web deployment.
Having developers with Java expertise is helpful. Although most of the work will require Forms PL/SQL
only, Oracle use Java to extend the range of Forms functionality. Much of the Java code you may require is
already available from Oracle and other sources but you may well need to develop some bespoke Java
programs. J2EE expertise is not required (remember, this is not a web project!). You might find developers
Paper # 36625
Customer Case Study
coming from a pure Java background have some difficulty reconciling their Object Orientated training with
the needs of a procedural language like PL/SQL.
PEOPLE WITH EXPERIENCE OF THE OLD TECHNOLOGY
If your application makes use of external libraries you may need people who know Visual Basic, C, etc. in
case any rewriting is required.
STEP 5: INSTALL YOUR ENVIRONMENTS
With Oracle9i Forms you have two distinct environments: O9iDS for development and O9iAS for deployment.
Both should be properly set up before you actually start work. Testing your migrated modules on O9iAS is crucial, as
they may exhibit different behaviour in the different runtime environments. O9iAS is your production platform and
you must ensure that the configuration files, paths and general infrastructure works properly.
If you are going to deploy your Forms and Reports on O9iAS installed on a Unix platform it is important to develop
them on Unix as well. This is primarily because Unix is case sensitive and uses a different directory separator from
Windows. These may seem like trivial differences, but they can cause tremendous problems with referenced modules:
this particularly affects libraries, menus, and CALL_FORM, OPEN_FORM, NEW_FORM statements. Oracle do not
support the use of their products via terminal emulation software, so accessing a Unix installation of O9iDS through
emulators such as Reflections X is unsupported. However, it is a lot cheaper than throwing away your developers’
expensive high specification PCs and buying Unix workstations instead.
If you are moving on a new development platform consider changing your working practices to suit. For instance, we
regretted continuing to use a Windows-based Source Control repository instead of moving to a Unix-based one.
Remember to involve all the different areas of the infrastructure team in this step. Check with the system
administrators and network support people to see if there are any issues surrounding network traffic or security. For
instance, does the new application have to use a firewall? Will the network cope?
Ensure you have a functioning Source Control Management repository. You are about to touch every single file in
your application. In addition, you now have to manage a new set of configuration files for O9iAS and other
applications. Proper source control and configuration management will make this task an awful lot easier.
Finally, remember to fully test the environments before work starts.
TOP TIP #5: O9IDS IS A CLIENT/SERVER APPLICATION
So, ironically enough, you cannot access O9iDS through a web browser and build your Forms remotely. This may
seem obvious, but I heard of one migration project where someone had proposed installing O9iDS on a server in
Germany even though the development team was based in Britain.
STEP 6: MONITOR CHANGE
The Plan of Approach is the cornerstone of the migration process. This document gives the developers a list of
issues to watch for and solutions to apply. So the Plan of Approach must be kept up to date with any new
discoveries. It is important to derive standard solutions to generic problems but it is even more important to
recognize when a solution is the wrong choice in a particular circumstance.
Once work on the migration has started it is important to keep track of the changes that are made to each module - a
spreadsheet will suffice. This makes it easy to determine which modules are affected in case you find a solution in the
Plan of Approach has a problem. If you are using the Forms Migration Wizard to achieve the initial conversion to
Oracle9i Forms then keep the log files it produces.
Again: Source Control and Configuration Management are key to a successful migration. At the very least the Source
Control Management repository will show you that you have actually converted all the modules you need!
STEP 7: DON’T RE-INVENT THE WHEEL
There are several sources of technical information and useable code. Take advantage of them.
Oracle TechNet has a Forms Upgrade web site that is devoted to the topic:
http://otn.oracle.com/products/forms/htdocs/upgrade/content.html
Paper # 36625
Customer Case Study
This site is a repository of informative white papers and demonstrations. The key white papers are Migrating
Client/Server to the Web and Forms6i to Oracle9i Forms Upgrade Reference.
There is another web site for WebUtil:
http://otn.oracle.com/products/forms/htdocs/webutil/webutil.htm
This is a utility that simplifies the process of integrating client-side functions with Oracle9i Forms. It provides some
client-side Java code that allows web Forms to communicate with the desktop and a PL/SQL library to wrap the Java
calls. WebUtil will be a supported part of O9iDS with the release of O10gDS (release 9.0.4).
The O9iDS comes with an extensive set of demos illustrating the use of Pluggable Java Components.
http://otn.oracle.com/sample_code/products/forms/content.html
These have fruitful suggestions for delivering client-side interaction from the new platform.
TOP TIP #6: USE THE OTN FORUMS
Several members of the Development Tools Group regularly post answers on the OTN Forms Forum.
Consequently, it is a conduit to some of the best knowledge on Oracle9i Forms and migrating to web deployment.
STEP 8: TEST, TEST, TEST
You are effectively rewriting your entire application to run in a different deployment environment. You need to test
everything but especially the joins between systems, links to external applications and the client-side interactions.
This is the kind of project where automated regression testing tools really come into their own.
FINALLY, DECIDE HOW TO GO INTO PRODUCTION
Some project methodologies recommend running a new system in parallel with the old one. Migrating to Oracle9i
Forms is one of the few circumstances in which this is a genuinely viable proposition. The migrated application can
be launched from a URL without disturbing the existing client/server version. This may make your users feel more
comfortable than does the prospect of the Big Switch-Off. Opting for parallel running is not without implications: if
you have to modify of the client-side programs then you need to make sure the new code works with the
client/server version of the application as well.
CONCLUSION
You improvise! You adapt! You overcome!
Gunnery Sgt Tom Highway, Heartbreak Ridge
The migration of a client/server application to web deployment is much more like a development project than a
maintenance one. It is probably not possible to anticipate all the obstacles that your project might encounter.
However, providing you have planned for the occurrence of some problems, you have a resourceful team and you
monitor the progress of the migration itself, there is no reason why it should not be a very successful project.
ABOUT THE AUTHOR
Andrew Clarke is a consultant for LogicaCMG. He is an Oracle generalist, having worked with Oracle products for
more than ten years. In his time he has been a developer, a designer, a DBA, a systems analyst and a technical
architect. He also has some rusting Java knowledge.
Paper # 36625