Installation Cookbooks: Deploying Forms on the Web

September 16, 2004

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.

» See All Articles by Columnist Steve Callan

The Network for Technology Professionals



Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers