3.1 OracleAS Forms Services in Action

This sections describes how Forms Services run in OracleAS, and how the configuration files are used, assuming that the Forms Servlet is used to generate the initial HTML page. For simplicity, we assume the Web server is running on port 7777 on a computer called "mycomputer.com". We also assume no modifications have been made to the standard configuration created during the Oracle Application Server installation process.

When a user runs an Oracle Application Server Forms Services application, the following sequence of events occurs:

1. The user starts up their Web browser and goes to a URL like the following:

   http://mycomputer.com:7777/forms/frmservlet?config=myapp&form=hrapp
   

   In this case, the (top level) form module to be run is called "hrapp" using the configuration section called "myapp".

2. Oracle HTTP Server listener receives the request. It forwards the request to OC4J, since the path /forms/frmservlet matches one of the OC4J mount directives in the forms.conf file (the one for the Forms Servlet).

3. OC4J maps the request to the Oracle Application Server Forms Services application (whose context root is /forms). It maps the request to the Forms Servlet (using the frmservlet mapping specified in the web.xml file).

4. The Forms Servlet (running in OC4J) processes the request as follows:

   • Opens the servlet configuration file (formsweb.cfg by default). If that parameter is not set, the default configuration file (ORACLE_HOME/forms/server/formsweb.cfg) is used.

   • Determines which configuration section to use in the formsweb.cfg file. Since the URL contains the query parameter config=myapp, the [myapp] section will be used.

   • Determines which baseHTML file to use, based on (a) what browser made the request, (b) what platform the browser is running on, and (c) the settings of various parameters in the formsweb.cfg file (specifically, baseHTMLie, baseHTMLjinitiator, baseHTMLjpi, baseHTML, and IE).

   • Reads the baseHTML file, and sends the contents back as an HTML page to the user's Web browser, after doing variable substitutions as follows:

Whenever a variable (like %myParam%) is encountered, the Forms Servlet looks for a matching URL query parameter (for example, &myParam=xxx), or, failing that, looks for a matching parameter in the formsweb.cfg file. If a matching parameter is found, the variable (%myParam%) is replaced with the parameter value.

For example, the baseHTML file contains the text %form%. In our example, this is replaced with the value "hrapp".

1. Depending on which baseHTML file the Forms Servlet selected, the HTML page sent back to the Web browser will contain an Applet, Object or Embed tag to start up the Forms applet (thin client). The Forms applet runs in a JVM (either the Web browser's native JVM, or a "plugged in" JVM like Oracle JInitiator or Sun's Java plug-in).

2. If the baseHTML file selected was for a plug-in (Oracle JInitiator or Sun's JDK Java plug-in), and if the user does not already have that plug-in installed on their computer, they are prompted to install the plug-in. In the case of JInitiator, the download location is under the virtual path /forms/jinitiator (a virtual path defined in the forms.conf file).

3. In order to start up the Forms applet, its Java code must first be loaded. The location of the applet is specified by the applet codebase and archive parameters. For example, if the user is running with Oracle JInitiator, the applet code is loaded from the file http://mycomputer.com:7777/forms/java/frmall_jinit.jar

   The virtual path definition in the formsweb.cfg file for "/forms/java" allows the applet code to be loaded from the Web server.

   Note: The Forms applet code (for example, frmall_jinit.jar) is only to be loaded over the network the first time the user runs an Oracle Application Server Forms Services application (or if a newer version of Oracle Application Server Forms Services is installed on the Web server). Otherwise, it is to be loaded from the Web browser's (or the Java plug-in's) cache on the local disk.

4. Once the Oracle Application Server Forms Services applet is running, it starts up a Forms session by contacting the Forms Listener Servlet at URL http://mycomputer.com:7777/forms/lservlet.

5. The Oracle HTTP Server listener receives the request. It forwards the request to OC4J, since the path Ò/forms/lservletÓ matches one of the OC4J mount directives in the forms.conf file (the one for the Forms Listener Servlet).

6. The Forms Listener Servlet (lservlet) starts up a Forms runtime process (frmweb.exe or frmweb) for the Forms session.

7. Communication continues between the Forms applet (running in the user's Web browser) and the Forms runtime process, via the Listener Servlet, until the Forms session ends.

8. The command line (such as giving the name of the form to run) is passed to the Forms runtime process. It is given as the applet parameter "serverArgs". Part of the serverArgs value in the baseHTML file was %form%, which was replaced by "hrapp". Therefore the runtime process actually runs the form in the file "hrapp.fmx".

   This file must either be present in the workingDirectory (which is specified in the Forms Web Configuration page of Application Server Control Console), or in one of the directories named in the FORMS_PATH environment setting, which is defined in the environment file (default.env by default). You can also specify the directory in the Forms Web Configuration page (for example, form=c:\<path>\myform).

9. The Forms sessions end when one of the following occurs:

   • The top level form is exited (for example, by PL/SQL trigger code which calls the "exit_form" built-in function). In this case, the user is prompted to save changes if there are unsaved changes. exit_form(no_validate) exits the form without prompting.

   • The user quits their Web browser. In this case, any pending updates are lost.