4
Configuring Forms Services with Enterprise Manager

4.1 Introduction

This chapter contains the following sections:

• Enterprise Manager and Oracle Forms

• Configuring Forms Services

• Configuring Parameters with Application Server Control

• Managing URL Security for Applications

• Creating Your Own Template HTML Files

• Including Graphics in Your Oracle Forms Application

• Deploying Icons and Images Used by Forms Services

• Enabling Language Detection

4.1.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 Application Server Control as your needs change.

4.2 Enterprise Manager and Oracle Forms

The Enterprise Manager Application Server Control 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://<machine.domain>:1810

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 to:

• Monitor metrics for an Forms Services instance. See Chapter 8.2.1.1, "Monitoring Forms Services Instances" for more information.

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

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

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

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

• Configure Forms Trace and monitor trace metrics. See Chapter 7.1.1, "Configuring Forms Trace" and Chapter 7.1.6, "Monitoring Forms Services Trace Metrics" for more information.

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

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

4.2.1 Configuring Enterprise Manager to Manage Forms Services

When you install Forms Services, the Oracle Universal Installer automatically edits Enterprise Manager's 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 to access the Enterprise Manager Administration page for a a node. (You will need to provide an administrator's username and password.)

To configure Enterprise Manager 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.2 Accessing Forms Services with Application Server Control

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

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

1. Using Application Server Control, 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, see "Introduction to Administration Tools" in the Oracle Application Server 10g 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.

4.3 Configuring Forms Services

Use the Configuration page in Application Server Control 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 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.

2. From the Application Server Control main page, select the link to the Oracle9iAS 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 and click Go.
   • 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 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

For a description and the location of the Forms Servlet configuration file (formsweb.cfg), see Chapter 3.2.1.2, "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:

Table 4-1 Default Configuration Parameters that Specify Files

Parameter	Value
baseHTML	base.htm
baseHTMLie	baseie.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>/forms90/server.

4.3.2 Managing Configuration Sections

You create new configuration sections from the Configuration tab of Application Server Control, 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.

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

3. From the Oracle9iAS 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:

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/forms90/f90servlet?config=sepwin

You can also use Application Server Control to create named configuration sections (see Chapter 7, "Tracing and Diagnostics").

See Appendix B.1, "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, select the radio button next to the section name and click Edit.

To delete a named configuration:

1. Start the Enterprise Manager Application Server Control.

2. From the Application Server Control 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 returns to the Forms Configuration tab and displays the remaining configurations at the bottom of the page.

4.3.3 Managing Parameters

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

To edit a parameter in a configuration section:

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

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, 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 Forms Configuration Section Parameters 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 Confirm 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 single sign-on parameters, see Chapter 6.4, "Enabling Single Sign-On for an Application".

These sections include:

• System Default Configuration Parameters

• Runform parameters (serverArgs parameters)

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

• Applet or Object Parameters

• Parameters for JInitiator

• Parameters for Sun's Java Plug-in

• Enterprise Manager Configuration Parameters

• OID (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.

Table 4-3 System Default Configuration Parameters

Parameter	Required / Optional	Parameter Value
baseHTML	required	The default base HTML file.
baseHTMLJInitiator	required	Physical path to HTML file that contains JInitiator tags.
connectionDisallowedURL	required	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.
baseHTMLie	optional	Physical path to the HTML file that contains Internet Explorer 5 tags, for example the CABBASE tag. The default path is <ORACLE_HOME>/forms90/server/baseie.htm. This is required when using the Internet Explorer native JVM.
HTML delimiter	required	Delimiter for variable names. Defaults to %.
workingDirectory	required	Defaults to <ORACLE_HOME>/forms90 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 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.

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.3.4, "Specifying Special Characters in Values of Runform Parameters" for information about how runform handles certain special characters that are specified in runform parameter values.

Table 4-4 Runform Parameters (serverArgs Parameters)

Parameter	Required / Optional	Parameter Value
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 FORMS90_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 forms90/f90servlet/admin screen are activated. forms90/f90servlet/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 Forms EM User Sessions screen. The default value is false; the test.fmx application is executed if an administrative function is attempted.
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 may not be set using URL query parameters.

Table 4-5 HTML Page Parameters

Parameter	Required / Optional	Parameter Value
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

All of the following 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
serverURL	required	/forms90/l90servlet (see Chapter 1, Forms Listener Servlet)
codebase	required	Virtual directory you defined to point to the physical directory <ORACLE_HOME>/forms90/java, where, by default, the applet JAR files are downloaded from. The default value is /forms90/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>/forms90/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 f90all.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 f90all_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 f90all.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

Table 4-7 Parameters for JInitiator

Parameter	Required / Optional	Parameter Value
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 /forms90/jinitiator/us/JInitiator/jinit.download.htm.
jinit_classid	required (IE only)	Default is clsid:CAFECAFE-0013-0001-0009-ABCDEFABCDEF
jinit_exename	required	Default is jinit.exe#Version=1.3.1.9
jinit_mimetype	required (Netscape only)	Default is application/x-jinit-applet;version=1.3.1.9
baseHTMLJInitiator	required	Physical path to HTML file that contains JInitiator tags.

4.3.4.6 Parameters for Sun's Java Plug-in

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

Parameter	Required / Optional	Parameter Value
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

Table 4-9 Enterprise Manager Configuration Parameters

Parameter	Required / Optional	Parameter Value
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.

4.3.4.8 OID (Oracle Internet Directory) Configuration Parameters

Table 4-10 Enterprise Manager Configuration Parameters

Parameter	Required / Optional	Parameter Value
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 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 FORMS90_PATH for the Forms runtime executable (ifweb90.exe on Windows and f90webm on UNIX) 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>/forms90/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. Environment files must be created manually in <ORACLE_HOME>/forms90/server with a .env extension. Likewise, environment files cannot be deleted from EM. For a new environment file to be picked up by Application Server Control 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.
FORM90_PATH	<ORACLE_HOME>\forms90 (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 UNIX, separate paths with a colon (:).
FORMS90_TIMEOUT	Default: 15 Valid Values: 3 - 1440 (1 day) Example: FORMS90_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
GRAPHICS60_PATH	ORACLE_GRAPHICS6I_HOME=<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:

• Allowing New Users Sessions

• Disabling New User Sessions

• Terminating a User Session on a Forms Services Instance

4.5.1 Allowing New Users Sessions

By default, users can create new Forms sessions, which is indicated by the green traffic light. You can also enable users to create Forms sessions after you've enabled 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 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 Application Server Control.

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. Provide the credentials in the dialog box that displays (the user name and password that is required is the same one that was used when Forms Services was installed).

7. Click OK.

   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.

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 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 Sample Configuration Section for myApp

Text description of the illustration edit_sec.gif

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.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.3.4, "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://otn.oracle.com/products/forms/.

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. Additional information can be found at http://otn.oracle.com/products/forms.

4.9.1 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 forms90 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 forms90/myapp.

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

Setting the imageBase parameter to codebase enables Oracle Forms to search the forms90/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.1.1 Storing Icons in a Java Archive

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 myjar.jar *.gif zips 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 forms90/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=f90all_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 f90all.jar file,

4.9.1.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>/forms90/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)
   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

Icon Location	When	How
DocumentBase	Default. Applications with few or no custom icons.	Store icons in forms90 directory or in a directory relative to forms90.
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.2 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.3 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 roundtrips 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 roundtrip is necessary to download the Jar file.

4.9.3.1 Creating a Jar File

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://www.javasoft.com.

For example:

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

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

4.9.3.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=f90all.jar, icons.jar
imageBase=codebase

4.9.4 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 Enterprise manager 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 host 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.4.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

file.gif (specified, for example, in formsweb.cfg as splashscreen=file.gif)	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.4.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 we 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 How Language Detection Works

When the Forms Servlet receives a request for a particular configuration (for example, http://myserv/servlet/f90servlet?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/f90servlet), it will look for a language-specific section in the default section matching the first language (for example, [.fr]).

4.10.2.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 FORMS90_PATH (to pick up language-specific fmx files). Using different workingDirectory settings provides another way to pick up language-specific.fmx files.