Skip Headers

Oracle® Application Server Forms Services Deployment Guide 10g Release 2 (10.1.2) B14032-02 |
| Library | Product | Contents | Index

Previous | Next |

# 4 Configuring Forms Services

This chapter contains the following sections:

- Section 4.1, "How Oracle Application Server Forms Services Launches a Forms Application"

- Section 4.2, "Enterprise Manager and Oracle Forms"

- Section 4.3, "Configuring Forms Services"

- Section 4.4, "Configuring Environment Variables with Enterprise Manager"

- Section 4.5, "Managing User Sessions"

- Section 4.6, "Managing URL Security for Applications"

- Section 4.7, "Creating Your Own Template HTML Files"

- Section 4.8, "Including Graphics in Your Oracle Forms Application"

- Section 4.9, "Deploying Icons and Images Used by Forms Services"

- Section 4.10, "Enabling Language Detection"

## 4.1 How Oracle Application Server Forms Services Launches a Forms Application

When a user first starts an Oracle Forms application (by clicking a link to the application's URL), the baseHTML file is read by Forms Servlet. Any variables (%variablename%) in the baseHTML file are replaced with the appropriate parameter values specified in the formsweb.cfg file, and from query parameters in the URL request (if any).

You can easily modify the configuration files with Oracle Enterprise Manager 10g Application Server Control Console as your needs change.

## 4.2 Enterprise Manager and Oracle Forms

The Enterprise Manager Application Server Control Console user interface that is shipped with Forms Services is a Web-based tool that you launch from your default browser. The default URL is:

    http://<computer.domain>:1156

Note: For information on how to launch Enterprise Manager, see the Oracle Enterprise Manager Advanced Configuration.

For Forms Services, use the Web-based Enterprise Manager Application Server Control Console to:

- Monitor metrics for a Forms Services instance. See Chapter 10, "Monitoring Forms Services Instances" for more information.

- Monitor metrics for user sessions. See Chapter 10, "Monitoring Metrics for User Sessions" for more information.

- Allow or deny new user sessions. See Chapter 4, "Allowing New Users Sessions" and Chapter 4, "Disabling New User Sessions" for more information.

- Terminate user sessions. See Chapter 4, "Terminating a User Session on a Forms Services Instance" for more information.

- Configure parameters for a Forms Services instance. See Chapter 4, "Configuring Parameters with Application Server Control Console" for more information.

- Configure Forms Trace and monitor trace metrics. See Chapter 8, "Configuring Forms Trace" and Chapter 8, "Monitoring Forms Services Trace Metrics" for more information.

- Configure multiple environment files. See Chapter 4, "Configuring Environment Variables with Enterprise Manager" for more information.

- Use available Forms Services utilities and runtime pooling. See Chapter 10, "Forms Services Utilities" and Chapter 10, "Tuning OracleAS Forms Services Applications" for more information.

### 4.2.1 Using Enterprise Manager Application Server Control to Manage Forms Sessions

By default, Enterprise Manager Application Server Control provides some information about Forms which allows you to centrally modify the configuration files. But you won't experience the full functionality that Enterprise Manager can provide for Forms unless you do the following:

1. In the Forms configuration file (formsweb.cfg) make sure the following variable is set in the default section.

   `em_mode=1`

   This will let Application Server Control show user information for each running Forms application. Only sessions created after setting `em_mode` to 1 will be shown. By default, this value is `0,` which is off.

2. In the Forms configuration file (formsweb.cfg) make sure the following variable is set. You can either set it in the default section or in a specific application section. As with step 1, you can set this variable using Application Server Control:

   `allow_debug=true`

   This will let you turn tracing on and off.

3. (Windows only) For the middle tier user that installed Oracle Application Server, you need to give them the "Log on as a batch job" privilege. Logon as either that user, or another user with administrator privileges. Select Administrative Tools in the Control Panel. Then select Local Security Settings| Local Policies | User Right Assignment. Add the username of the user who installed Oracle Application Server.

4. (Windows only) As the user who installed Oracle Application Server or as a user with administrator privileges, bring up the Windows Services, which can be found in the Control Panel. Find the Oracle/xxxxxx/ProcessManager service. Right-click it and choose Properties. In the Logon tab, make sure Allow service to interact with desktop is selected.

5. (Windows only) You will need to restart this service. Note that even after it is restarted, it can take up to several minutes for the changes to take effect in Application Server Control.

### 4.2.2 Configuring Enterprise Manager Grid Control to Manage Forms Services

When you install Forms Services, the Oracle Universal Installer automatically edits Enterprise Manager Grid Control targets.xml file. The targets.xml file contains a list of all the services to be managed by Enterprise Manager.

The first time you use Enterprise Manager to monitor Forms Services, you must perform the following steps for each Forms Services instance to be monitored.

See the Enterprise Manager documentation for information on how to use the Application Server Control Console to access the Enterprise Manager Administration page for a node. (You will need to provide an administrator's username and password.)

To configure Enterprise Manager Grid Control to Manage Forms Services:

1. On the Agent Administration page, all services that are being monitored are listed under the Agent Monitored Targets heading.

2. Select the radio button next to the Forms instance to be configured for Enterprise Manager.

3. Click Edit.

4. Provide the ORACLE_HOME and URL for the Forms instance.

5. Click OK.

   Note: See the Enterprise Manager help system for more information about other tasks that you can complete on this page.

### 4.2.3 Accessing Forms Services with Application Server Control Console

To perform most management tasks for a Forms server using Application Server Control Console, you start by navigating to the Forms Home page for the Forms Server in Application Server Control Console.

To navigate to the Forms Home page for a Forms Server in the Application Server Control Console:

1. Using Application Server Control Console, navigate to the home page for the application server that contains Forms server you want to manage.

   For introductory information about using the Enterprise Manager Application Server Control Console, see "Introduction to Administration Tools" in the Oracle Application Server Administrator's Guide.

2. In the System Components section on the application server home page, click the link for the Forms server that you want to manage. This displays the Forms home page for the Forms server in the Application Server Control Console.

## 4.3 Configuring Forms Services

Use the Configuration page in Application Server Control Console to configure Forms Services. This page manages all changes in the formsweb.cfg file for you.

Note: If you manually edit any of the configuration or environment files, you'll need to restart Enterprise Manager as well as restart all Distributed Configuration Management (DCM) processes so that Enterprise Manager can read all changes. If you do not restart Enterprise Manager as well as DCM processes, any changes that you make through Oracle Enterprise Manager 10g will overwrite any manual changes you've made to these files. These DCM processes include: `emctl stop em` `dcmctl stop` `opmnctl stopall` `opmnctl startall` `dcmctl start` `emctl start em`

Note: You should backup the formsweb.cfg and default.env files before editing them with Enterprise Manager.

To configure Forms Services:

1. Start the Application Server Control Console.

2. From the Application Server Control Console main page, select the link to the OracleAS Forms Services instance that you want to configure.

3. From the Forms Services instance, select the Configuration tab.

4. Select Forms Web Configuration from the View pulldown list.

   - To create a new section in the formsweb.cfg file, click Create New Section and enter a name for this section on the next page

   - To delete a section in the formsweb.cfg file, click the radio button next to the section to be deleted, then click Delete and confirm the deletion on the next page.

     Note: As with most Web applications, it is easy to lose unsaved changes by switching pages. Be sure to save any changes you make through Application Server Control Console to Forms configuration or environment files before proceeding to other pages. The length of time it takes for changes to be saved is affected by the number of lines you have changed. For example, an additional fifty lines of comments will take longer to save than just the deletion of a single entry.

### 4.3.1 Configuring Parameters with Application Server Control Console

For a description and the location of the Forms Servlet configuration file (formsweb.cfg), see Chapter 3, "formsweb.cfg".

#### 4.3.1.1 Parameters that Specify Files

The four baseHTML parameters should point to appropriate files. Typically, the following values and their parameters should appear in the default configuration section, as shown in Table 4-1, "Default Configuration Parameters that Specify Files":

Table 4-1 Default Configuration Parameters that Specify Files

Parameter | Value
--- | ---
baseHTML | base.htm
`baseHTMLJinitiator` | basejini.htm
`baseHTMLjpi` | basejpi.htm
`envFile` | default.env

All of these parameters specify file names. If no paths are given (as in this example), the files are assumed to be in the same directory as the Forms Servlet configuration file (formsweb.cfg), that is `ORACLE_HOME/forms/server`.

### 4.3.2 Managing Configuration Sections

You create new configuration sections from the Configuration tab of Application Server Control Console, which creates the named configurations in the formsweb.cfg file. These configurations can be requested in the end-user's query string of the URL that is used to run a form.

To create a new configuration section:

1. Start the Enterprise Manager Application Server Control Console.

2. From the Application Server Control Console main page, select the link to the Forms Services instance that you want to configure.

3. From the Forms Services instance, select the Configuration tab.

4. Click Create New Section at the top of the Configuration tab.

   The Forms New Section Name page appears.

5. Enter a name for your new configuration and click OK.

6. If you enter a description of your new section, make sure you save it clicking Apply before editing the section and adding parameters.

For example, to create a configuration to run Forms in a separate browser window with a "generic" look and feel, create a new section and add the following parameters from Table 4-2, "Sample Parameters to Add to a New Configuration Section":

Table 4-2 Sample Parameters to Add to a New Configuration Section

Parameter | Value
--- | ---
forms | <module>
separateFrame | True
lookandfeel | Generic

Your users would type the following URL to launch a form that uses the "sepwin" (or whatever name you applied) configuration:

    http://server:port/forms/frmservlet?config=sepwin

See Appendix C, "Default formsweb.cfg File" for other examples of special configurations.

#### 4.3.2.1 Duplicating a Named Configuration

You can make a copy of a named configuration for backup purposes, or create new configuration sections from duplicates.

To duplicate a named configuration:

1. Select the radio button next to the section to be duplicated.

2. Click Duplicate.

3. On the next page enter a new, unique name for the duplicated section and click OK.

   A new section with exactly the same parameters, parameter values and comments as the section you are duplicating is created.

#### 4.3.2.2 Deleting Named Configurations

When you delete a named configuration, you delete all the information within it. If you only want to delete specific parameters, see Section 4.3.3, "Managing Parameters".

To delete a named configuration:

1. Start the Enterprise Manager Application Server Control Console.

2. From the Application Server Control Console main page, select the link to the Forms Services instance that you want to configure.

3. From the Configuration, select the radio button next to the configuration section you want to delete.

4. Click Delete.

   The Confirmation page appears.

5. Click OK.

   The configuration section is deleted.

   Application Server Control Console returns to the Configuration tab and displays the remaining configurations.

### 4.3.3 Managing Parameters

Use Application Server Control Console to manage parameters within a named configuration. You can add, edit, or delete parameters from the Edit Section page of Application Server Control Console.

To edit a parameter in a configuration section:

1. From the Configuration tab of Enterprise Manager Application Server Control Console, select the radio button next to the configuration section that contains the parameter that you want to edit.

2. Click Edit at the top of this page.

   The Edit Section page appears for that selected configuration.

3. Select the radio button next to the parameter you want to edit.

4. Make your changes in the text fields.

5. Click Apply.

   Your changes are saved.

To add a parameter to a configuration:

1. From the Configuration tab of Application Server Control Console, select the radio button next to the configuration section to which you want to add a parameter.

2. Click Edit at the top of this page.

   The Edit Section page appears for that selected configuration.

3. Enter a name and value for the new parameter and click Add New Parameter.

   The Edit Section page refreshes and displays the new parameter.

4. Add a description for the new parameter, and click Apply.

5. To return to the Forms page, click Forms in the breadcrumb trail.

To delete a parameter in a configuration:

1. To edit a configuration section, select the radio button next to it and click Edit at the top of this page.

   The Edit Section page appears for the selected configuration.

2. Select the radio button next to the parameter you want to delete.

3. Click Delete.

4. Confirm the deletion on the Confirmation page that appears.

   The parameter is deleted from the configuration section.

### 4.3.4 Default Forms Configuration Parameters

Table 4-3, "System Default Configuration Parameters" describes the default forms configuration parameters in the formsweb.cfg file. For additional information on OracleAS Single Sign-On parameters, see Chapter 6, "Enabling OracleAS Single Sign-On for an Application".

These sections include:

- Section 4.3.4.1, "System Default Configuration Parameters"

- Section 4.3.4.2, "Runform parameters (serverArgs parameters)"

- Section 4.3.4.3, "HTML page title, attributes for the BODY tag and HTML to add before and after the form"

- Section 4.3.4.4, "Applet or Object Parameters"

- Section 4.3.4.5, "Parameters for JInitiator"

- Section 4.3.4.6, "Parameters for the Sun Java Plug-in"

- Section 4.3.4.7, "Enterprise Manager Configuration Parameters"

- Section 4.3.4.8, "Oracle Internet Directory Configuration Parameters"

#### 4.3.4.1 System Default Configuration Parameters

These parameters control the behavior of the Forms Servlet. They can only be specified in the servlet configuration file (formsweb.cfg) and cannot be specified as URL query parameters.These parameters are described in Table 4-3, "System Default Configuration Parameters":

Table 4-3 System Default Configuration Parameters

Parameter | Required / Optional | Parameter Value and Description
--- | --- | ---
`baseHTML` | required | The default base HTML file.
`baseHTMLJInitiator` | required | Physical path to HTML file that contains JInitiator tags.
`connectionDisallowedURL` | optional | This is the URL shown in the HTML page that is not allowed to start a new session.
`baseHTMLjpi` | optional | Physical path to HTML file that contains Java Plug-in tags. Used as the baseHTML file if the client browser is not on Windows and the client browser is either Netscape or IE without the IE native settings.
`HTMLdelimiter` | required | Delimiter for variable names. Defaults to %.
`workingDirectory` | required | Defaults to `ORACLE_HOME/forms` if not set.
`envFile` | required | This is set to default.env in the formsweb.cfg file.
`defaultcharset` | optional | Specifies the character set to be used in servlet requests and responses. Defaults to ISO-8859-1 (also known as Latin-1). Ignored if the servlet request specifies a character set (e.g. in the content-type header of a POST). The values of this parameter may be specified either as an IANA character set name (e.g. SHIFT_JIS) or as an Oracle character set name (e.g. JA16SJIS). It should match the character set specified in the NLS_LANG environment variable, and it should also be a character set that the browser is capable of displaying. Also, if the browser allows multibyte characters to be entered directly into a URL, e.g. using the IME, as opposed to URL escape sequences, and if you wish to allow end users to do this, then the value of this parameter should match the character set that the browser uses to convert the entered characters into byte sequences. Note: If your configuration file contains configuration sections with names that contain characters other than 7-bit ASCII characters, then the following rules apply. If a `config` parameter is specified in a URL or in the body of a POST request with no specified character set, and the value contains non-7-bit ASCII characters, then the value is interpreted using a character set whose name is derived from the value of the `defaultcharset` parameter. However, only the language-dependent default section and the language-independent default section of the configuration file is searched for the `defaultcharset` parameter. No other configuration section is searched because the name is not yet known.
`IE` | recommended if there are users with Internet Explorer 5.0 or above browsers | Specifies how to execute the Forms applet under Microsoft Internet Explorer 5.0 or above. If the client is using an Internet Explorer 5.0 or above browser, either the native JVM or JInitiator can be used. A setting of "JInitiator" uses the basejini.htm file and JInitiator. A setting of "Native" uses the browser's native JVM.
`log` | optional | Supports running and debugging a form from the Builder. Default value is `Null`.
`jvmcontroller` | optional | Valid values: See Section 7.5.8.2, "Starting a JVM Controller at the Command Line". In addition, you can specify no JVM. Default value: none This parameter can be set globally in the default section, or any application section can choose to override it. This tells the Forms runtime process which JVM controller to use. It corresponds to the jvmcontroller parameter for the dejvm executable (see section 2.3, table 1). If jvmcontroller does not have a value, then the Oracle Forms Runtime Process will start its own in-process JVM, which means that the Java Importer uses pre-10g behavior.

#### 4.3.4.2 Runform parameters (serverArgs parameters)

All parameters from here on match variables (`%parameterName%`) in the baseHTML file. These variables are replaced with the parameter values specified in the URL query string, or failing that, in the formsweb.cfg file. See Chapter 3, "Specifying Special Characters in Values of Runform Parameters" for information about how runform handles certain special characters that are specified in runform parameter values. These runform parameters are described in Table 4-4, "Runform Parameters (serverArgs Parameters)":

Table 4-4 Runform Parameters (serverArgs Parameters)

Parameter | Required / Optional | Parameter Value and Description
--- | --- | ---
`clientDPI` | optional | Specifies the dots per inch (DPI) and overrides the DPI setting returned by the JVM, allowing you to manage varying DPI settings per platform. For example, a form developed on the Win32 platform may not display properly on the UNIX platform due to varying DPI values. The clientDPI value can be any positive integer. Oracle recommends that you use an integer between 50 and 200, e.g. `<param name="clientDPI" value="200">`.
`escapeparams` | optional | Set this parameter to `false` if you want runform to treat special characters in runform parameters as it did in releases prior to 9.0.4.
`heartBeat` | optional | Use this parameter to set the frequency at which a client sends a packet to the server to indicate that it is still running. Define this integer value in minutes or in fractions of minutes, for example, 0.5 for 30 seconds. The default is two minutes. If the heartbeat is less than `FORMS_TIMEOUT`, the user's session will be kept alive, even if they are not actively using the form.
`form` | required | Specifies the name of the top level Forms module (fmx file) to run.
`userid` | optional | Login string. For example: `scott/tiger@ORADB`.
`otherparams` | optional | This setting specifies command line parameters to pass to the Forms runtime process in addition to `form` and `userid`. Default is: `otherparams=buffer_records=%buffer% debug_messages=%debug_messages% array=%array% obr=%obr% query_only=%query_only% quiet=%quiet% render=%render% record=%record% tracegroup=%tracegroup% log=%log% term=%term%` Note: Special syntax rules apply to this parameter when it is specified in a URL: a + may be used to separate multiple name=value pairs (see Section 3.3.4, "Specifying Special Characters in Values of Runform Parameters" for more information). For production environments, in order to provide better control over which runform parameters end users can specify in a URL, use the `restrictedURLparams` parameter.
`debug` | optional | Allows running in debug mode. Default value is `No`.
`buffer` | optional | Supports running and debugging a form from the Builder. Sub argument for `otherparams` Default value is `No`.
`debug_messages` | optional | Supports running and debugging a form from the Builder. Sub argument for `otherparams` Default value is `No`.
`allow_debug` | optional | When set to true, all admin functions from the `forms/frmservlet/admin` screen are activated. `forms/frmservlet/xlate` runs Forms Trace Xlate on a specified trace file. This parameter must be set to `true` before trace logs can be viewed from the User Sessions screen. The default value is `false`; an inline message displays which says that tracing can be viewed only if `allow_debug=true`.
`array` | optional | Supports running and debugging a form from the Builder. Default value is `No`.
`query_only` | optional | Supports running and debugging a form from the Builder. Default value is `No`.
`quiet` | optional | Supports running and debugging a form from the Builder. Default value is `Yes`.
`render` | optional | Supports running and debugging a form from the Builder. Default value is `No`.
`host` | optional | Supports running and debugging a form from the Builder. Default value is `Null`.
`port` | optional | Supports running and debugging a form from the Builder. Default value is `Null`.
`record` | optional | Supports running and debugging a form from the Builder. Default value is `Null`.
`tracegroup` | optional | Supports running and debugging a form from the Builder. Default value is `Null`.
`log` | optional | Supports running and debugging a form from the Builder. Default value is `Null`.
`term` | optional | Supports running and debugging a form from the Builder. Default value is `Null`.
`em_trace` | For internal use only. |

#### 4.3.4.3 HTML page title, attributes for the BODY tag and HTML to add before and after the form

For security reasons these parameters may not be set using URL query parameters, as described in Table 4-5, "HTML Page Parameters":

Table 4-5 HTML Page Parameters

Parameter | Required / Optional | Parameter Value and Description
--- | --- | ---
`pageTitle` | optional | HTML page title, attributes for the BODY tag, and HTML to add before and after the form.
`HTMLbodyAttrs` | optional | Attributes for the <BODY> tag of the HTML page.
`HTMLbeforeForm` | optional | HTML content to add to the page above the area where the Forms application will be displayed.
`HTMLafterForm` | optional | HTML content to add to the page below the area where the Forms application will be displayed.

#### 4.3.4.4 Applet or Object Parameters

The following parameters in Table 4-6, "Applet or Object Parameters" are specified in the baseHTML file as values for object or applet parameters. For example: `<PARAM NAME="serverURL" VALUE="%serverURL%">`

Table 4-6 Applet or Object Parameters

Parameter | Required / Optional | Parameter Value and Description
--- | --- | ---
`serverURL` | required | `/forms/lservlet` (see Chapter 1.5, "Forms Listener Servlet".)
`codebase` | required | Virtual directory you defined to point to the physical directory `ORACLE_HOME/forms/java`, where, by default, the applet JAR files are downloaded from. The default value is `/forms/java`.
`imageBase` | optional | Indicates where icon files are stored. Choose between: `codeBase`, which indicates that the icon search path is relative to the directory that contains the Java classes. Use this value if you store your icons in a JAR file (recommended). `documentBase`, which is the default. In deployments that make use of the Forms Server CGI, you must specify the icon path in a custom application file.
`logo` | optional | Specifies the .GIF file that should appear at the Forms menu bar. Set to NO for no logo. Leave empty to use the default Oracle logo
`restrictedURLparams` | optional | Specified by an administrator to restrict a user from using certain parameters in the URL. If the number of parameters is more than one, then they should be separated by a comma. The `restrictedURLparams` itself cannot be the value of this parameter i.e., `restrictedURLparams`. Default value is `HTMLbodyAttrs`,`HTMLbeforeForm`, `pageTitle`,`HTMLafterForm`,`log`,`allow_debug`,`allowNewConnections`
`formsMessageListener` | optional | Forms applet parameter.
`recordFileName` | optional | Forms applet parameter.
`width` | required | Specifies the width of the form applet, in pixels. Default is 650.
`height` | required | Specifies the height of the form applet, in pixels.Default is 500.
`separateFrame` | optional | Determines whether the applet appears within a separate window. Legal values: True or False.
`splashScreen` | optional | Specifies the .GIF file that should appear before the applet appears. Set to `NO` for no splash. Leave empty to use the default splash image. To set the parameter include the file name (for example, myfile.gif) or the virtual path and file name (for example, images/myfile.gif).
`background` | optional | Specifies the .GIF file that should appear in the background. Set to `NO` for no background. Leave empty to use the default background.
`lookAndFeel` | optional | Determines the applications look-and-feel. Legal values: Oracle or Generic (Windows look-and-feel).
`colorScheme` | optional | Determines the application's color scheme. Legal values: Teal, Titanium, Red, Khaki, Blue, Olive, or Purple. Note: `colorScheme` is ignored if lookAndFeel is set to Generic.
`serverApp` | optional | Replace default with the name of your application file (if any). Use application classes for creating application-specific font mapping and icon path settings. To set the parameter include the file name if file is in `ORACLE_HOME/forms/java/oracle/forms/registry` or include the virtual path and file name.
`archive` | optional | Comma-separated list of archive files that are used when the browser detected is neither Internet Explorer using native JVM nor JInitiator. (The default is frmall.jar.) To set the parameter include the file name if the file is in the codebase directory or include the virtual path and file name.
`archive_jinit` | optional | Comma-separated list of JAR file(s) that is used when the browser detected is JInitiator. (The default is frmall_jinit.jar.) To set the parameter include the file name if the file is in the codebase directory or include the virtual path and file name.
`archive_ie` | optional | Comma-separated list of CAB file(s) that is used when the browser detected is Internet Explorer using native JVM. (The default is `frmall.cab`.)
`networkRetries` | optional | In situations of high load or network failures, you can specify the number of times (up to 10) the client will attempt to send a request to the intended servlet engine. The default setting is 0, in which case the Forms session will terminate after one try.
`mapFonts` | optional | `<PARAM NAME = "mapFonts" VALUE = "yes" >` to trigger font mapping. As a result of some font rendering code changes in JDK 1.3, the font heights set in JDK 1.1 increased in JDK 1.3. As this may cause display issues, you can map the JDK 1.3 fonts so that the font sizes are the same as they were in JDK 1.1.

#### 4.3.4.5 Parameters for JInitiator

The following parameters are specific to JInitiator, as described in Table 4-7, "Parameters for JInitiator":

Table 4-7 Parameters for JInitiator

Parameter | Required / Optional | Parameter Value and Description
--- | --- | ---
`jinit_download_page` | required (Netscape only) | If you create your own version of the Jinitiator download page, set this parameter to point to it. Default is `/forms/jinitiator/us/JInitiator/jinit.download.htm`.
`jinit_classid` | required (IE only) | Default is `clsid:CAFECAFE-0013-0001-0017-ABCDEFABCDEF`
`jinit_exename` | required | Default is `jinit.exe#Version=1.3.1.17`
`jinit_mimetype` | required (Netscape only) | Default is `application/x-jinit-applet;version=1.3.1.17`
`baseHTMLJInitiator` | required | Physical path to HTML file that contains JInitiator tags.

#### 4.3.4.6 Parameters for the Sun Java Plug-in

The following parameters are for use with the Sun Java Plug-in, as described in Table 4-8, "Parameters for Sun's Java Plug-in":

Table 4-8 Parameters for Sun's Java Plug-in

Parameter | Required / Optional | Parameter Value and Description
--- | --- | ---
`jpi_codebase` | required | Sun's Java Plug-in codebase setting
`jpi_classid` | required | Sun's Java Plug-in class id
`jpi_download_page` | required | Sun's Java Plug-in download page

#### 4.3.4.7 Enterprise Manager Configuration Parameters

The following parameters are for configuring Enterprise Manager, as described in Table 4-9, "Enterprise Manager Configuration Parameters":

Table 4-9 Enterprise Manager Configuration Parameters

Parameter | Required / Optional | Parameter Value and Description
--- | --- | ---
`em_mode` | required | 1 is to enable. 0 is to disable. 1 indicates that all Enterprise Manager information is available, including metrics and servlet status. 0 indicates that only configuration information is available.
EndUserMonitoringEnabled | Optional | Indicates whether End User Monitoring integration is enabled.
EndUserMonitoringURL | Optional | indicates where to record End User Monitoring data.

#### 4.3.4.8 Oracle Internet Directory Configuration Parameters

The following parameters are for configuring Oracle Internet Directory, as described in Table 4-10, "Oracle Internet Directory Configuration Parameters". You can only configure these parameters if you are using an OracleAS Infrastructure instance.

Table 4-10 Oracle Internet Directory Configuration Parameters

Parameter | Required / Optional | Parameter Value and Description
--- | --- | ---
`oid_formsid` | required | Configured during the OracleAS installation, so you do not need to change this.
`ORACLE_HOME` | required | Configured during the OracleAS installation, so you do not need to change this.

## 4.4 Configuring Environment Variables with Enterprise Manager

Use the Environment tab of the Enterprise Manager Application Server Control Console page to manage Environment Variables. From this page, you can add, edit, or delete environment variables as necessary.

The environment variables such as `PATH`, `ORACLE_HOME`, and `FORMS_PATH` for the Forms runtime executable (`frmweb.exe` on Windows and `frmweb` on Solaris) are defined in the Environment tab. The Listener Servlet calls the executable and initializes it with the variable values provided in the environment file, which is `ORACLE_HOME/forms/server/default.env` by default.

Any environment variable that is not defined in that page is inherited from the servlet engine (OC4J). The environment file must be named in the `envFile` parameter in the Default section of the Forms Web Configuration page.

A few things to keep in mind when customizing environment variables are:

- Environment variables may also be specified in the Windows registry. Values in the environment file override settings in the registry. If a variable is not set in the environment file, the registry value is used.

- You will need administrator privileges to alter registry values.

- You do not need to restart the server for configuration changes to take effect.

- Environment variables not set in the environment file or Windows registry are inherited from the environment of the parent process, which is the servlet engine (OC4J).

  Note: You cannot create or delete environment files through Enterprise Manager Application Server Control Console. Environment files must be created manually in `ORACLE_HOME/forms/server` with a `.env` extension. Likewise, environment files cannot be deleted from Application Server Control. For a new environment file to be picked up by Application Server Control Console and for a deleted one to disappear you will need to restart the Enterprise Manager processes: `emctl stop em` `emctl start em`

Table 4-11, "Default Environment Variables" describes important environment variables that are specified in default.env:

Table 4-11 Default Environment Variables

Environment Variable | Valid Values | Purpose
--- | --- | ---
`ORACLE_HOME` | `ORACLE_HOME` (default) | Points to the base installation directory of any Oracle product.
`PATH` | `ORACLE_HOME\bin` (default) | Contains the executables of Oracle products.
`FORM_PATH` | `ORACLE_HOME\forms` (default) | Specifies the path that Oracle Forms searches when looking for a form, menu, or library to run. For Windows, separate paths with a semi-colon (;). For Solaris, separate paths with a colon (:).
`FORMS_TIMEOUT` | Default: 15 Valid Values: 3 – 1440 (1 day) Example: `FORMS_TIMEOUT=1440` | This parameter specifies the amount of time in elapsed minutes before the Form Services process is terminated when there is no client communication with the Form Services. Client communication can come from the user doing some work, or from the Forms Client heartbeat if the user is not actively using the form.
`TNS_ADMIN` | `ORACLE_HOME/network/admin` | Specifies the path name to the TNS files such as TNSNAMES.ORA, SQLNET.ORA etc.
`CLASSPATH` | `ORACLE_HOME/jdk/bin/java` | Specifies the Java class path, which is required for the Forms debugger.
`REPORTS_CLASSPATH` | `ORACLE_HOME/jlib/zrclient.jar:ORACLE_HOME/reports/jlib/rwrun.jar` | This setting is only needed if Reports applications are called from Forms applications
`REPORTS_SERVERMAP` | `cluster:repserver` Where: `cluster` is the Reports Server cluster name; `repserver` is the Reports Server name. | This setting is needed if Forms applications are calling Reports applications from a Reports cluster instead of a Reports server. This setting is also needed when a Forms application calls a Reportss application using `web.show_document`. See Oracle Application Server Reports Services Publishing Reports to the Web for additional Reports configuration information.
`ORACLE_GRAPHICS6I_HOM` | `<GRAPHICS6I_HOME>` | These settings are only needed if Graphics applications are called from Forms applications Use Enterprise Manager to set the `ORACLE_HOME` value to use Graphics applications.
`LD_LIBRARY_PATH` | Set the `LD_LIBRARY_PATH` environment variable for the first time to `ORACLE_HOME/lib`. You can reset `LD_LIBRARY_PATH` in the Bourne shell by entering: `$ set LD_LIBRARY_PATH=ORACLE_HOME/lib:${LD_LIBRARY_PATH}` `$ export LD_LIBRARY_PATH` or in the C shell by entering: `% setenv LD_LIBRARY_PATH ORACLE_HOME/lib:${LD_LIBRARY_PATH}` | Oracle Forms Developer and Reports Developer products use dynamic, or shared, libraries. Therefore, you must set `LD_LIBRARY_PATH` so that the dynamic linker can find the libraries.

Note: On Windows, Oracle Application Server Forms Services reads Oracle environment settings from the Windows Registry unless they are set as environment variables.

## 4.5 Managing User Sessions

Oracle Application Server Forms Services contains features to help administrators manage user sessions, including:

- Section 4.5.1, "Allowing New Users Sessions"

- Section 4.5.2, "Disabling New User Sessions"

- Section 4.5.3, "Terminating a User Session on a Forms Services Instance"

### 4.5.1 Allowing New Users Sessions

By default, users can create a new Forms session, which is indicated by the green traffic light. You can also enable users to create Forms sessions after you've disabled them.

To allow new Forms User sessions:

- From the Enterprise Manager Oracle Application Server Forms Services Overview page, click Enable (default).

  The traffic light changes to green

### 4.5.2 Disabling New User Sessions

To disable new user Forms user sessions:

- From the Enterprise Manager Oracle Application Server Forms Services Overview page, click Disable.

  The traffic light changes to yellow.

When you press Disable, a new parameter is added to the default section of the formsweb.cfg file. The parameter is called `allowNewConnections` and pressing Disable sets it to `false`. When new user sessions are disabled, attempted connections will be directed to a URL identified by the formsweb.cfg parameter `connectionDisallowedURL` (default section) e.g:

    connectionDisallowedURL=www.oracle.com
    connectionDisallowedURL=http://www.oracle.com

If no `connectionDisallowedURL` is specified then the following message will be displayed in the browser:

    The Forms Servlet will not allow new connections. Please contact your System Administrator.

However, when you disable new user sessions, existing forms sessions are unaffected and the OC4J instance remains up.

### 4.5.3 Terminating a User Session on a Forms Services Instance

1. Start the Oracle Enterprise Manager 10g Application Server Control Console.

2. Select the link to the Forms Services instance that has the user session to be terminated.

3. From the Overview page for the Forms Services instance, select the Session Details link.

4. Click the radio button next to the user session to be deleted.

5. Click Stop.

6. The Confirmation page appears.

7. Click Yes.

   The user session is deleted and the Runform instance is terminated.

## 4.6 Managing URL Security for Applications

Oracle Forms applications are Web deployed solutions that users access through a browser. Oracle Forms architecture allows Forms developers two ways to choose and configure how a Forms application runs. One option is to set the parameter and the value in the URL. The second option is to set the parameter and its value(s) in the configuration file, i.e. formsweb.cfg. The parameter that is set in the formsweb.cfg can be overridden by the parameter set in the URL.

Note: You manage the `restrictedURLparams` parameter through the Configuration page of Enterprise Manager Application Server Control Console.

A Forms administrator can override this default behavior, and give the Forms administrator full control over what parameter can be used in the URL.

Here are two scenarios to consider when deciding which parameters to allow or not allow in a URL. The first scenario is when an administrator just wants to restrict the usages of the USERID parameter in the URL that forces the end-user to always log in using the default login window. The second scenario is when an administrator would like to disable all parameters except a few, such as `CONFIG=MyApp` in a URL.

The parameter `restrictedURLparams` allows flexibility for the Forms administrator to consider any URL-accessible parameter in the formsweb.cfg file as restricted to a user. An administrator can specify this parameter in a named configuration section to override the one specified in the default configuration section. The `restrictedURLparams` parameter itself cannot be set in the URL.

Figure 4-1, "Defining the restricedURLparams Parameter" is an example of how the `restrictedURLparams` parameter is defined in the [myApp] section to override the one set in the [default] configuration section:

Figure 4-1 Defining the restricedURLparams Parameter

By default, this user, `scott`, is not allowed to debug this Forms application, use Forms Trace, or edit records in it. In the myApp section, user scott is only forced to log in when accessing the application, and not allowed to debug it. He can now, though, work with Forms Trace and edit records through a URL for this application.

An administrator can use the `restrictedURLparams` parameter to redirect a user to an error page that lists the parameters the user is restricted from using (or allowed to use) for this application.

### 4.6.1 Securing the Oracle Forms Test Form

The test form runs when you access an Oracle Forms URL but do not specify an application to run. For example, normally you call an Oracle Forms application with the following syntax:

`http://<host>:<port>/forms/frmservlet?config=myApp`

The Forms Servlet will locate `[myApp]` in the formsweb.cfg file and launch that application. However, when no application is specified, for example:

`http://<host>:<port>/forms/frmservlet`

the Forms Servlet uses the settings in the default section of the formsweb.cfg file. These settings are located under `[default]` in the Forms Configuration file (anytime an application does not override any of these settings, the defaults are used). The default section has the following setting:

`form=test.fmx`

This is the test form which allows you to test your Oracle Forms Services installation and configuration. Thus if you don't specify an application, Forms will launch the test.fmx file. You could change this to:

`form=`

and the form will not run. However, this is not optimal; the Forms Servlet still sends the dynamically generated HTML file to the client, from which a curious user could obtain information. The optimally secure solution is to redirect requests to an informational HTML page that is presented to the client instead. You'll need to change some parameters in the formsweb.cfg file.

Here are the parameters to change, along with their default values when you install Oracle Forms Services:

        # System parameter: default base HTML file
        baseHTML=base.htm
        # System parameter: base HTML file for use with JInitiator client
        baseHTMLjinitiator=basejini.htm
        # System parameter: base HTML file for use with Sun's Java Plug-In
        baseHTMLjpi=basejpi.htm
        # System parameter: base HTML file for use with Microsoft Internet Explorer
        # (when using the native JVM)
        baseHTMLie=baseie.htm

These parameters are templates for the HTML information that are sent to the client. Create an informational HTML page and have these variables point to that instead. For example, in the `ORACLE_HOME/forms/server` directory, create a simple HTML page called `forbidden.html` with the following content:

        <html>
          <head>
            <title>Forbidden</title>
          </head>
          <body>
           <h1>Forbidden!</h1>
            <h2>You may not access this Forms application.</h2>
          </body>
        </html>

Note: this redirecting of client information and presenting a message page instead is not the same Web page that the Web server returns when the requested content has restricted permissions on it.

Next, modify the formsweb.cfg parameters by commenting out or modifying the original parameters:

        # System parameter: default base HTML file
        #baseHTML=base.htm
        baseHTML=forbidden.html
        # System parameter: base HTML file for use with JInitiator client
        #baseHTMLjinitiator=basejini.htm
        baseHTMLjinitiator=forbidden.html
        # System parameter: base HTML file for use with Sun's Java Plug-In
        #baseHTMLjpi=basejpi.htm
        baseHTMLjpi=forbidden.html
        # System parameter: base HTML file for use with Microsoft Internet Explorer
        # (when using the native JVM)
        #baseHTMLie=baseie.htm
        baseHTMLie=forbidden.html

When a user enters the URL

`http://<host>:<port>/forms/frmservlet`

the customized Web page is presented. Of course, you can customize `forbidden.html`, including its contents, its filename, and its location as long as you make the corresponding changes to these parameters in the formsweb.cfg file. Administrators can put any information, such as warnings, errors, time stamps, IP logging, or contact information in this information Web page with minimal impact on the server configuration.

Note: Overriding the base HTML template entries in the default section of formsweb.cfg requires that you add the same entries pointing to the original values (or some other valid HTML file) in your application-specific named configuration:
    [myApp]
    form=myApplication.fmx
    lookandfeel=oracle
    baseHTML=base.htm
    baseHTMLjinitiator=basejini.htm
    baseHTMLjpi=basejpi.htm
    baseHTMLie=baseie.htm
If you don't specify these base HTML values, and when a user runs an application, they will see the forbidden.html page because the application-specific configuration section hasn't overridden the default values.

## 4.7 Creating Your Own Template HTML Files

Consider creating your own HTML file templates (by modifying the templates provided by Oracle). By doing this, you can hard-code standard Forms parameters and parameter values into the template. Your template can include standard text, a browser window title, or images (such as a company logo) that would appear on the first Web page users see when they run Web-enabled forms. Adding standard parameters, values, and additional text or images reduces the amount of work required to customize the template for a specific application. To add text, images, or a window title, simply include the appropriate tags in the template HTML file.

See Chapter 3, "Specifying Special Characters in Values of Runform Parameters" for information about coding the `serverArgs` applet parameter.

## 4.8 Including Graphics in Your Oracle Forms Application

In order to integrate graphics applications with your Oracle Forms applications, you must set the path definition in the Forms Servlet environment to include graphics as follows:

    PATH=ORACLE_HOME/bin;<GRAPHICS6I_HOME>/bin

The path definition of the Forms Servlet environment, is taken from the path definition of the servlet container. The file or location where the path will be defined is different for different servlet containers.

For more information about graphics, see Oracle Forms Developer and Oracle Application Server Forms Services: Migrating Forms Applications from Forms6i and Deploying Graphics in Oracle9iAS Forms Services, available at Oracle Technology Network (OTN), `http://www.oracle.com/technology/products/forms/`.

### 4.8.1 Oracle Graphics 6i and Oracle Database 9.0.1.4.0 (64bit)

Due to a limitation in the 8.0.6 RSF, Oracle Graphics 6i on Windows cannot connect to a 64-bit database. Thus, if you are using Oracle Forms 10g (9.0.4) or later to connect to a 64-bit database, and want to integrate with Oracle Graphics, you will need to upgrade your Oracle 6i Home (where Graphics is installed) to include an RSF version that contains a fix to bug 3088708. Please contact Oracle Support regarding availability of such an RSF.

### 4.8.2 Configuring Graphics 6i for use by Reports Server

Perform the following to correctly setup Reports/Graphics for Forms/Reports/Graphics integration:

1. In the `graphicsrun.sh` script enter the following:

       ORACLE_GRAPHICS6I_HOME=<location forms6i>
       export ORACLE_GRAPHICS6I_HOME
       TK_PRINTER=<real printer>

2. In the reports.sh script enter the following:

       ORACLE_GRAPHICS6I_HOME=<location forms6i>; export ORACLE_GRAPHICS6I_HOME
       REPORTS_DEFAULT_DESPLAY=NO; export REPORTS_DEFAULT_DESPLAY
       DISPLAY=<computer name>:0.0; export DISPLAY

## 4.9 Deploying Icons and Images Used by Forms Services

This section explains how to specify the default location and search paths for icons and images in Registry.dat.

### 4.9.1 Managing Registry.dat with Application Server Control

Use Application Server Control to change, add, or delete parameters from Registry.dat.

To change a Registry.dat parameter value:

1. Select the Configuration page of Enterprise Manager.

2. From the View dropdown list, select Forms Font and Icon Mapping (Registry.dat).

3. Select a radio button next to a parameter and change the value(s) for it in the Value text field.

4. Click Apply.

   Your changes are saved.

To add a Registry.dat parameter and its value:

1. Select the Configuration page of Enterprise Manager.

2. From the View dropdown list, select Forms Font and Icon Mapping (Registry.dat).

3. At the bottom of the Registry.dat page, enter a name for the parameter in the Name text field.

4. Enter a value for this new parameter in the Value text field.

5. Click Add New Parameter.

   Your changes are saved.

To delete a Registry.dat parameter and its value:

1. Select the Configuration page of Enterprise Manager.

2. From the View dropdown list, select Forms Font and Icon Mapping (Registry.dat).

3. Select a radio button next to a parameter and click Delete.

4. The Confirmation page appears, click Yes.

5. The parameter is deleted and the Configuration page reappears.

### 4.9.2 Deploying Application Icons

When deploying an Oracle Forms application, the icon files used must be in a Web-enabled format, such as JPG or GIF (GIF is the default format).

By default, the icons are found relative to the `DocumentBase` directory. That is, `DocumentBase` looks for images in the directory relative to the base directory of the application start HTML file. As the start HTML file is dynamically rendered by the Forms Servlet, the `forms` directory becomes the document base.

For example, if an application defines the icon location for a button with `myapp/<iconname>`, then the icon is looked up in the directory `forms/myapp`.

To change the default location, set the `imageBase` parameter to `codebase` in the Forms Web Configuration page of Enterprise Manager Application Server Control Console. Alternatively, you can change the `default.icons.iconpath` value of the Registry.dat file in the `forms/java/oracle/forms/registry` directory.

Setting the imageBase parameter to `codebase` enables Oracle Forms to search the `forms/java` directory for the icon files. Use this setting if your images are stored in a Java archive file. Changing the image location in the Registry.dat configuration file is useful if you want to store images in a central location independent of any application and independent of the Oracle Forms installation.

#### 4.9.2.1 Storing Icons in a Java Archive File

If an application uses a lot of custom icon images, it is recommended you store icons in a Java archive file and set the `imageBase` value to `codebase`. The icon files can be zipped to a Java archive via the Jar command of any Java Software Development Kit (Java SDK).

For example, the command `jar -cvf myico.jar *.gif` packages all files with the extension `.gif` into an archive file with the name myico.jar.

In order for Oracle Forms to access the icon files stored in this archive, the archive needs to be stored into the `forms/java` directory. Also, the name of the archive file must be part of the archive tag used in the custom application section of the formsweb.cfg file (for example, `archive_jini=frmall_jinit.jar, myico.jar`). Now, when the initial application starts, the icon files are downloaded to and permanently stored on the client until the archive file is changed.

Note: You do not need to deploy Oracle Forms default icons (for example, icons present in the default smart icon bar), as they are part of the `frmall.jar` file.

#### 4.9.2.2 Adding Icon Changes to Registry.dat

If you want to add icon changes to the Registry.dat file used by your application, it is recommended that you make a copy of the existing Registry.dat file and edit the copied file.

To create a copy of the Registry.dat file:

1. Copy the Registry.dat text file found in the `ORACLE_HOME/forms/java/oracle/forms/registry` directory to another directory. This directory must be mapped to a virtual directory for your Web server (for example, `/appfile`).

2. Rename this new file (for example, myapp.dat).

3. Modify the `iconpath` parameter specifying your icon location:

       default.icons.iconpath=/mydir or http://myhost.com/mydir

   (for an absolute path)

   or

       default.icons.iconpath=mydir

   (for a relative path, starting from the `DocumentBase` Directory)

4. Modify the `iconextension` parameter:

       default.icons.iconextension=gif

   or

       default.icons.iconextension=jpg

To reference the application file:

- In a specific named configuration section in the formsweb.cfg file, modify the value of the `serverApp` parameter and set the value to the location and name of your application file.

  For example:

      [my_app]
      ServerApp=/appfile/myapp

  (for an absolute path)

  or

      [my_app]
      ServerApp=appfile/myapp

  (for a relative path, relative to the `CodeBase` directory)

  Table 4-12, "Icon Location Guide" describes the correct locations where to place your application icons:

Table 4-12 Icon Location Guide

Icon Location | When | How
--- | --- | ---
DocumentBase | Default. Applications with few or no custom icons. | Store icons in forms directory or in a directory relative to forms.
Java Archives | Applications that use many custom icons | Set `ImageBase` to `codebase`, create Java archive file for icons, and add archive file to the archive parameter in formsweb.cfg.
Registry.dat | Applications with custom icons that are stored in a different location as the Oracle Forms install (can be another server). Useful if you need to make other changes to the Registry.dat file like font mapping. | Copy Registry.dat and change ServerApp parameter in formsweb.cfg.

### 4.9.3 SplashScreen and Background Images

When you deploy your applications, you have the ability to specify a splash screen image (displayed during the connection) and a background image file.

Those images are defined in the HTML file or you can use the Forms Web Configuration page in Enterprise Manager:

    <PARAM NAME="splashScreen" VALUE="splash.gif">

    <PARAM NAME="background" VALUE="back.gif">

The default location for the splash screen and background image files is in the DocumentBase directory containing the baseHTML file.

### 4.9.4 Custom Jar Files Containing Icons and Images

Each time you use an icon or an image (for a splash screen or background), an HTTP request is sent to the Web server. To reduce the HTTP round-trips between the client and the server, you have the ability to store your icons and images in a Java archive (Jar) file. Using this technique, only one HTTP round-trip is necessary to download the Jar file.

#### 4.9.4.1 Creating a Jar File for Images

The Java SDK comes with an executable called jar. This utility enables you to store files inside a Java archive. For more information, see `http://java.sun.com/`.

For example:

    jar -cvf myico.jar Splash.gif Back.gif icon1.gif

This command stores three files (`Splash.gif`, `Back.gif`, `icon1.gif`) in a single Jar file called `myico.jar`.

#### 4.9.4.2 Using Files Within the Jar File

The default search path for the icons and images is relative to the DocumentBase. However, when you want to use a Jar file to store those files, the search path must be relative to the `CodeBase` directory, the directory which contains the Java applet.

If you want to use a Jar file to store icons and images, you must specify that the search path is relative to `CodeBase` using the imageBase parameter in the formsweb.cfg file or HTML file.

This parameter accepts two different values:

- DocumentBase The search path is relative to the `DocumentBase` directory. It is the default behavior.

- CodeBase The search path is relative to the `CodeBase` directory, which gives the ability to use Jar files.

In this example, we use a JAR file containing the icons and we specify that the search should be relative to CodeBase. If the parameter `imageBase` is not set, the search is relative to `DocumentBase` and the icons are not retrieved from the Jar file.

For example (formsweb.cfg):

    archive=frmall.jar, icons.jar
    imageBase=codebase

### 4.9.5 Search Path for Icons and Images

The icons and images search path depends on:

- What you specify in your custom application file (for the icons).

- What you specified in the `splashScreen` and `background` parameters of your default Forms Web configuration or HTML file (for the images).

- What you specify in the `imageBase` parameter in the Forms Web Configuration page of Application Server Control for the file or HTML file (for both icons and images).

Forms Services searches for the icons depending on what you specify. This example assumes:

- host is the computer name.

- `DocumentBase` is the URL pointing to the HTML file.

- CodeBase is the URL pointing to the location of the starting class file (as specified in the formsweb.cfg file or HTML file).

- mydir is the URL pointing to your icons or images directory.

#### 4.9.5.1 DocumentBase

The default search paths for icons and images are relative to the `DocumentBase`. In this case, you do not need to specify the imageBase parameter:

Table 4-13 Search Paths for Icons

Location Specified | Search path used by Forms Services
--- | ---
default | `http://host/documentbase`
`iconpath=mydir` (specified in your application file) | `http://host/documentbase/mydir` (relative path)
`iconpath=/mydir` (specified in your application file) | `http://host/mydir` (absolute path)

Table 4-14 Search Paths for Images

Location Specified | Search path used by Forms Services
--- | ---
file.gif (specified, for example, in formsweb.cfg as splashscreen=file.cfg) | `http://host/documentbase/file.gif`
`mydir/file.gif` | `http://host/documentbase/mydir/file.gif` (relative path)
`/mydir/file.gif` | `http://host/mydir/file.gif` (absolute path)
file.gif (specified, for example, in formsweb.cfg as `splashscreen=file.gif`) | `http://host/documentbase/file.gif`

#### 4.9.5.2 CodeBase

Use the `imageBase=CodeBase` parameter to enable the search of the icons and images in a Jar file:

Table 4-15 Icon Search Paths Used by Forms Services

Location Specified | Search Path Used by Forms Services
--- | ---
default | `http://host/codebase` or root of the Jar file
`iconpath=mydir` (specified in your application file) | `http://host/codebase/mydir` or in the mydir directory in the Jar file (relative path)
`iconpath=/mydir` (specified in your application file) | `http://host/mydir` (absolute path) No Jar file is used

Table 4-16 Image Search Paths Used by Forms Services

Location Specified | Search Path Used by Forms Services
--- | ---
file.gif | `http://host/codebase/file.gif` or root of the Jar file
`mydir/file.gif` (specified in your HTML file) | `http://host/codebase/mydir/file.gif` or in the mydir directory in the Jar file (relative path)
`/mydir/file.gif` (specified in your HTML file) | `http://host/mydir/file.gif` (absolute path) No Jar file is used.

## 4.10 Enabling Language Detection

Oracle Forms architecture supports deployment in multiple languages. The purpose of this feature is to automatically select the appropriate configuration to match a user's preferred language. In this way, all users can run Oracle Forms applications using the same URL, yet have the application run in their preferred language. As Oracle Forms Services do not provide an integrated translation tool, you must have translated application source files.

### 4.10.1 Specifying Language Detection

For each configuration section in the Forms Web Configuration page, you can create language-specific sections with names like `<config_name>.<language-code>`. For example, if you created a configuration section "hr", and wanted to create French and Chinese languages, your configuration section might look like the following:

    [hr]
    lookAndFeel=oracle
    width=600
    height=500
    envFile=default.env
    workingDirectory=/private/apps/hr
    [hr.fr]

    envFile=french.env
    workingDirectory=/private/apps/hr/french

    [hr.zh]
    envFile=chinese.env
    workingDirectory=/private/apps/hr/chinese

### 4.10.2 Inline IME Support

Inline IME support enables Forms Web applications to properly display the composing text in which each character may not be directly represented by a single keystroke (e.g. Asian characters) near the insertion cursor (so called inline, or on-the-spot). It is enabled by default. To disable, set the applet parameter "inlineIME" to "false" in the baseHTML file:

    <HTML>
    <!-- FILE: basejini.htm (Oracle Forms) -->
     <BODY>
     ...
     <OBJECT classid=...
    >
    <PARAM NAME="inlineIME" VALUE="false">
    <EMBED SRC="" ...
    inlineIME="false"
    >
    ...
    .
    </BODY>
    </HTML>
    .
    To have inline IME support, forms client needs to be Jinitator 1.3.1 or Plug-in 1.4.1+.

For more information about using baseHTML, see Appendix C, "base.htm, basejini.htm, and basejpi.htm Files".

### 4.10.3 How Language Detection Works

When the Forms Servlet receives a request for a particular configuration (for example, `http://myserv/servlet/frmservlet?config=hr`) it gets the client language setting from the request header `"accept-language"`. This gives a list of languages in order of preference. For example, accept-language: de, fr, en_us means the order of preference is German, French, then US English. The servlet will look for a language-specific configuration section matching the first language. If one is not found, it will look for the next and so on. If no language-specific configuration is found, it will use the base configuration.

When the Forms Servlet receives a request with no particular configuration specified (with no `"config="` URL parameter, for example, `http://myserv/servlet/frmservlet`), it will look for a language-specific section in the default section matching the first language (for example, [.fr]).

#### 4.10.3.1 Multi-Level Inheritance

For ease of use, to avoid duplication of common values across all language-specific variants of a given base configuration, only parameters which are language-specific to be defined in the language-specific sections are allowed. Four levels of inheritance are now supported:

1. If a particular configuration is requested, using a URL query parameter like `config=myconfig`, the value for each parameter is looked for in the langage-specific configuration section which best matches the user's browser language settings (for example in section [myconfig.fr]),

2. Then, if not found, the value is looked for in the base configuration section ([myconfig],

3. Then, failing that, in the language-specific default section (for example, [.fr]),

4. And finally in the default section.

Typically, the parameters which are most likely to vary from one language to another are `"workingDirectory"` and `"envFile"`. Using a different `envFile` setting for each language lets you have different values of `NLS_LANG` (to allow for different character sets, date and number formats) and `FORMS_PATH` (to pick up language-specific fmx files). Using different `workingDirectory` settings provides another way to pick up language-specific.fmx files.

## 4.11 Enabling Key Mappings

A key binding connects a key to an application function. When you bind a key to a function, the program performs that function when you type that keystroke. You define key bindings in the fmrweb.res file in the `ORACLE_HOME/admin/resource/<language directory>` directory in UNIX, for example `ORACLE_HOME/forms/admin/resource/US`. For Windows, the location is `ORACLE_HOME\forms`.

By defining key bindings, you can integrate a variety of keyboards to make an application feel similar on each of them.On some platforms not all keys are able to be re-mapped. For example, on Microsoft Windows, because keys are defined in the Windows keyboard device driver, certain keys cannot be re-mapped. Key combinations integral to Windows, such as Alt-F4 (Close Window) and F1 (Help) cannot be re-mapped. As a general rule, keys which are part of the ÒextendedÓ keyboard also cannot be re-mapped. These keys include the number pad, gray arrow and editing keys, Print Screen, Scroll Lock, and Pause.

Note: If running with different `NLS_LANG` settings a different resource file will be used. e.g. `NLS_LANG``=GERMAN_GERMANY=WE8ISO8859P1 fmrwebd.res` file will be used.There is a resource file for each supported language. To override this, pass parameter `term=fullpath\filename.res` to the Oracle Forms Runtime process.

It is possible to pass this parameter directly within the URL. For example:

    http://hostname/forms/f90servlet?Form=test.fmx&term=fullpath\filename.res

You can also set this parameter in the formsweb.cfg file, for example:

    otherParams=term=fullpath\filename.res

### 4.11.1 Customizing fmrweb.res

fmrweb.res is a text file which can edited with a text editor such as vi in UNIX or Notepad or Wordpad on Windows. Unlike Oracle 6i Forms, Oracle Terminal editor is no longer required. The text file is self-documented.

Note: The customization is limited, particularly compared to character mode forms. You cannot edit `fmrweb.res` with Oracle Enterprise Manager Application Server Control.

#### 4.11.1.1 Example change: Swapping Enter and Execute Mappings

In the section marked `USER-READABLE STRINGS`, find the entries with

    122 : 0 : "F11" : 76 : "Enter Query"
    122 : 2 : "Ctrl+F11" : 77 : "Execute Query"

and change them to:

    122 : 2 : "Ctrl+F11" : 76 : "Enter Query"
    122 : 0 : "F11" : 77 : "Execute Query"

Note: By default `fmrweb.res` does not reflect the Microsoft Windows client-server keyboard mappings. It reflects the key mapping if running client-server on Unix X-Windows/Motif.

A file called `fmrpcweb.res` has also been provided which gives the Microsoft Windows client-server keyboard mappings. To use this file, rename `fmrpcweb.res` e.g to `fmrweb_orig.res`, and copy `fmrpcweb.res` to `fmrweb.res`. Alternatively use the term parameter as described above.

#### 4.11.1.2 Exceptions/ Special Key Mappings

The following examples show special key mappings:

- Section 4.11.1.2.1, "Mapping F2"

- Section 4.11.1.2.2, "Mapping for ENTER to Fire KEY-ENTER-TRIGGER"

- Section 4.11.1.2.3, "Mapping Number Keys"

- Section 4.11.1.2.4, "Mapping for ESC Key to exit out of a Web Form"

##### 4.11.1.2.1 Mapping F2

To map F2, change the default entry for F2, "List Tab Pages", to another key. Here is an example of the default entry:

    113: 0 : "F2" : 95 : "List Tab Pages"

This must be explicitly changed to another key mapping such as the following:

    113: 8 : "F2" : 95 : "List Tab Pages"

To map the F2 function to the F2 key, comment out the lines that begin with "113 : 0" and "113 : 3" with a # symbol and add the following lines to the bottom of the resource file:

    113: 0 : "F2" : 84 : "Function 2"
    113: 8 : " " : 95 : " "

Since a new function has been added which uses F2 by default, it is necessary to explicitly map this new function to something else in order to map the F2 key. This function was added to allow for keyboard navigation between the tab canvas pages and it defaults to F2. Even if it is commented out and not assigned to F2, the F2 key cannot be mapped unless this function, Forms Function Number 95, is mapped to another key.

##### 4.11.1.2.2 Mapping for ENTER to Fire KEY-ENTER-TRIGGER

By default, whether deploying client-server or over the web pressing the ENTER key takes the cursor to the next navigable item in the block. To override this default behavior it is necessary to modify the forms resource file to revise the key mapping details.

Modify FMRWEB.RES and change the Forms Function Number (FFN) from 27 to 75 for the Return Key. The line should be changed to the following:

    10 : 0 : "Return" : 75 : "Return"

By default, the line is displayed with an FFN of 27 and looks as follows:

    10 : 0 : "Return" : 27 : "Return"

This line should NOT fire the Key-Enter trigger since the Return or Enter key is actually returning the Return function represented by the FFN of 27. The FFN of 75 represents the Enter function and will fire the Key-Enter trigger.

##### 4.11.1.2.3 Mapping Number Keys

The objective is to map CTRL+<number> keys in fmrweb.res for numbers 0 to 9 and there are no Java Function keys mentioned for the numbers in fmrweb.res. The steps to be performed along with an example that shows the steps needed to map CTRL+1 to 'Next Record'

1. List the java function key numbers that could be implemented in fmrweb.res file for the Key Mapping. For example:

       public static final int VK_1 = 0x31;

2. The hexadecimal values have to be converted to their decimal equivalents before their use in fmrweb.res.

   In step (1), 0x31 is a hexadecimal value that has to be converted to its decimal equivalent. (Note:1019580.6) e.g:

       SQL> select hextodec('31') from dual;
       HEXTODEC('31')
       --------------
       49

3. Use this decimal value for mapping the number key 1 in fmrweb.res For example, CTRL+1 can be mapped to 'Next Record' as:

       49 : 2 : "CTRL+1" : 67 : "Next Record"

##### 4.11.1.2.4 Mapping for ESC Key to exit out of a Web Form

1. Make a backup copy of fmrweb.res

2. Open the fmrweb.res file present in the path `ORACLE_HOME/FORMS` and add the following entry in it:

       27 : 0 : "Esc" : 32 : "Exit"

3. Ensure that you comment or delete the old entry

       #115 : 0 : "F4" : 32 : "Exit"

   The first number (115) might differ on different versions or platforms. When you run the Web Form and press the ESC key, then the Form will exit.