3 Basics of Deploying Oracle Forms Applications

A sequence of events occurs when Forms Services is run in Oracle Fusion Middleware and you have to perform specific steps to deploy Forms applications. In this chapter you will also review the basic configuration files. After installation is completed, you can use the information in this chapter to change your initial configuration or make modifications as per requirement.

The following sections are included:

• Oracle Forms Services in Action

• Configuration Files

• Application Deployment

• Client Configuration Considerations

3.1 Oracle Forms Services in Action

This section describes the steps to run Forms Services in Oracle Fusion Middleware and how the configuration files are used, with the assumption that the Forms servlet helps in generating the initial HTML page.

Be aware that if you run an out-of-the-box Forms URL with no arguments they 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 their environment 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 the Weblogic Managed Server is running on port 9001 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 starts the Web browser and goes to a URL such as:

   http://example.com:9001/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 (OHS) 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_12.2.1/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 baseHTML or basejnlp file to use, based on (a) what browser (user-agent) made the request, (b) what platform the browser is running on, and (c) the settings of various parameters in the formsweb.cfg file.

   • Reads the baseHTML file, and returns the contents as an HTML (or JNLP) page to the user's Web browser, 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 baseHTML file contains the text %form%. This is replaced with the value "hrapp".

5. Depending on which baseHTML file the Forms servlet selected, the HTML page returned to the Web browser contains an applet, object embed, or jnlp tag to start the Forms applet (thin client). The Forms client runs in the JVM environment provided by Oracle Java plug-in, Web Start, or standalone Java executible, 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:9001/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 baseHTML 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). You can also specify the directory in formsweb.cfg (for example, form=c:\<path>\myform).

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 Web browser, any pending updates are lost.

3.2 Configuration Files

This section introduces the basic files used to configure Forms applications.

This following sections are included:

• Oracle Forms Configuration Files

• Forms Java EE Application Deployment Descriptors

• Oracle HTTP Listener Configuration File

• Standard Fonts and Icons File

• baseHTML (template) Files

• WebUtil Configuration Files and Template HTML Files

  Note:

  Location of files are given relative to the DOMAIN_HOME directory. Forward slashes should be replaced by back slashes on Windows. For information about terminology used such as Middleware home, Oracle home, Oracle instance, and so on, see Starting and Stopping Oracle Fusion Middleware in Administering Oracle Fusion Middleware.

For advanced configuration topics, see Configuring and Managing Forms Services.

3.2.1 Oracle Forms Configuration Files

Oracle Forms configuration files allow you to specify parameters for your Forms. You can manage these files through the Oracle Fusion Middleware Control.

These configuration files include:

• default.env

• formsweb.cfg

• ftrace.cfg

Note:

For a list of Forms configuration files and their respective locations, see Table C-1.

3.2.1.1 default.env

Location: $DOMAIN_HOME/config/fmwconfig/servers/<MANAGED_SERVER>/applications/<appname>_<appversion>/config

Typically, this location is $DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_12.2.1/config

This file contains environment settings for Forms run time. On UNIX and Linux, default.env includes the PATH and LD_LIBRARY_PATH.

For information about default.env, see Managing Environment Variables.

3.2.1.2 formsweb.cfg

Location: $DOMAIN_HOME/config/fmwconfig/servers/<MANAGED_SERVER>/applications/<appname>_<appversion>/config

Typically, this location is $DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_12.2.1/config

This Forms configuration file contains the following:

• Values for Forms run-time command line parameters, and the name of the environment file to use (envFile setting).

• Most of the servlet configuration parameter settings that you set during installation. You can modify these parameters, if needed.

Variables (%variablename%) in the base.htm file are replaced with the appropriate parameter values specified in the formsweb.cfg file and from query parameters in the URL request (if any).

For information about formsweb.cfg, see Configure Parameters with Fusion Middleware Control.

3.2.1.3 ftrace.cfg

Location: $DOMAIN_HOME//config/fmwconfig/components/FORMS/instances/<FORMS Instance Name>/server/ftrace.cfg

This file configures Forms Trace. Forms Trace replaces the functionality that was provided with Forms Runtime Diagnostics (FRD) which is available in earlier releases of Oracle Forms. Forms Trace traces the execution path through a form (for example, steps the user took while using the form).

For information about ftrace.cfg, see Tracing and Diagnostics.

3.2.2 Forms Java EE Application Deployment Descriptors

The Forms Services Java EE application EAR (Enterprise Archive) file formsapp.ear is deployed to the WLS_FORMS (Oracle WebLogic Managed Server) when you configure Oracle Forms.

This results in the creation of a directory structure under $DOMAIN_HOME /servers/WLS_FORMS/tmp/_WL_user/formsapp_12.2.1/<random_string1>/APP-INF directory that is similar to the following:

./APP-INF
./APP-INF/lib
./APP-INF/lib/frmconfig.jar
./APP-INF/lib/frmconfigmbeans.jar
./META-INF
./META-INF/application.xml
./META-INF/jazn-data.xml
./META-INF/jps-config.xml
./META-INF/mbeans.xml
./META-INF/weblogic-application.xml

This following directory structure is created under $DOMAIN_HOME/servers/WLS_FORMS/tmp/_WL_user/formsapp_12.2.1/<random_string2>/war/WEB-INF directory.

./WEB-INF
./WEB-INF/lib
./WEB-INF/lib/frmsrv.jar
./WEB-INF/web.xml
./WEB-INF/weblogic.xml

Note:

The sub-directories in $DOMAIN_HOME/servers/WLS_FORMS/tmp/_WL_user/formsapp_12.2.1 are created by the nostage deployment process of Oracle WebLogic Server. They are named with a random string. For example, e18uoi, wb1h9e and so on.

Deployment descriptors:

• application.xml and weblogic-application.xml define the structure of the EAR file.

• web.xml defines the aliases frmservlet and lservlet for the Forms servlet and the Forms Listener servlet.

• weblogic.xml defines the context parameters and any user defined virtual directory mappings.

3.2.3 Oracle HTTP Listener Configuration File

To configure Oracle HTTP Listener for Oracle Forms Services you have to use specific configuration files.

Location: $DOMAIN_HOME/config/fmwconfig/components/OHS/<OHS INSTANCE NAME>/moduleconf

forms.conf is the Oracle HTTP listener configuration file for Oracle Forms Services. It includes Forms Services related directives, like Forms WebLogic Managed Server handler mappings.

To configure Oracle HTTP Server for use with Oracle Forms, see:

• Enabling Oracle HTTP Server with Oracle Forms Services

• About Editing forms.conf

• Configuring OHS

3.2.4 Standard Fonts and Icons File

Registry.dat is the file that contains the default font, font mappings, icon, and custom color schemes information that Forms Services uses.

Location: $DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_12.2.1/config/oracle/forms/registry/Registry.dat

For information about Registry.dat, see Deploying Fonts, Icons, and Images Used by Forms Services.

3.2.5 baseHTML (template) Files

Location: $DOMAIN_HOME/config/fmwconfig/components/FORMS/instances/<Forms Instance Name>/server

When you generate the HTML page that is used to start an Oracle Forms application, one the following are used as templates by the Forms servlet:

1. base.htm

2. basejpi.htm

3. basesaa.txt

4. base.jnlp

5. basejpi_jnlp.htm

Oracle recommends that you make configuration changes in the formsweb.cfg file using Oracle Fusion Middleware Control and avoid editing these files. To change the baseHTML files, create your own versions and reference them from the formsweb.cfg file by changing the appropriate settings.

3.2.6 WebUtil Configuration Files and Template HTML Files

You have to use specific files to configure WebUtil at run time

For information about using WebUtil at design time, see the Oracle Forms Developer Online Help. The following are the WebUtil configuration files:

• Default webutil.cfg

• Default webutilbase.htm

• Default webutiljpi.htm

• Default webutil.jnlp

• Default webutilsaa.txt

3.2.6.1 Default webutil.cfg

Location: $DOMAIN_HOME/config/fmwconfig/components/FORMS/instances/<Forms Instance Name>/server

This file provides all of the configuration settings for WebUtil, including:

• Logging Options

• Installation Options

• File Upload and Download Options

• Server Side Logging Options for logging errors and log messages

3.2.6.2 Default webutilbase.htm

Location: $DOMAIN_HOME/config/fmwconfig/components/FORMS/instances/<Forms Instance Name>/server

This is the default baseHTML file for running a WebUtil enabled form using a generic APPLET tag.

3.2.6.3 Default webutiljpi.htm

Location: $DOMAIN_HOME/config/fmwconfig/components/FORMS/instances/<Forms Instance Name>/server

This is the default baseHTML file for running a WebUtil enabled form using the Java Plugin. For example, this file can be used when running a WebUtil enabled form with Firefox on UNIX.

3.2.6.4 Default webutil.jnlp

This is the default basejnlp file for running a WebUtil enabled form with Java Web Start or Enbedded JNLP.

Location: $DOMAIN_HOME/config/fmwconfig/components/FORMS/instances/<Forms Instance Name>/server

3.2.6.5 Default webutilsaa.txt

This is the default basesaa file for running a WebUtil enabled form with the Forms Standalone Launcher (FSAL).

Location: $DOMAIN_HOME/config/fmwconfig/components/FORMS/instances/<Forms Instance Name>/server

3.2.7 Managing Configuration Template and Key Binding Files

The Forms Enterprise Manager Fusion Middleware Control, Advanced Configuration page is used to add, edit, and delete configuration template and key binding files using a free text editor.

On the Forms Enterprise Manager Fusion Middleware Control Home page, click Advanced Configuration to the opens the Advanced Configuration page.

The Advanced Configuration page shows the Select Category and Select File list box. If you select a category in Select Category list box, all the related files are displayed in the Select File list box.

The following topics are included:

• Add, Edit, and Delete a Configuration Template File

• Editing Key Binding Files

3.2.7.1 Add, Edit, and Delete a Configuration Template File

Following the steps to add / modify an existing configuration template file and delete a file on Advanced Configuration page.

To creating a file:

1. Click Create Like button to open a dialog box.

   Category and Source File Name fields are preselected based the file selected in Select File list box. If a file is not selected, you have to select a specific category.

2. Insert a name in New File Name field.

3. Click Create button, to create a new file.

   Note:

   If a file exists with the same file name, an error message is displayed.

To edit a file:

1. Select a file in Select File list box, to displays its content in Edit box.

   Note:

   The Edit box uses a free text editor.

2. In the Edit box update the content of a file and click Apply.

   Or,

   Click Revert, to discard the changes.

Note:

The file contents are read and saved with the help of an mBean operation.

To delete a file:

1. Select a category in Select Category list box.

2. Select a file in Select File list box.

3. Click Delete button to delete a specific file.

Note:

If the selected file is a user created file, a Delete confirmation dialog box is displayed. If the selected file is a shipped file, an error message showing Standard files cannot be deleted. Only user created files can be deleted, is displayed.

Figure 3-1 Deleting a File Showing Error Message

Description of "Figure 3-1 Deleting a File Showing Error Message"

3.2.7.2 Editing Key Binding Files

The steps you have to follow on the Advanced Configuration page to edit Key Binding file.

To edit Key Binding Files:

1. Click Select Key Binding Files button to open a dialog box.

   Select language field is preselected based the Key Binding file selected in Select File list box. If a file is not selected, you have to select a specific language in the Select language field. Files related to a specific language are displayed.

2. Select or unselect a file check box in the Select file(s) list box.

   Standard and non-standard file are displayed in the Select file(s) list box. 4 standard files and files whose MBeans already exist are show with selected check box. Non-standard files are show with unselected check box.

   • Select a different language to refresh the populated files list in the Select file(s) list box.

3. Click Save button, to create MBeans for any newly selected items and delete MBeans for any newly unselected items. MBeans are not deleted/added for the files whose selection is not changed.

   • You can repeat the selection process for more than one language.

   Click Save and Close button, to create MBeans for any newly selected items, delete MBeans for any newly unselected items, and close the dialog box.

   A commit confirmation dialog box shows the following message: Changes to Key Binding files are committed.

   You can also click Cancel button to discard the changes and closes the Select Key Binding Files dialog box.

Figure 3-2 Key Binding File Changes Commit Confirmation Message

Description of "Figure 3-2 Key Binding File Changes Commit Confirmation Message"

3.3 Application Deployment

Once you have created your application in Forms Developer, you are ready for application Web deployment. Oracle Forms Services accesses an application in Oracle Fusion Middleware through a specified URL.

The URL then accesses the HTTP Listener, which communicates with the Listener Servlet. The Listener Servlet starts a Forms run-time process (frmweb.exe on Windows or frmweb on UNIX and Linux) for each Forms Services session.

For information about how Forms Services run, see Oracle Forms Services in Action.

The following section are included:

• Deploying your Application

• Specifying Parameters

• Creating Configuration Sections in Fusion Middleware Control

• Specifying Special Characters in Values of Runform Parameters

• Accessing the Listener Servlet Administration Page

3.3.1 Deploying your Application

To deploy a basic form with the default parameters set up by Oracle Fusion Middleware Config Wizard:

1. Create your application in Oracle Forms Developer and save or copy the related source files (.fmb, .mmb, .pll, .olb) to the desired location on the application server where they will be hosted.

   The source files are design time files that can only be opened in Forms Developer. The executable files (.fmx, mmx, plx) are the run-time files created when you compile the source files (using the Forms Compiler) and are used for Web deployment.

   See the Help menu in Forms Developer for information about Forms Developer.

2. Using the Forms Compiler (a component of Forms Developer), generate executables from the source files. The compiler and its location can be found here:

   • On Unix platforms: FORMS_INSTANCE/bin/frmcmp.sh

   • On Microsoft Windows: ORALCE_HOME\bin\frmcmp.exe

   If no arguments are passed into the compiler at startup, it will attempt to launch its graphical user interface. Details about using the Forms Compiler can be found in the Forms Developer (Form Builder) Help. Alternatively, use the –help option to expose optional arguments. For example: frmcmp -help

   Usage example: frmcmp.sh module=myForm.fmb module_type=form compile_all=yes userid=scott/tiger@orcl

3. Modify the formsweb.cfg file so that Oracle Forms Services can access your application module. You edit this file in the Web Configuration page of Fusion Middleware Control, see Configuring Forms Services.

   Table 3-1 shows the configuration of an application called "my_application" with a form module called "form=hrapp.fmx":

   Table 3-1 Example of Configuration Section Parameter Values

   Configuration Section Name	Forms Module Name Value
   my_application	hrapp.fmx

   When configured, the Oracle Forms Services module hrapp.fmx is accessible on the Web by entering "...?config=my_application" in the browser URL (the name of the Web Configuration section in formsweb.cfg).

   Note:

   The name of the configuration section must not include spaces and must contain only alphanumeric characters.

4. Make sure the .fmx file location is specified in the FORMS_PATH environment variable.

   For example, in Windows, if your .fmx file is located in d:\my_files\applications, in the FORMS_PATH, include d:\my_files\applications. On Windows, use semicolons to separate directory locations if specifying multiple locations. On UNIX/Linux, use colons for separators. Specify this information in the Environment Configuration page for the environment file.

5. To modify an environment file, select the file in the Environment Configuration page of Fusion Middleware Control and add or edit environment variables as needed by your application. For example, you can add the environment variable shown in the following table.

   Table 3-2 Example of Environment Variable Values

   Environment Variable Name	Environment Variable Value
   NLS_LANG	NLS_LANG=GERMAN_GERMANY.WE8ISO8859P15

   If you specified these environment variables in an environment file, specify this environment file in the respective configuration section of the formsweb.cfg in the Web Configuration page.

6. Enter the name of your application in the URL as shown:

   http://example.com:9001/forms/frmservlet?

   where "example" is the hostname of your computer and "9001" is the port used by your WebLogic Manager Server

   Once you have created a configuration section, add "config=" and the name of the configuration section. In this example, the URL to access hrapp.fmx is:

   http://example.com:9001/forms/frmservlet?config=my_application

3.3.2 Specifying Parameters

There are two ways to predefine parameter values for your Oracle Forms Services applications. You can define parameters by:

• Editing your application settings in the default section of the Web Configuration page of Fusion Middleware Control. The default configuration section displays the default values that are used by Oracle Forms Services.

• Managing (adding, editing, copying, deleting) other system and user parameter values in the named application configuration section (see Creating Configuration Sections in Fusion Middleware Control). For example, in the configuration section you create for myApp, you can add or change these parameters and their values, as shown in the following table.

  Table 3-3 Example Configuration Section: Parameter Values for myApp

  Parameter Name	Parameter Value
  baseHTML	mybase.htm
  baseHTMLjpi	mybasejpi.htm
  form	hrapp.fmx
  userid	scott/tiger@orcl

Note:

Parameters specified in the named configuration section of a Web Configuration override the settings in the default section.

Note:

System Parameters cannot be overridden in the URL, while user parameters can.

3.3.3 Creating Configuration Sections in Fusion Middleware Control

Under the configuration sections you created in step 2 of Deploying your Application, you can specify parameters for your Oracle Forms Services applications. You can specify any application and system parameters that are available in the default section for Web Configuration page.

For example, you can set the look and feel of the application to the Oracle look and feel by setting the lookAndFeel parameter to the value of oracle and clicking Apply.

You can also override the default parameter values in the named configuration section. For example, to predefine the connect information of an application to scott/tiger@orcl, the parameter value for userid must be set in the named configuration section by changing the parameter value of userid to scott/tiger@orcl.

For other parameters that you can edit, see Forms Configuration Parameters.

3.3.3.1 Editing the URL to Access Oracle Forms Services Applications

You can directly type parameters in the URL that accesses your Oracle Forms Services application. Using the previous example, instead of specifying the form parameter in your configuration file, you could also type it into the URL as follows:

http://example.com:9001/forms/frmservlet?config=my_application&form=hrapp

You can use the ampersand (&) to call a combination of a form and named configuration parameters. In the above example, you are calling the form "hrapp" with the parameter settings you specified in "my_application".

Note:

Parameters specified in the URL override the parameters set in the configuration section, see Managing URL Security for Applications.

3.3.4 Specifying Special Characters in Values of Runform Parameters

Certain considerations apply if values passed to runform parameters contain special characters. This section describes these considerations, and compares the default behavior in this release with the behavior in prior releases.

Runform parameters are those that are specified in the serverArgs applet parameter of the template HTML file. The value specified for the serverArgs parameter in the template HTML file, after variable substitution, is sometimes referred to as the command-line parameters string. It consists of a series of blank-separated name=value pairs. The name must consist solely of alphanumeric or underscore characters. The value portion of a name=value pair can be an arbitrary string.

3.3.4.1 Default Behavior in the Current Release

The value of a runform parameter can be specified in one of three places:

1. In the value of the serverArgs parameter in the template HTML file (for example, base.htm).

2. In the value of a variable specified in the configuration file (for example, formsweb.cfg), which is substituted (directly or recursively) for a variable reference in (1). Such values are typically maintained using Fusion Middleware Control; see Configuring Forms Services.

3. As an attribute value in a URL, which is substituted directly for a variable reference in (1) or (2).

For case (3), URL syntax rules (as enforced by the browser and the application server) require that certain characters be entered as URL escape sequences ('%' followed by 2 hexadecimal digits representing the ASCII value of the character, for a total of three characters).

This requirement includes the % character itself (which must be entered as %25). In addition, Oracle Forms Services currently requires that the quote character ('"') be entered as %22, even if the browser and the application server allow a quote to be entered without escaping.

URL syntax rules also allow a space to be entered as a + (as an alternative to the URL escape sequence %20). However in the value of the otherparams configuration parameter, a + is treated specially; it separates name=value pairs as opposed to indicating a space embedded in the value of a runform parameter.

For example, if a runform application has user parameters param1 and param2, and you want to assign them the values 'a b' and 'c d', you do so by incorporating the following into a URL:

&otherparams=param1=a%20b+param2=c%20d

When specifying runform parameters in the template HTML files or in the configuration files (cases (1) and (2)), Forms requires URL escape sequences in some circumstances, allows them in others, and forbids them in still others.

Outside of the values of runform parameters, URL escape sequences must not be used. For example, the = in a name=value pair must always be specified simply as =, and the space that separates two adjacent name=value pairs must always be specified simply as " " (a single space character).

Within the value of a runform parameter, space (' ') must be specified as a URL escape sequence (%20). The HTML delimiter character (specified in the configuration file) must also be specified as a URL escape sequence. And when the runform parameter is specified in the template HTML file (case (1)), quote ('"') must also be specified as a URL escape sequence (%22).

Any other 7-bit ASCII character may also be specified as a URL escape sequence, although this is not required (except possibly for %, as noted below). Certain additional restrictions apply to the % character. These include:

• If the HTML delimiter is % (the default), then an occurrence of % within the value of a runform parameter must be escaped (specified as %25). (This actually follows from the requirement stated above, that the HTML delimiter character be escaped). Furthermore, variable names must never begin with two hexadecimal digits that represent a 7-bit ASCII value (that is, two hexadecimal digits, the first of which is in the range 0-7).

• If the HTML delimiter is not %, then an occurrence of % must be escaped if it is immediately followed by an octal digit and then a hexadecimal digit. It is recommended that other occurrences of '%' also be escaped; but this is not a requirement.

(You might choose to ignore this recommendation if you have existing template HTML files or configuration files created in prior releases, which use an HTML delimiter other than '%', and which contain '%' in runform parameter values).

3.3.4.2 Behavior in Previous Releases

Release 9.0.4 and later behave the same as the current release except that a quote must be escaped (%22) within the value of a runform parameter in a configuration file, and in the template HTML file.

Releases before 9.0.4 did not allow URL escape sequences in runform parameter values specified in the template HTML file or the configuration file (cases (1) and (2) above). In all three cases, it was difficult or impossible to specify certain special characters, notably space, quote, and apostrophe. Also, certain transformations were applied to the parameter value before passing it to runform. Most notably, if a value began and ended with an apostrophe, these were typically stripped off. However, these transformations were not well-defined, and they differed between the Web and client/server environments.

3.3.4.3 Obtaining the Behavior of Prior Releases in the Current Release

If your applications are dependent on the behavior of prior releases, you can obtain that behavior in the current release, by simply setting the value of the escapeparams variable to False in the configuration file (this can be accomplished using Fusion Middleware Control).

If you want to obtain the old behavior only for selected applications, you can specify different values for the escapeparams variable in different configuration sections. Applications that require the old behavior can specify a configuration section in which the escapeparams variable is set to False; applications that require (or tolerate) the behavior in the current release can specify a configuration section in which the escapeparams variable is set to True.

3.3.4.4 Considerations for Template HTML Files

If you are creating your own template HTML files, consider the following:

It is recommended that a reference to the escapeparams variable (the string %escapeparams%, if '%' is the HTML delimiter character) appear at the beginning of the value of the serverArgs applet parameter, followed by a space. See the shipped base.htm file for an example.

References to the escapeparams variable must appear nowhere else in the template HTML file. If you choose to enclose the value of the serverArgs applet parameter in apostrophes instead of quotes, then within the value of a runform parameter in your template HTML file, apostrophes must be escaped (%27). Quotes do not require escape sequences.

It is permissible to omit the reference to the escapeparams variable from the beginning of the value of the serverArgs applet parameter. This results in the behavior of prior releases, regardless of the value specified in the configuration file for the escapeparams variable.

3.3.4.5 Considerations for Static HTML Pages

If you are invoking the runform engine using static HTML, and you want to obtain the behavior in the current release, then you must take certain steps.

The basic rule is that your static HTML must look like the HTML generated by the Forms servlet. Specifically, the value of the serverArgs applet parameter must begin with the string escapeparams=true (case-insensitive).

Also, in the value portion of each name=value pair, in the value of the serverArgs applet parameter, certain characters must be specified by a URL escape sequence, as listed in the following table.

Table 3-4 URL Escape Sequences for Static HTML pages

Characters that must be escaped	URL Escape Sequence
newline ' \n '	%0a
space ' '	%20
quote ' " '	%22
percent ' % '	%25
apostrophe ' ' '	%27
left parenthesis ' ( '	%28
right parenthesis ' ) '	%29

It is also permissible to escape other 7-bit ASCII characters in the value portion of a name=value pair.

Here's an example of what the serverArgs applet parameter might look like in static HTML. This is for a form named "my form" (quotes not included), which is being passed the value "foo'bar" (quotes again not included) to the user-defined parameter named myparam.

<PARAM NAME="serverArgs" VALUE="escapeparams=true module=my%20form userid=scott/tiger@mydb myparam=foo%27bar">

3.3.5 Accessing the Listener Servlet Administration Page

You can display a test page for the Listener Servlet by accessing the following URL:

http://<hostname>:<port>/forms/frmservlet/admin

The information displayed depends on the value of the initialization parameter TestMode. This parameter is set in the $DOMAIN_HOME/servers/WLS_FORMS/tmp/_WL_user/formsapp_12.2.1/<random_string>/war/WEB-INF /web.xml file. An example is shown below:

<init-param>
<!-- Display sensitive options on the /admin page -->
    <param-name>TestMode</param-name>
    <param-value>true</param-value>
</init-param>

3.4 Client Configuration Considerations

You can use the available client configurations according to the requirements.

The following client configurations are available:

• Applet Embedded in HTML

  • Default configuration

  • Full support for SSO, SSO Logout, and Java Script integration

  • Requires Java Plugin and browser

• JNLP Embedded in HTML

  • Full support for SSO, SSO Logout, and Java Script integration

  • Requires Java Plugin and browser

  • Base64 encodes JNLP code in client side html source

• Java Web Start

  • Supports SSO (when used with browser)

  • No support for SSO Logout or Java Script Integration

  • Requires either JDK or Java Plugin (JRE) installation

  • Presents application with a native appearance

• Standalone (Forms Standalone Launcher)

  • No support for SSO, SSO Logout, or Java Script Integration

  • Requires either JDK or Java Plugin (JRE) installation

  • Browser not required

  • Presents application with a native appearance

  • Example page available at: http://server:9001/forms/html/fsal.htm

  Note:

  An example of how to use each of these configurations can be found in the Forms web configuration, formsweb.cfg.

3.4.1 Client Browser Support

The following links provide information about client browser, Java version and the latest supported platforms. You can also view the Oracle Forms applications using Oracle Java Plug-in.

• For Oracle Support, see https://support.oracle.com.

• For product certification requirement documents, see Oracle Fusion Middleware Supported System Configurations page.

• For system requirement information, see Oracle Fusion Middleware System Requirements and Specifications document.

3.4.2 How Configuration Parameters and BaseHTML Files are Tied to Client Browsers

When a user requests an Oracle Forms application from a browser (for example, by clicking a link to the application's URL), the Forms servlet:

1. Detects which browser is being used.

2. Selects the appropriate baseHTML file using the following table:

   Table 3-5 baseHTML file descriptions

   Detected Browser	Base HTML file used
   Internet Explorer	basejpi.htm
   Mozilla FireFox	basejpi.htm
   All other browsers and Macintosh clients	base.htm

3. Replaces variables (%variablename%) in the baseHTML file with the appropriate parameter values specified in the Forms servlet.initArgs file, formsweb.cfg file, and from query parameters in the URL request (if any).

4. Sends the HTML file to the user's browser.