Skip Headers

Oracle® Application Server Forms Services Deployment Guide
10g (9.0.4) for Windows and UNIX
Part No. B10470-02
  Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index
Previous Next  

4 Configuring Forms Services with Enterprise Manager

This chapter contains the following sections:

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

4.2.1 Using Enterprise Manager to Manage Forms Sessions

By default, Enterprise Manager 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 the following variable is set in the default section. You can do this either through EM, or manually on the server.

    em_mode=1

    This will let EM 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 EM, or manually on the server.

    allow_debug=true

    This will let you turn tracing on and off within EM.

  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 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 EM.

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

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 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, "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 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, "Sample Configuration Files" 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, "Enabling Single Sign-On for an Application".

These sections include:

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 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.
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.

HTMLdelimiter 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, "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.2.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:

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:

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

This image shows a sample configuration section using EM.

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.2.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/registry 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)

  1. 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.

  Previous Next
Oracle Logo
Copyright © 2004, Oracle. All rights reserved.
  Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index