Web-enabling Oracle
Developer Applications
Bonnie Vermillion,
Dulcian, Inc.
Introduction
The Web has become an important mechanism in
providing non-client/server business application solutions. For this reason, it
is important for corporations to further reduce the cost of implementing Web
solutions by Web-enabling existing business applications. More applications
would be running on the Web both as Intranet and Internet applications if
current client server applications could be Web-enabled.
Oracle’s Web Application Server, now known as
Oracle Application Server (OAS), makes it possible to Web-enable Oracle forms
and reports. This process becomes easier with each new release of the Oracle
Application Server.
This paper explains how to implement a Web
forms solution for Oracle Forms applications. It covers issues that need to be
addressed in the Application Server and in the form. Also included is an
explanation of how the Application Server and Developer work together to Web-enable
forms. Additional tips and issues regarding the installation and configuration
of the Web Server will also be covered.
Developer Versions 2.1 (Forms 5) and Forms 6
are discussed although, as of this writing, version 6 is only in beta release
and Oracle Application Server 4 is not yet compliant with Developer 6
architecture.
Factors to Consider
There are three important factors to consider
in deploying Web forms:
Each will be discussed in turn.
1. Architecture
The architecture of Web forms is a
three-tier solution. The first tier is the user interface or client, which
consists of a Java-enabled browser. The second tier is the application server .
The third tier is the database server. Developer resides on the Application
Server and consists of a Forms Client and Forms Server. At runtime, the Forms
Client, a Java applet, is downloaded to the client displaying the form and
manages the connection between the client and application server. The Forms
Server consists of a listener and a runtime engine. The Forms Server Listener
starts the runtime session and connects the Forms Client to the Forms Server
runtime session. Thus, the client handles the user interface while all
processing occurs on the application server.
The Oracle Application Sever also resides on
the application server. All versions following 4.0.6.4 of the Oracle
Application Server (OAS) require their own ORACLE_HOME, separate from the
database and therefore must physically reside on a machine separate from the
one where the database resides.
2. Software versions
Software versions must be compatible. To
avoid confusion, it is important to read the release notes in the Developer
documentation. For example, the following software requirements differ based on
the database and Developer version deployed:
Software
requirements for Oracle RDBMS 7.3.4 or 8.0.4:
Software
requirements for Oracle RDBMS 8.0.4:
Software
requirements for Oracle RDBMS 8.05
*Note – Netscape 4.05 will not work with
OAS4.0.6.4 unless it is the international version
3. Performance
Performance is a major concern in
implementing Web forms because all processing is handled by the application
server instead of the client. The developer needs to be aware that any action
in the form requires processing on the application server. There are a number of
ways to improve performance with Web forms. Oracle goes into much detail
regarding performance in the Oracle Developer Guidelines for Building
Applications section of the documentation that is provided with Developer.
Important performance issues to be aware of include:
Read the Oracle documentation carefully since
there are many other useful performance tips specific to Forms, Reports and
Graphics.
Images, background images, and timers also
degrade performance. It is best to eliminate such items wherever possible in
Web forms. Images such as company logos can be called within the HTML file that
loads at startup. This retains them in the Forms application and improves
performance.
Forms Issues
The documentation that comes with Developer
is very clear regarding form features that will not convert to the Web. This
documentation is available after installing Developer 2.1 and can be accessed
by selecting START/PROGRAMS/DEVELOPER DOC. Once you have access to the
documentation, select "Guidelines for Building Applications" and then
select "Deploying Applications on the Web." This section of the
documentation will specify of the form restriction details.
The major items to be concerned with are the
following:
In order to run an .FMX as a Web form, the
.FMX must be the same version as the Developer Server version. If a Forms 4.5
.FMX is to be run as a Web form under Developer Server 2.1, the .FMX must first
be converted to a Forms 5.0 .FMX.
Implementation
In order to implement Web forms, some
specific installation requirements for Developer 2.1 are necessary including :
Once all of the above products are installed,
select "Start/Programs/Developer 2000 R2.1." Select "Forms
Server Listener." This only takes a second to start and will quickly
return to the menu. It is important to note that anytime the WebServer box is
shutdown, upon startup this process will need to be invoked. Later, when
configuring cartridges for the Web Application Server, a ServerPort parameter
will be defined in the cartridge and linked to the value of 9000. This
definition relates to the Forms Server Listener. If an attempt is made to run
Web forms without starting the Forms Server Listener, a message to the effect
that "ServerPort 9000 is invalid" will be displayed. The solution is
to start the Forms Server Listener from the Designer 2000 R2.1 menu.
In order for Web Forms to be deployed the
Oracle Application Server (OAS) must be configured. The steps for configuring
OAS 3.1 are as follows:
1. Start the Application Server:
Each time the Server is booted one of the two
methods described below will need to be performed.
2.
Log on as the ADMIN user. This step also verifies that the Web Application
Server successfully started.
4. Configure the Listener.
File-System Directory |
Flag |
Virtual Directory |
D:\orant\forms50\Java\ |
NR |
/w50_code/ |
D:\apps\Web\HTML\ |
NR |
/Web_HTML/ |
D:\apps\Web\jars\ |
NR |
/Web_jars/ |
D:\apps\Web\tmp\ |
NR |
/Web_temp/ |
Please note that all of the above file system
directories should exist on the physical drive indicated. If the directories do
not exist, create the ones needed. The jar directory needs to contain copies of
the jar files from the forms50/Java directory. The HTML directory will contain
the HTML files that will be created to pass the form information to the Oracle
Application Server.
The www listener is now configured for Web
Forms. Click on the "Modify Listener" button. A success message will
appear. Scroll down the page to verify that the Modify process also started the
listener. If the listener did not start, but was successfully modified, click
on the "Start" button. If the listener does not start then either the
directory does not exist or there is a spelling or syntax error in one of the
file system or virtual directory mappings.
5. Configure the Cartridge
Configuration of a cartridge for Web forms is
not required to enable Web forms. A non-cartridge implementation is possible
and is described in the next section . The creation of a cartridge permits
parameters to be passed from the URL to the Web Application Server instead of
having to hard code information such as User Name and Password in a static HTML
file. This allows one HTML file to pass in information via the URL instead of a
static file for each form.
Click on the "ADMIN" button from
the Listener Administration page to get back to the Web Application Server
Administration page. From this page, click on the "Oracle Web Application
Server" icon. From the next page, click on "Cartridge
Administration." Click on "Add a New Cartridge." From the
Cartridge Administration page click on "Add New Cartridge with Manual
Configuration."
The page will now be labeled "New
Cartridge Configuration." Enter the following information:
Cartridge Name |
w50_cart |
Object Path |
d:\orant\bin\f50Webc.dll |
Entry Point |
form_entry |
Min # Instances |
0 |
Max # |
10 |
Services |
TRANSACTIONS |
|
CONTENT |
Protocol |
|
List of Hosts |
|
Custom config URL |
|
Cartridge Description |
Forms 50 Cartridge |
Cartridge Icon |
|
Valid mime types |
|
Client certificate |
Disabled |
Client sessions |
Disabled |
Max Session Idle Time |
0 |
Error Page |
%ORAWEB_HOME%/admdoc/wrberr.HTML |
Next
under Virtual Paths enter:
Virtual Path** |
Physical path |
/w50_cart |
d:\orant\bin |
**Note
that there is no slash after the virtual path.
Click on "Register New Cartridge." Go
back to the Cartridge Administration Page and select the Forms 50 Cartridge
that was just created . Click on "w50_cart Cartridge specific
Parameters" and enter the following:
Parameters |
Values |
BaseHTML |
d:\apps\Web\HTML\w50_cart.HTML |
HTMLdelimeter |
% |
Code |
oracle.forms.uiClient.v1_4.engine.Main |
Codebase |
/w50_code/ |
Archive |
/Web_jars/f50Web.jar |
ServerPort |
9000 |
module |
|
userid |
|
Click on "Modify Cartridge
Configuration." Note that the ServerPort 9000 definition above is
connected to the forms listener process. This step concludes the Web
Application Server Configuration process.
Icons need to be
converted to GIFs and physically located in the directory indicated by the
/Web_temp/ virtual directory in the OAS listener.
Modify the NT
REGISTRY:
FORMS50_MAPPING /Web_temp
FORMS50_OUTPUT
D:/’server image file temp directory’
or
Modify registry.dat:
Default.icons.iconspath=http://servername.com:listenerport/Web_temp/
Default.icons.iconextension=gif
HTML examples
An example of the
HTML file used to pass the form and user information is shown below and another
HTML file example shows how hard coding information within the HTML file will
bypass use of the cartridge.
Cartridge
HTML file example:
<HTML>
<HEAD>
<TITLE>Developer
Forms 50 Cartridge: form50cart</TITLE>
</HEAD>
<BODY>
<OBJECT
classid="clsid:9F77a997-F0F3-11d1-9195-00C04FC990DC"
WIDTH=%Width%
HEIGHT=%Height%
codebase="http://mymachine/jinit1110f.exe">
<PARAM
NAME="CODE" VALUE="%Code%">
<PARAM
NAME="CODEBASE" VALUE="%Codebase%">
<PARAM
NAME="ARCHIVE" VALUE="%Archive%">
<PARAM
NAME="type"
VALUE="application/x-jinit-applet;version=1.1.1.0f">
<PARAM
NAME="serverHost" VALUE="%ServerHost%">
<PARAM
NAME="serverPort" VALUE="%ServerPort%">
<PARAM
NAME="serverArgs" VALUE="Module=%Module%">
<COMMENT>
<EMBED
type="application/x-jinit-applet;version=1.1.1.0f"
Java_CODE="%Code%"
Java_CODEBASE="%Codebase%"
Java_ARCHIVE="%Archive%"
WIDTH=%Width%
HEIGHT=%Height%
serverHost="%ServerHost%"
serverPort="%ServerPort%"
serverArgs="Module=%Module%"
pluginspage="http://mymachine/jinit_download.htm">
<NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>
</BODY>
</HTML>
NON-Cartridge
HTML file example:
<HEAD><TITLE>Developer
Server and Oracle Jinitiator</TITLE></HEAD>
<BODY>
<P>
<OBJECT
classid="clsid:9F77a997-F0F3-lldl-9195-00C04FC990DC"
WIDTH=180
HEIGHT=20
codebase="http://mymachine/Web_HTML/jinit1110f.exe"
>
<PARAM
NAME="CODE" VALUE="oracle.forms.uiClient.v1_4.engine.Main">
<PARAM
NAME="CODEBASE" VALUE="/form50code/">
<PARAM
NAME="ARCHIVE" VALUE="/form50code/f50all.jar">
<PARAM
NAME="serverPort" VALUE="9000">
<PARAM
NAME="serverArgs" VALUE="module=d:\orant\forms50\emp.fmx
userid=Web_user/Web_user">
<PARAM_NAME="serverApp" VALUE="default">
<COMMENT>
<EMBED
Java_CODE="oracle.forms.uiClient.v1_4.engine.Main"
Java_CODEBASE="//"
Java_ARCHIVE="/form50code/f50all.jar"
WIDTH=180
HEIGHT=20
serverPort="9000"
serverArgs="module=d:\orant\forms50\emp.fmx"
pluginspage="http://mymachine:mylistener/Web_HTML/jinit_download.htm">
<NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>
</BODY>
</HTML>
URL Examples
The following
examples show differences between URLs with and without the cartridge.
Example with the
cartridge:
http://hostname/w50_cart?Module=form&userid=username/password@database
Example without the
cartridge:
http://hostname
/Web_HTML/filename.HTML
Test
To test a form, set
up the HTML file. You may want to try both types. Use the URL examples to enter
a URL from the Browser. The form will need to be recompiled using Developer 2.1
and the .FMX will need to be physically put in the \APPS\WEB\FORMS directory.
Developer 6 and
OAS4
As of this writing
Developer 6 exists in beta only. Upon its production release, it will be
compatible with OAS 4.07. According to Oracle, changes need to be made in
Developer 6 and in OAS 4.0.7 in order for Web Forms to work. Some important OAS
4 concepts to be aware of are outlined below.
OAS4 brings a new
look and feel to the Oracle Application Server, but does not contain the
required application type to produce a Forms Web cartridge at the time of this
writing.
The components of
OAS 4 are similar to prior versions, but the concepts and interface are
different. There are 3 layers to OAS4. These layers work together to pass
requests from the client to the database and back:
Configuring
OAS4
Configuration of OAS
4 for Web Forms is not performed in isolation, but becomes part of an expanded
function of configuration of the Forms Server that now contains a listener and
a modified Forms runtime engine. OAS 4.0.6.4.0 is the most recent OAS 4 release
at the time of this writing. This release is compatible with Developer version
6 beta release for the non-cartridge release only. As stated above, the
Developer 6 production release will be compatible with OAS 4.0.7. Be sure to
read the Release Notes option on the Welcome page when logging into OAS as
ADMIN.
OAS4 and Developer 6
can be loaded on a standalone machine, but in order to be used properly should
be loaded on separate machines. Configuration for a standalone machine on NT
does not require entries in the TNSNAMES.ORA file and configuration areas
requiring a connect string should be left blank.
Configuration of the
Forms Server is similar to configuring 3.0.1 with a few exceptions and includes
the following steps:
Oracle has included online documentation with
Developer 6 for easy configuration of each step.
Recompile .FMX’s using Developer 6 and run
the form by launching the base HTML file from a Java enabled browser . The HTML
file must point to the correct directory where the .FMX resides.
Conclusion
Using Web Forms is becoming a more viable
option for application deployment as performance is improved and more features
within forms can be Web-enabled. The Oracle documentation within each version
has also improved and is easier to understand and follow. Specifically, the
online documentation provided with Developer and the Oracle Application Server
explains the methodology used as well as the specific installation steps.
Web-enabling Oracle Developer Forms
applications provides cost effective reuse of existing business applications,
allowing customers to take full advantage of their Intranet in application
deployment. Reduction in maintenance, client hardware and Web application
design and deployment costs are the main benefits of this approach.
About the Author
Bonnie Vermillion is a Senior Developer with
Dulcian, Inc. She has been an Oracle Developer for over 10 years with the
Federal Government including 3 years with the Federal Trade Commission. She has
4 years experience working with Designer/2000 (now Oracle Designer) and serving
as CASE administrator. Bonnie has given presentations at ECO, ODTUG, and
numerous local Oracle user group meetings. She can be contacted at bvermillion@dulcian.com or through Dulcian’s Website at www.dulcian.com.