More and more, companies are making the move from the
client-server model of Forms to the 9i/10g Application Server Web-based
architecture. Previous articles in the Installation
Cookbook series discussed how to install Developer Suite and Application
Server. This article lays out a deployment framework to address the "now
that I have these things installed, what do I do now?" questions that are
appearing with greater frequency on Oracle-related websites, including Oracle’s
own MetaLink site.
As an Oracle developer, many of the topics covered will
directly apply to you. As an Oracle DBA, you could find yourself in the
position of being told to resurrect old Forms 6.0 or 6i forms and reports and
making them available on your company’s intranet. Remember when your Forms guy
was laid off? "We don’t want to you to do any development, Mr. DBA; we
just want you to make the forms available on the Web." So, with these two
Oracle users in mind (the developer and the DBA), let’s look at a deployment
framework that simplifies and explains what it takes to deploy forms on the Web.
There is a lot of material to cover here, so this
information will appear in two parts. Part one (this article) will primarily
discuss the migration process for Forms, and part two (published one or two
weeks after part one) will cover the steps needed to call Reports from Forms.
How to get from Forms 6i to 9i/10g
Before you do anything else, ensure you have a backup copy
of your Forms source code. This includes fmb’s, mmb’s, and pll files. Having
done that, you are now ready to start converting your 6i forms into a 9i/10g
state. Which Oracle product are you going to use to perform this conversion?
This answer may surprise you: use the Form Builder found in Forms 6i.
If a form compiles under 9i, it will compile under 6i. The
reverse is not necessarily true, but you can make it that way. Two commonly
used built-in’s in Forms 6i (change_alert_message and enable_menu_item/disable_menu_item)
are obsolete in 9i. These have become (actually, they already "were")
set_alert_property and set_menu_item_property under 9i. These built-in’s work
in 6i, so if you make the appropriate changes using the 6i Form Builder, your
6i fmb will successfully compile. You can also check the execution of your
revised fmx file by running it in the client-server mode. The specifications
for these built-in’s are shown in the 6i Form Builder Reference Guide (volume
one).
Using the 9i version of Form Builder (or the 10g version,
which is really release 9.0.4), open the 6i fmb and compile the module, BUT DO
NOT SAVE IT. If you save your 6i fmb as a 9i fmb, you cannot go back to a 6i
state. Yes, the 6i fmb will open, but you will find that much of your code has
disappeared. That is why you have a backup of everything. If there is a
compilation error under 9i, fix it (and save it) using 6i Form Builder, then
re-compile under both Form Builder versions. This approach allows you to keep
one source code repository and be able to generate fmx’s for two different
versions of Forms. Additionally, running the fmx from Form Builder is a lot
quicker than running its 9i counterpart on the Web. If the form runs fine in
6i, it will most likely run fine on the Web.
Oracle included a migration utility to take a 6i fmb to a 9i
state, but I found that it does not work that well. If you have a lot of forms
to migrate, you can open several at a time and use the Find and Replace
function in the PL/SQL editor to make your changes. It is actually pretty easy
to perform this step while using Form Builder because you will quickly develop
a pattern in how you make the edits. If the two aforementioned built-in’s are
your biggest changes, you can easily convert around 100 forms in an afternoon.
If any of these forms call reports, you have some extra work ahead of you. More
on that in the next article.
You can also use the f90genm executable to compile your 6i fmb’s
into a 9i state. This process can be tied into a shell script, but don’t forget
to pipe the output into a log file so you can see if there were any compilation
errors.
Finally, don’t forget to compile your attached library files
and menu files, (which you may want to do first). All of these 9i-enabled fmx’s,
mmx’s and plx’s can be placed in one or more directories as specified by the
FORMS90_PATH environment variable found in the default.env file.
How to view your new 9i forms on the Web
How did users call your 6i forms in the client-server
environment? If you used a master form that calls other forms (and reports),
you can use the same form in 9i. The master form has everything listed in
drop-down menu lists. This master form can be specified in the formsweb.cfg
file on the "form=" line. This simplifies the URL your users will use
to launch your forms. Using "http://server:port/forms90/f90servlet"
will cause an Oracle logon window to appear. After a successful logon, the
master form appears, and from there, all forms can be called. The unstated tip
here is that if you did not have a master form in 6i, think about making or
using one in 9i. Your users will appreciate the point and click approach to
call a form as opposed to entering URL after URL.
While testing your new 9i forms on the Web, you may as well
use Application Server to call/view them. There is no real need (assuming you
have the resources) to "turn on" the Developer Suite version of
Application Server – why not simply use Application Server to begin with? With
this approach, there is no configuration needed in Developer Suite. Just do it
once in Application Server. You are going to have to configure Application
Server anyway, so why bother with Developer Suite.
One other bit of work you may need to perform upon viewing a
9i form concerns the appearance of a form on the Web. Some text and display
items may be truncated when the form is viewed in a browser. For example, if
you have a "Save" button on a form, the "Save" text may
appear as "Sa…" if the button is disabled. You will have to add some
extra width to the button (via the property palette in Form Builder) if you
want all of the text to appear. The same thing applies for text alignment and
justification.
Quick tip about Oracle JInitiator
The very first time you call a form on the Web, you will be
prompted to download and install Oracle JInitiator. 99% of the time, this goes
off without a hitch. Some users will receive errors during the installation
process (messages about not being able to install 16-bit Windows applications,
a temp directory not being found, etc.). Do not waste time trying figure out
why the user’s computer is looking for some nonexistent temp directory. Copy
the jinit.exe file to the problem PC. Right-click the file and extract it
locally. Once that is accomplished, the setup.exe file can be run.
In closing
With a small amount of planning and prior preparation,
migrating 6i forms to a 9i state is a fairly painless process. If you have an
application that currently uses the client-server architecture and want to port
your forms to the Web, all the while supporting the client-server environment, you
will definitely want to use and maintain one source code repository. In
addition to the ease of testing for compilation purposes, using Form Builder 6i
is a sensible solution to preventing the problem of having to maintain two sets
of source code.
In the next article, I will cover the steps to use
Reports-related built-in’s in your forms, how to "tell" your forms
the name of your report server, how to toss in some JavaScript so an "Exit"
button will exit a form and close the browser window, and how to use and
configure the in-process report server. In the meantime, you now have enough
information about what it takes to set up and use forms in a Web-based
environment. The framework I have laid out will ensure a successful migration
process for you.
