This topic describes the steps to run Forms Services in Oracle Fusion Middleware and how the configuration files are used.

Be aware that if you run an out-of-the-box Forms URL with no arguments the user will be shown the default test-form, which displays the Forms version number information. If it is desired that this information not be displayed, the administrator can simply modify the [default] config section in the Forms Web Configuration so that a different form is specified (or no form is specified at all, in which case users will get an error message when they try that URL rather than seeing the form that includes the version number). For example, assume Oracle HTTP Server (OHS) is running on port 7777 on a computer called example.com. Also assume no modifications have been made to the standard configuration created during the Oracle Fusion Middleware installation process.

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

1. The user calls Forms using a URL:

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

   In this example, 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 finds /forms path in the URL and forwards the request to the correct Oracle WebLogic Managed Server based on the WebLogic handler mappings. The mapping is defined in forms.conf.

   Note:

   Using Oracle HTTP Server in front of WebLogic Server is optional. Choosing to do so will require that forms.conf be configured post installation. The included example within the file can be used as an example of appropriate settings. Once settings have been saved, the file should be moved to the OHS configuration file directory that contains other .conf files, see Enabling Oracle HTTP Server with Oracle Forms Services.
3. Oracle WebLogic Managed Server maps the request to the Oracle Forms Services application that has a context root named /forms. It maps the request to the Forms servlet using the frmservlet mapping specified in the application.xml file.
4. The Forms servlet running on the Oracle WebLogic Managed Server processes the request. The Forms servlet:
   • Opens the servlet configuration file (formsweb.cfg by default), which is located in $DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_14.1.2/config.
   • Determines which configuration section to use in the formsweb.cfg file. In this example, the URL contains the query parameter config=myapp, therefore, the [myapp] section is used.
   • Determines which template file (for example, baseHTML, basejnlp, or basesaa.txt) file to use, based on:
     1. which client configuration (for example, browser, web start, or FSAL) made the request;
     2. what platform the user is running; and
     3. the settings of various parameters in the formsweb.cfg file.
   • Reads the template file, and returns the contents as an HTML, JNLP, or text (based on the client configuration choice) after performing 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.

     In this example, the template file contains the text %form%. This is replaced with the value "hrapp".

5. Depending on which template file the Forms servlet selected, the page returned to the client contains an applet, object embed, or jnlp tag to start the Forms applet. The Forms client runs in the JVM environment provided by Oracle Java plug-in, Web Start, or standalone Java executable, depending on the request type.
6. To start the Forms applet, its Java code must first be loaded. The location of the applet is specified by the applet codebase and archive parameters.

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

   Note:

   The Forms applet code is only loaded over the network the first time the user runs an Oracle Forms Services application or if a newer version of Oracle Forms Services is installed on the Web server. Otherwise, it is loaded from the Java cache on the local disk.
7. Once the Oracle Forms Services applet is running, it starts a Forms session by contacting the Forms Listener servlet at URL http://example.com:7777/forms/lservlet.
8. The Oracle HTTP Server listener receives the request. It forwards the request to Oracle WebLogic Managed Server, since the path /forms/lservlet matches a servlet mapping in the web.xml file (the one for the Forms Listener servlet).
9. The Forms Listener servlet (lservlet) starts a Forms run-time process (frmweb.exe or frmweb) for the Forms session.
10. Communication continues between the Forms applet and the Forms run-time process, through the Listener Servlet, until the Forms session ends.
11. The attribute value in a URL (such as the name of the form to run) is passed to the Forms run-time process. Part of the serverArgs value in the template file is %form%, which is replaced by "hrapp". Therefore, the run-time process runs the form in the file "hrapp.fmx".

    This file must be present in any of the directories named in the FORMS_PATH environment setting, which is defined in the environment file (default.env by default).

12. The Forms sessions end when either of the following occurs:
    • The top-level form is exited (for example, by the PL/SQL trigger code which calls the "exit_form" built-in function). The user is prompted to save changes if there are unsaved changes. exit_form(no_validate) exits the form without prompting.
    • If the user quits the session without first saving pending changes, all changes will be lost.