|
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2) B14032-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2) B14032-02 |
|
|
Previous |
Next |
This chapter contains the following sections:
Section 4.1, "How Oracle Application Server Forms Services Launches a Forms Application"
Section 4.4, "Configuring Environment Variables with Enterprise Manager"
Section 4.8, "Including Graphics in Your Oracle Forms Application"
Section 4.9, "Deploying Icons and Images Used by Forms Services"
When a user first starts an Oracle Forms application (by clicking a link to the application's URL), the baseHTML file is read by Forms Servlet. Any variables (%variablename%) in the baseHTML file are replaced with the appropriate parameter values specified in the formsweb.cfg file, and from query parameters in the URL request (if any).
You can easily modify the configuration files with Oracle Enterprise Manager 10g Application Server Control Console as your needs change.
The Enterprise Manager Application Server Control Console user interface that is shipped with Forms Services is a Web-based tool that you launch from your default browser. The default URL is:
http://<computer.domain>:1156
|
Note: For information on how to launch Enterprise Manager, see the Oracle Enterprise Manager Advanced Configuration. |
For Forms Services, use the Web-based Enterprise Manager Application Server Control Console to:
Monitor metrics for a Forms Services instance. See Chapter 10, "Monitoring Forms Services Instances" for more information.
Monitor metrics for user sessions. See Chapter 10, "Monitoring Metrics for User Sessions" for more information.
Allow or deny new user sessions. See Chapter 4, "Allowing New Users Sessions" and Chapter 4, "Disabling New User Sessions" for more information.
Terminate user sessions. See Chapter 4, "Terminating a User Session on a Forms Services Instance" for more information.
Configure parameters for a Forms Services instance. See Chapter 4, "Configuring Parameters with Application Server Control Console" for more information.
Configure Forms Trace and monitor trace metrics. See Chapter 8, "Configuring Forms Trace" and Chapter 8, "Monitoring Forms Services Trace Metrics" for more information.
Configure multiple environment files. See Chapter 4, "Configuring Environment Variables with Enterprise Manager" for more information.
Use available Forms Services utilities and runtime pooling. See Chapter 10, "Forms Services Utilities" and Chapter 10, "Tuning OracleAS Forms Services Applications" for more information.
By default, Enterprise Manager Application Server Control provides some information about Forms which allows you to centrally modify the configuration files. But you won't experience the full functionality that Enterprise Manager can provide for Forms unless you do the following:
In the Forms configuration file (formsweb.cfg) make sure the following variable is set in the default section.
em_mode=1
This will let Application Server Control show user information for each running Forms application. Only sessions created after setting em_mode to 1 will be shown. By default, this value is 0, which is off.
In the Forms configuration file (formsweb.cfg) make sure the following variable is set. You can either set it in the default section or in a specific application section. As with step 1, you can set this variable using Application Server Control:
allow_debug=true
This will let you turn tracing on and off.
(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.
(Windows only) As the user who installed Oracle Application Server or as a user with administrator privileges, bring up the Windows Services, which can be found in the Control Panel. Find the Oracle/xxxxxx/ProcessManager service. Right-click it and choose Properties. In the Logon tab, make sure Allow service to interact with desktop is selected.
(Windows only) You will need to restart this service. Note that even after it is restarted, it can take up to several minutes for the changes to take effect in Application Server Control.
When you install Forms Services, the Oracle Universal Installer automatically edits Enterprise Manager Grid Control targets.xml file. The targets.xml file contains a list of all the services to be managed by Enterprise Manager.
The first time you use Enterprise Manager to monitor Forms Services, you must perform the following steps for each Forms Services instance to be monitored.
See the Enterprise Manager documentation for information on how to use the Application Server Control Console to access the Enterprise Manager Administration page for a node. (You will need to provide an administrator's username and password.)
To configure Enterprise Manager Grid Control to Manage Forms Services:
On the Agent Administration page, all services that are being monitored are listed under the Agent Monitored Targets heading.
Select the radio button next to the Forms instance to be configured for Enterprise Manager.
Click Edit.
Provide the ORACLE_HOME and URL for the Forms instance.
Click OK.
|
Note: See the Enterprise Manager help system for more information about other tasks that you can complete on this page. |
To perform most management tasks for a Forms server using Application Server Control Console, you start by navigating to the Forms Home page for the Forms Server in Application Server Control Console.
To navigate to the Forms Home page for a Forms Server in the Application Server Control Console:
Using Application Server Control Console, navigate to the home page for the application server that contains Forms server you want to manage.
For introductory information about using the Enterprise Manager Application Server Control Console, see "Introduction to Administration Tools" in the Oracle Application Server Administrator's Guide.
In the System Components section on the application server home page, click the link for the Forms server that you want to manage. This displays the Forms home page for the Forms server in the Application Server Control Console.
Use the Configuration page in Application Server Control Console to configure Forms Services. This page manages all changes in the formsweb.cfg file for you.
|
Note: If you manually edit any of the configuration or environment files, you'll need to restart Enterprise Manager as well as restart all Distributed Configuration Management (DCM) processes so that Enterprise Manager can read all changes. If you do not restart Enterprise Manager as well as DCM processes, any changes that you make through Oracle Enterprise Manager 10g will overwrite any manual changes you've made to these files. These DCM processes include:
|
|
Note: You should backup the formsweb.cfg and default.env files before editing them with Enterprise Manager. |
To configure Forms Services:
Start the Application Server Control Console.
From the Application Server Control Console main page, select the link to the OracleAS Forms Services instance that you want to configure.
From the Forms Services instance, select the Configuration tab.
Select Forms Web Configuration from the View pulldown list.
To create a new section in the formsweb.cfg file, click Create New Section and enter a name for this section on the next page
To delete a section in the formsweb.cfg file, click the radio button next to the section to be deleted, then click Delete and confirm the deletion on the next page.
|
Note: As with most Web applications, it is easy to lose unsaved changes by switching pages. Be sure to save any changes you make through Application Server Control Console to Forms configuration or environment files before proceeding to other pages.The length of time it takes for changes to be saved is affected by the number of lines you have changed. For example, an additional fifty lines of comments will take longer to save than just the deletion of a single entry. |
For a description and the location of the Forms Servlet configuration file (formsweb.cfg), see Chapter 3, "formsweb.cfg".
The four baseHTML parameters should point to appropriate files. Typically, the following values and their parameters should appear in the default configuration section, as shown in Table 4-1, "Default Configuration Parameters that Specify Files":
Table 4-1 Default Configuration Parameters that Specify Files
| Parameter | Value |
|---|---|
|
baseHTML |
base.htm |
|
|
basejini.htm |
|
|
basejpi.htm |
|
|
default.env |
All of these parameters specify file names. If no paths are given (as in this example), the files are assumed to be in the same directory as the Forms Servlet configuration file (formsweb.cfg), that is ORACLE_HOME/forms/server.
You create new configuration sections from the Configuration tab of Application Server Control Console, which creates the named configurations in the formsweb.cfg file. These configurations can be requested in the end-user's query string of the URL that is used to run a form.
To create a new configuration section:
Start the Enterprise Manager Application Server Control Console.
From the Application Server Control Console main page, select the link to the Forms Services instance that you want to configure.
From the Forms Services instance, select the Configuration tab.
Click Create New Section at the top of the Configuration tab.
The Forms New Section Name page appears.
Enter a name for your new configuration and click OK.
If you enter a description of your new section, make sure you save it clicking Apply before editing the section and adding parameters.
For example, to create a configuration to run Forms in a separate browser window with a "generic" look and feel, create a new section and add the following parameters from Table 4-2, "Sample Parameters to Add to a New Configuration Section":
Table 4-2 Sample Parameters to Add to a New Configuration Section
| Parameter | Value |
|---|---|
|
forms |
<module> |
|
separateFrame |
True |
|
lookandfeel |
Generic |
Your users would type the following URL to launch a form that uses the "sepwin" (or whatever name you applied) configuration:
http://server:port/forms/frmservlet?config=sepwin
See Appendix C, "Default formsweb.cfg File" for other examples of special configurations.
You can make a copy of a named configuration for backup purposes, or create new configuration sections from duplicates.
To duplicate a named configuration:
Select the radio button next to the section to be duplicated.
Click Duplicate.
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.
When you delete a named configuration, you delete all the information within it. If you only want to delete specific parameters, see Section 4.3.3, "Managing Parameters".
To delete a named configuration:
Start the Enterprise Manager Application Server Control Console.
From the Application Server Control Console main page, select the link to the Forms Services instance that you want to configure.
From the Configuration, select the radio button next to the configuration section you want to delete.
Click Delete.
The Confirmation page appears.
Click OK.
The configuration section is deleted.
Application Server Control Console returns to the Configuration tab and displays the remaining configurations.
Use Application Server Control Console to manage parameters within a named configuration. You can add, edit, or delete parameters from the Edit Section page of Application Server Control Console.
To edit a parameter in a configuration section:
From the Configuration tab of Enterprise Manager Application Server Control Console, select the radio button next to the configuration section that contains the parameter that you want to edit.
Click Edit at the top of this page.
The Edit Section page appears for that selected configuration.
Select the radio button next to the parameter you want to edit.
Make your changes in the text fields.
Click Apply.
Your changes are saved.
To add a parameter to a configuration:
From the Configuration tab of Application Server Control Console, select the radio button next to the configuration section to which you want to add a parameter.
Click Edit at the top of this page.
The Edit Section page appears for that selected configuration.
Enter a name and value for the new parameter and click Add New Parameter.
The Edit Section page refreshes and displays the new parameter.
Add a description for the new parameter, and click Apply.
To return to the Forms page, click Forms in the breadcrumb trail.
To delete a parameter in a configuration:
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.
Select the radio button next to the parameter you want to delete.
Click Delete.
Confirm the deletion on the Confirmation page that appears.
The parameter is deleted from the configuration section.
Table 4-3, "System Default Configuration Parameters" describes the default forms configuration parameters in the formsweb.cfg file. For additional information on OracleAS Single Sign-On parameters, see Chapter 6, "Enabling OracleAS Single Sign-On for an Application".
These sections include:
Section 4.3.4.2, "Runform parameters (serverArgs parameters)"
Section 4.3.4.7, "Enterprise Manager Configuration Parameters"
Section 4.3.4.8, "Oracle Internet Directory Configuration Parameters"
These parameters control the behavior of the Forms Servlet. They can only be specified in the servlet configuration file (formsweb.cfg) and cannot be specified as URL query parameters.These parameters are described in Table 4-3, "System Default Configuration Parameters":
Table 4-3 System Default Configuration Parameters
| Parameter | Required / Optional | Parameter Value and Description |
|---|---|---|
|
required |
The default base HTML file. |
|
|
required |
Physical path to HTML file that contains JInitiator tags. |
|
|
optional |
This is the URL shown in the HTML page that is not allowed to start a new session. |
|
|
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. |
|
|
required |
Delimiter for variable names. Defaults to %. |
|
|
required |
Defaults to |
|
|
required |
This is set to default.env in the formsweb.cfg file. |
|
|
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 |
|
|
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. |
|
|
optional |
Supports running and debugging a form from the Builder. Default value is |
|
|
optional |
Valid values: See Section 7.5.8.2, "Starting a JVM Controller at the Command Line". In addition, you can specify no JVM. Default value: none This parameter can be set globally in the default section, or any application section can choose to override it. This tells the Forms runtime process which JVM controller to use. It corresponds to the jvmcontroller parameter for the dejvm executable (see section 2.3, table 1). If jvmcontroller does not have a value, then the Oracle Forms Runtime Process will start its own in-process JVM, which means that the Java Importer uses pre-10g behavior. |
All parameters from here on match variables (%parameterName%) in the baseHTML file. These variables are replaced with the parameter values specified in the URL query string, or failing that, in the formsweb.cfg file. See Chapter 3, "Specifying Special Characters in Values of Runform Parameters" for information about how runform handles certain special characters that are specified in runform parameter values. These runform parameters are described in Table 4-4, "Runform Parameters (serverArgs Parameters)":
Table 4-4 Runform Parameters (serverArgs Parameters)
| Parameter | Required / Optional | Parameter Value and Description |
|---|---|---|
|
optional |
Specifies the dots per inch (DPI) and overrides the DPI setting returned by the JVM, allowing you to manage varying DPI settings per platform. For example, a form developed on the Win32 platform may not display properly on the UNIX platform due to varying DPI values. The clientDPI value can be any positive integer. Oracle recommends that you use an integer between 50 and 200, e.g. |
|
|
optional |
Set this parameter to |
|
|
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 |
|
|
required |
Specifies the name of the top level Forms module (fmx file) to run. |
|
|
optional |
Login string. For example: |
|
|
optional |
This setting specifies command line parameters to pass to the Forms runtime process in addition to Default is:
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 |
|
|
optional |
Allows running in debug mode. Default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Sub argument for Default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Sub argument for Default value is |
|
|
optional |
When set to true, all admin functions from the The default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Default value is |
|
|
optional |
Supports running and debugging a form from the Builder. Default value is |
|
|
For internal use only. |
|
For security reasons these parameters may not be set using URL query parameters, as described in Table 4-5, "HTML Page Parameters":
Table 4-5 HTML Page Parameters
| Parameter | Required / Optional | Parameter Value and Description |
|---|---|---|
|
optional |
HTML page title, attributes for the BODY tag, and HTML to add before and after the form. |
|
|
optional |
Attributes for the <BODY> tag of the HTML page. |
|
|
optional |
HTML content to add to the page above the area where the Forms application will be displayed. |
|
|
optional |
HTML content to add to the page below the area where the Forms application will be displayed. |
The following parameters in Table 4-6, "Applet or Object Parameters" are specified in the baseHTML file as values for object or applet parameters. For example: <PARAM NAME="serverURL" VALUE="%serverURL%">
Table 4-6 Applet or Object Parameters
| Parameter | Required / Optional | Parameter Value and Description |
|---|---|---|
|
required |
|
|
|
required |
Virtual directory you defined to point to the physical directory The default value is |
|
|
optional |
Indicates where icon files are stored. Choose between:
|
|
|
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 |
|
|
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 Default value is |
|
|
optional |
Forms applet parameter. |
|
|
optional |
Forms applet parameter. |
|
|
required |
Specifies the width of the form applet, in pixels. Default is 650. |
|
|
required |
Specifies the height of the form applet, in pixels.Default is 500. |
|
|
optional |
Determines whether the applet appears within a separate window. Legal values: True or False. |
|
|
optional |
Specifies the .GIF file that should appear before the applet appears. Set to To set the parameter include the file name (for example, myfile.gif) or the virtual path and file name (for example, images/myfile.gif). |
|
|
optional |
Specifies the .GIF file that should appear in the background. Set to |
|
|
optional |
Determines the applications look-and-feel. Legal values: Oracle or Generic (Windows look-and-feel). |
|
|
optional |
Determines the application's color scheme. Legal values: Teal, Titanium, Red, Khaki, Blue, Olive, or Purple. Note: |
|
|
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 |
|
|
optional |
Comma-separated list of archive files that are used when the browser detected is neither Internet Explorer using native JVM nor JInitiator. (The default is frmall.jar.) To set the parameter include the file name if the file is in the codebase directory or include the virtual path and file name. |
|
|
optional |
Comma-separated list of JAR file(s) that is used when the browser detected is JInitiator. (The default is frmall_jinit.jar.) To set the parameter include the file name if the file is in the codebase directory or include the virtual path and file name. |
|
|
optional |
Comma-separated list of CAB file(s) that is used when the browser detected is Internet Explorer using native JVM. (The default is |
|
|
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. |
|
|
optional |
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. |
The following parameters are specific to JInitiator, as described in Table 4-7, "Parameters for JInitiator":
Table 4-7 Parameters for JInitiator
| Parameter | Required / Optional | Parameter Value and Description |
|---|---|---|
|
required (Netscape only) |
If you create your own version of the Jinitiator download page, set this parameter to point to it. Default is |
|
|
required (IE only) |
Default is |
|
|
required |
Default is |
|
|
required (Netscape only) |
Default is |
|
|
required |
Physical path to HTML file that contains JInitiator tags. |
The following parameters are for use with the Sun Java Plug-in, as described in Table 4-8, "Parameters for Sun's Java Plug-in":
The following parameters are for configuring Enterprise Manager, as described in Table 4-9, "Enterprise Manager Configuration Parameters":
Table 4-9 Enterprise Manager Configuration Parameters
| Parameter | Required / Optional | Parameter Value and Description |
|---|---|---|
|
required |
1 is to enable. 0 is to disable. 1 indicates that all Enterprise Manager information is available, including metrics and servlet status. 0 indicates that only configuration information is available. |
|
|
EndUserMonitoringEnabled |
Optional |
Indicates whether End User Monitoring integration is enabled. |
|
EndUserMonitoringURL |
Optional |
indicates where to record End User Monitoring data. |
The following parameters are for configuring Oracle Internet Directory, as described in Table 4-10, "Oracle Internet Directory Configuration Parameters". You can only configure these parameters if you are using an OracleAS Infrastructure instance.
Table 4-10 Oracle Internet Directory Configuration Parameters
| Parameter | Required / Optional | Parameter Value and Description |
|---|---|---|
|
required |
Configured during the OracleAS installation, so you do not need to change this. |
|
|
required |
Configured during the OracleAS installation, so you do not need to change this. |
Use the Environment tab of the Enterprise Manager Application Server Control Console page to manage Environment Variables. From this page, you can add, edit, or delete environment variables as necessary.
The environment variables such as PATH, ORACLE_HOME, and FORMS_PATH for the Forms runtime executable (frmweb.exe on Windows and frmweb on Solaris) are defined in the Environment tab. The Listener Servlet calls the executable and initializes it with the variable values provided in the environment file, which is ORACLE_HOME/forms/server/default.env by default.
Any environment variable that is not defined in that page is inherited from the servlet engine (OC4J). The environment file must be named in the envFile parameter in the Default section of the Forms Web Configuration page.
A few things to keep in mind when customizing environment variables are:
Environment variables may also be specified in the Windows registry. Values in the environment file override settings in the registry. If a variable is not set in the environment file, the registry value is used.
You will need administrator privileges to alter registry values.
You do not need to restart the server for configuration changes to take effect.
Environment variables not set in the environment file or Windows registry are inherited from the environment of the parent process, which is the servlet engine (OC4J).
|
Note: You cannot create or delete environment files through Enterprise Manager Application Server Control Console. Environment files must be created manually inORACLE_HOME/forms/server with a .env extension.
Likewise, environment files cannot be deleted from Application Server Control. For a new environment file to be picked up by Application Server Control Console and for a deleted one to disappear you will need to restart the Enterprise Manager processes:
|
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 |
|---|---|---|
|
|
Points to the base installation directory of any Oracle product. |
|
|
|
Contains the executables of Oracle products. |
|
|
|
Specifies the path that Oracle Forms searches when looking for a form, menu, or library to run. For Windows, separate paths with a semi-colon (;). For Solaris, separate paths with a colon (:). |
|
|
|
Default: 15 Valid Values: 3 – 1440 (1 day) Example:
|
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. |
|
|
|
Specifies the path name to the TNS files such as TNSNAMES.ORA, SQLNET.ORA etc. |
|
|
|
Specifies the Java class path, which is required for the Forms debugger.
|
|
|
This setting is only needed if Reports applications are called from Forms applications
|
|
|
Where:
|
This setting is needed if Forms applications are calling Reports applications from a Reports cluster instead of a Reports server. This setting is also needed when a Forms application calls a Reportss application using |
|
|
|
These settings are only needed if Graphics applications are called from Forms applications Use Enterprise Manager to set the |
|
|
Set the
You can reset
or in the C shell by entering:
|
Oracle Forms Developer and Reports Developer products use dynamic, or shared, libraries. Therefore, you must set |
|
Note: On Windows, Oracle Application Server Forms Services reads Oracle environment settings from the Windows Registry unless they are set as environment variables. |
Oracle Application Server Forms Services contains features to help administrators manage user sessions, including:
By default, users can create a new Forms session, which is indicated by the green traffic light. You can also enable users to create Forms sessions after you've disabled them.
To allow new Forms User sessions:
From the Enterprise Manager Oracle Application Server Forms Services Overview page, click Enable (default).
The traffic light changes to green
To disable new user Forms user sessions:
From the Enterprise Manager Oracle Application Server Forms Services Overview page, click Disable.
The traffic light changes to yellow.
When you press Disable, a new parameter is added to the default section of the formsweb.cfg file. The parameter is called allowNewConnections and pressing Disable sets it to false. When new user sessions are disabled, attempted connections will be directed to a URL identified by the formsweb.cfg parameter connectionDisallowedURL (default section) e.g:
connectionDisallowedURL=www.oracle.com connectionDisallowedURL=http://www.oracle.com
If no connectionDisallowedURL is specified then the following message will be displayed in the browser:
The Forms Servlet will not allow new connections. Please contact your System Administrator.
However, when you disable new user sessions, existing forms sessions are unaffected and the OC4J instance remains up.
Start the Oracle Enterprise Manager 10g Application Server Control Console.
Select the link to the Forms Services instance that has the user session to be terminated.
From the Overview page for the Forms Services instance, select the Session Details link.
Click the radio button next to the user session to be deleted.
Click Stop.
The Confirmation page appears.
Click Yes.
The user session is deleted and the Runform instance is terminated.
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 therestrictedURLparams parameter through the Configuration page of Enterprise Manager Application Server Control Console.
|
A Forms administrator can override this default behavior, and give the Forms administrator full control over what parameter can be used in the URL.
Here are two scenarios to consider when deciding which parameters to allow or not allow in a URL. The first scenario is when an administrator just wants to restrict the usages of the USERID parameter in the URL that forces the end-user to always log in using the default login window. The second scenario is when an administrator would like to disable all parameters except a few, such as CONFIG=MyApp in a URL.
The parameter restrictedURLparams allows flexibility for the Forms administrator to consider any URL-accessible parameter in the formsweb.cfg file as restricted to a user. An administrator can specify this parameter in a named configuration section to override the one specified in the default configuration section. The restrictedURLparams parameter itself cannot be set in the URL.
Figure 4-1, "Defining the restricedURLparams Parameter" is an example of how the restrictedURLparams parameter is defined in the [myApp] section to override the one set in the [default] configuration section:
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.
The test form runs when you access an Oracle Forms URL but do not specify an application to run. For example, normally you call an Oracle Forms application with the following syntax:
http://<host>:<port>/forms/frmservlet?config=myApp
The Forms Servlet will locate [myApp] in the formsweb.cfg file and launch that application. However, when no application is specified, for example:
http://<host>:<port>/forms/frmservlet
the Forms Servlet uses the settings in the default section of the formsweb.cfg file. These settings are located under [default] in the Forms Configuration file (anytime an application does not override any of these settings, the defaults are used). The default section has the following setting:
form=test.fmx
This is the test form which allows you to test your Oracle Forms Services installation and configuration. Thus if you don't specify an application, Forms will launch the test.fmx file. You could change this to:
form=
and the form will not run. However, this is not optimal; the Forms Servlet still sends the dynamically generated HTML file to the client, from which a curious user could obtain information. The optimally secure solution is to redirect requests to an informational HTML page that is presented to the client instead. You'll need to change some parameters in the formsweb.cfg file.
Here are the parameters to change, along with their default values when you install Oracle Forms Services:
# System parameter: default base HTML file
baseHTML=base.htm
# System parameter: base HTML file for use with JInitiator client
baseHTMLjinitiator=basejini.htm
# System parameter: base HTML file for use with Sun's Java Plug-In
baseHTMLjpi=basejpi.htm
# System parameter: base HTML file for use with Microsoft Internet Explorer
# (when using the native JVM)
baseHTMLie=baseie.htm
These parameters are templates for the HTML information that are sent to the client. Create an informational HTML page and have these variables point to that instead. For example, in the ORACLE_HOME/forms/server directory, create a simple HTML page called forbidden.html with the following content:
<html>
<head>
<title>Forbidden</title>
</head>
<body>
<h1>Forbidden!</h1>
<h2>You may not access this Forms application.</h2>
</body>
</html>
|
Note: this redirecting of client information and presenting a message page instead is not the same Web page that the Web server returns when the requested content has restricted permissions on it. |
Next, modify the formsweb.cfg parameters by commenting out or modifying the original parameters:
# System parameter: default base HTML file
#baseHTML=base.htm
baseHTML=forbidden.html
# System parameter: base HTML file for use with JInitiator client
#baseHTMLjinitiator=basejini.htm
baseHTMLjinitiator=forbidden.html
# System parameter: base HTML file for use with Sun's Java Plug-In
#baseHTMLjpi=basejpi.htm
baseHTMLjpi=forbidden.html
# System parameter: base HTML file for use with Microsoft Internet Explorer
# (when using the native JVM)
#baseHTMLie=baseie.htm
baseHTMLie=forbidden.html
When a user enters the URL
http://<host>:<port>/forms/frmservlet
the customized Web page is presented. Of course, you can customize forbidden.html, including its contents, its filename, and its location as long as you make the corresponding changes to these parameters in the formsweb.cfg file. Administrators can put any information, such as warnings, errors, time stamps, IP logging, or contact information in this information Web page with minimal impact on the server configuration.
|
Note: Overriding the base HTML template entries in the default section of formsweb.cfg requires that you add the same entries pointing to the original values (or some other valid HTML file) in your application-specific named configuration:[myApp] form=myApplication.fmx lookandfeel=oracle baseHTML=base.htm baseHTMLjinitiator=basejini.htm baseHTMLjpi=basejpi.htm baseHTMLie=baseie.htm If you don't specify these base HTML values, and when a user runs an application, they will see the forbidden.html page because the application-specific configuration section hasn't overridden the default values. |
Consider creating your own HTML file templates (by modifying the templates provided by Oracle). By doing this, you can hard-code standard Forms parameters and parameter values into the template. Your template can include standard text, a browser window title, or images (such as a company logo) that would appear on the first Web page users see when they run Web-enabled forms. Adding standard parameters, values, and additional text or images reduces the amount of work required to customize the template for a specific application. To add text, images, or a window title, simply include the appropriate tags in the template HTML file.
See Chapter 3, "Specifying Special Characters in Values of Runform Parameters" for information about coding the serverArgs applet parameter.
In order to integrate graphics applications with your Oracle Forms applications, you must set the path definition in the Forms Servlet environment to include graphics as follows:
PATH=ORACLE_HOME/bin;<GRAPHICS6I_HOME>/bin
The path definition of the Forms Servlet environment, is taken from the path definition of the servlet container. The file or location where the path will be defined is different for different servlet containers.
For more information about graphics, see Oracle Forms Developer and Oracle Application Server Forms Services: Migrating Forms Applications from Forms6i and Deploying Graphics in Oracle9iAS Forms Services, available at Oracle Technology Network (OTN), http://www.oracle.com/technology/products/forms/.
Due to a limitation in the 8.0.6 RSF, Oracle Graphics 6i on Windows cannot connect to a 64-bit database. Thus, if you are using Oracle Forms 10g (9.0.4) or later to connect to a 64-bit database, and want to integrate with Oracle Graphics, you will need to upgrade your Oracle 6i Home (where Graphics is installed) to include an RSF version that contains a fix to bug 3088708. Please contact Oracle Support regarding availability of such an RSF.
Perform the following to correctly setup Reports/Graphics for Forms/Reports/Graphics integration:
In the graphicsrun.sh script enter the following:
ORACLE_GRAPHICS6I_HOME=<location forms6i> export ORACLE_GRAPHICS6I_HOME TK_PRINTER=<real printer>
In the reports.sh script enter the following:
ORACLE_GRAPHICS6I_HOME=<location forms6i>; export ORACLE_GRAPHICS6I_HOME REPORTS_DEFAULT_DESPLAY=NO; export REPORTS_DEFAULT_DESPLAY DISPLAY=<computer name>:0.0; export DISPLAY
This section explains how to specify the default location and search paths for icons and images in Registry.dat.
Use Application Server Control to change, add, or delete parameters from Registry.dat.
To change a Registry.dat parameter value:
Select the Configuration page of Enterprise Manager.
From the View dropdown list, select Forms Font and Icon Mapping (Registry.dat).
Select a radio button next to a parameter and change the value(s) for it in the Value text field.
Click Apply.
Your changes are saved.
To add a Registry.dat parameter and its value:
Select the Configuration page of Enterprise Manager.
From the View dropdown list, select Forms Font and Icon Mapping (Registry.dat).
At the bottom of the Registry.dat page, enter a name for the parameter in the Name text field.
Enter a value for this new parameter in the Value text field.
Click Add New Parameter.
Your changes are saved.
To delete a Registry.dat parameter and its value:
Select the Configuration page of Enterprise Manager.
From the View dropdown list, select Forms Font and Icon Mapping (Registry.dat).
Select a radio button next to a parameter and click Delete.
The Confirmation page appears, click Yes.
The parameter is deleted and the Configuration page reappears.
When deploying an Oracle Forms application, the icon files used must be in a Web-enabled format, such as JPG or GIF (GIF is the default format).
By default, the icons are found relative to the DocumentBase directory. That is, DocumentBase looks for images in the directory relative to the base directory of the application start HTML file. As the start HTML file is dynamically rendered by the Forms Servlet, the forms directory becomes the document base.
For example, if an application defines the icon location for a button with myapp/<iconname>, then the icon is looked up in the directory forms/myapp.
To change the default location, set the imageBase parameter to codebase in the Forms Web Configuration page of Enterprise Manager Application Server Control Console. Alternatively, you can change the default.icons.iconpath value of the Registry.dat file in the forms/java/oracle/forms/registry directory.
Setting the imageBase parameter to codebase enables Oracle Forms to search the forms/java directory for the icon files. Use this setting if your images are stored in a Java archive file. Changing the image location in the Registry.dat configuration file is useful if you want to store images in a central location independent of any application and independent of the Oracle Forms installation.
If an application uses a lot of custom icon images, it is recommended you store icons in a Java archive file and set the imageBase value to codebase. The icon files can be zipped to a Java archive via the Jar command of any Java Software Development Kit (Java SDK).
For example, the command jar -cvf myico.jar *.gif packages all files with the extension .gif into an archive file with the name myico.jar.
In order for Oracle Forms to access the icon files stored in this archive, the archive needs to be stored into the forms/java directory. Also, the name of the archive file must be part of the archive tag used in the custom application section of the formsweb.cfg file (for example, archive_jini=frmall_jinit.jar, myico.jar). Now, when the initial application starts, the icon files are downloaded to and permanently stored on the client until the archive file is changed.
|
Note: You do not need to deploy Oracle Forms default icons (for example, icons present in the default smart icon bar), as they are part of thefrmall.jar file.
|
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:
Copy the Registry.dat text file found in the ORACLE_HOME/forms/java/oracle/forms/registry directory to another directory. This directory must be mapped to a virtual directory for your Web server (for example, /appfile).
Rename this new file (for example, myapp.dat).
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" describes the correct locations where to place your application icons:
Table 4-12 Icon Location Guide
| Icon Location | When | How |
|---|---|---|
|
DocumentBase |
Default. Applications with few or no custom icons. |
Store icons in forms directory or in a directory relative to forms. |
|
Java Archives |
Applications that use many custom icons |
Set |
|
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. |
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.
Each time you use an icon or an image (for a splash screen or background), an HTTP request is sent to the Web server. To reduce the HTTP round-trips between the client and the server, you have the ability to store your icons and images in a Java archive (Jar) file. Using this technique, only one HTTP round-trip is necessary to download the Jar file.
The Java SDK comes with an executable called jar. This utility enables you to store files inside a Java archive. For more information, see http://java.sun.com/.
For example:
jar -cvf myico.jar Splash.gif Back.gif icon1.gif
This command stores three files (Splash.gif, Back.gif, icon1.gif) in a single Jar file called myico.jar.
The default search path for the icons and images is relative to the DocumentBase. However, when you want to use a Jar file to store those files, the search path must be relative to the CodeBase directory, the directory which contains the Java applet.
If you want to use a Jar file to store icons and images, you must specify that the search path is relative to CodeBase using the imageBase parameter in the formsweb.cfg file or HTML file.
This parameter accepts two different values:
DocumentBase The search path is relative to the DocumentBase directory. It is the default behavior.
CodeBase The search path is relative to the CodeBase directory, which gives the ability to use Jar files.
In this example, we use a JAR file containing the icons and we specify that the search should be relative to CodeBase. If the parameter imageBase is not set, the search is relative to DocumentBase and the icons are not retrieved from the Jar file.
For example (formsweb.cfg):
archive=frmall.jar, icons.jar imageBase=codebase
The icons and images search path depends on:
What you specify in your custom application file (for the icons).
What you specified in the splashScreen and background parameters of your default Forms Web configuration or HTML file (for the images).
What you specify in the imageBase parameter in the Forms Web Configuration page of Application Server Control for the file or HTML file (for both icons and images).
Forms Services searches for the icons depending on what you specify. This example assumes:
host is the computer name.
DocumentBase is the URL pointing to the HTML file.
CodeBase is the URL pointing to the location of the starting class file (as specified in the formsweb.cfg file or HTML file).
mydir is the URL pointing to your icons or images directory.
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 |
|
|
(specified in your application file) |
(relative path) |
|
(specified in your application file) |
(absolute path) |
Table 4-14 Search Paths for Images
| Location Specified | Search path used by Forms Services |
|---|---|
|
file.gif (specified, for example, in formsweb.cfg as splashscreen=file.cfg) |
|
|
|
(relative path) |
|
|
(absolute path) |
|
file.gif (specified, for example, in formsweb.cfg as |
|
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 |
|
|
(specified in your application file) |
(relative path) |
|
(specified in your application file) |
(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 |
|
|
(specified in your HTML file) |
(relative path) |
|
(specified in your HTML file) |
(absolute path) No Jar file is used. |
Oracle Forms architecture supports deployment in multiple languages. The purpose of this feature is to automatically select the appropriate configuration to match a user's preferred language. In this way, all users can run Oracle Forms applications using the same URL, yet have the application run in their preferred language. As Oracle Forms Services do not provide an integrated translation tool, you must have translated application source files.
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
Inline IME support enables Forms Web applications to properly display the composing text in which each character may not be directly represented by a single keystroke (e.g. Asian characters) near the insertion cursor (so called inline, or on-the-spot). It is enabled by default. To disable, set the applet parameter "inlineIME" to "false" in the baseHTML file:
<HTML> <!-- FILE: basejini.htm (Oracle Forms) --> <BODY> ... <OBJECT classid=... > <PARAM NAME="inlineIME" VALUE="false"> <EMBED SRC="" ... inlineIME="false" > ... . </BODY> </HTML> . To have inline IME support, forms client needs to be Jinitator 1.3.1 or Plug-in 1.4.1+.
For more information about using baseHTML, see Appendix C, "base.htm, basejini.htm, and basejpi.htm Files".
When the Forms Servlet receives a request for a particular configuration (for example, http://myserv/servlet/frmservlet?config=hr) it gets the client language setting from the request header "accept-language". This gives a list of languages in order of preference. For example, accept-language: de, fr, en_us means the order of preference is German, French, then US English. The servlet will look for a language-specific configuration section matching the first language. If one is not found, it will look for the next and so on. If no language-specific configuration is found, it will use the base configuration.
When the Forms Servlet receives a request with no particular configuration specified (with no "config=" URL parameter, for example, http://myserv/servlet/frmservlet), it will look for a language-specific section in the default section matching the first language (for example, [.fr]).
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:
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]),
Then, if not found, the value is looked for in the base configuration section ([myconfig],
Then, failing that, in the language-specific default section (for example, [.fr]),
And finally in the default section.
Typically, the parameters which are most likely to vary from one language to another are "workingDirectory" and "envFile". Using a different envFile setting for each language lets you have different values of NLS_LANG (to allow for different character sets, date and number formats) and FORMS_PATH (to pick up language-specific fmx files). Using different workingDirectory settings provides another way to pick up language-specific.fmx files.
A key binding connects a key to an application function. When you bind a key to a function, the program performs that function when you type that keystroke. You define key bindings in the fmrweb.res file in the ORACLE_HOME/admin/resource/<language directory> directory in UNIX, for example ORACLE_HOME/forms/admin/resource/US. For Windows, the location is ORACLE_HOME\forms.
By defining key bindings, you can integrate a variety of keyboards to make an application feel similar on each of them.On some platforms not all keys are able to be re-mapped. For example, on Microsoft Windows, because keys are defined in the Windows keyboard device driver, certain keys cannot be re-mapped. Key combinations integral to Windows, such as Alt-F4 (Close Window) and F1 (Help) cannot be re-mapped. As a general rule, keys which are part of the ÒextendedÓ keyboard also cannot be re-mapped. These keys include the number pad, gray arrow and editing keys, Print Screen, Scroll Lock, and Pause.
Note: If running with different NLS_LANG settings a different resource file will be used. e.g. NLS_LANG=GERMAN_GERMANY=WE8ISO8859P1 fmrwebd.res file will be used.There is a resource file for each supported language. To override this, pass parameter term=fullpath\filename.res to the Oracle Forms Runtime process.
It is possible to pass this parameter directly within the URL. For example:
http://hostname/forms/f90servlet?Form=test.fmx&term=fullpath\filename.res
You can also set this parameter in the formsweb.cfg file, for example:
otherParams=term=fullpath\filename.res
fmrweb.res is a text file which can edited with a text editor such as vi in UNIX or Notepad or Wordpad on Windows. Unlike Oracle 6i Forms, Oracle Terminal editor is no longer required. The text file is self-documented.
|
Note: The customization is limited, particularly compared to character mode forms. You cannot editfmrweb.res with Oracle Enterprise Manager Application Server Control.
|
In the section marked USER-READABLE STRINGS, find the entries with
122 : 0 : "F11" : 76 : "Enter Query" 122 : 2 : "Ctrl+F11" : 77 : "Execute Query"
and change them to:
122 : 2 : "Ctrl+F11" : 76 : "Enter Query" 122 : 0 : "F11" : 77 : "Execute Query"
|
Note: By defaultfmrweb.res does not reflect the Microsoft Windows client-server keyboard mappings. It reflects the key mapping if running client-server on Unix X-Windows/Motif.
|
A file called fmrpcweb.res has also been provided which gives the Microsoft Windows client-server keyboard mappings. To use this file, rename fmrpcweb.res e.g to fmrweb_orig.res, and copy fmrpcweb.res to fmrweb.res. Alternatively use the term parameter as described above.
The following examples show special key mappings:
Section 4.11.1.2.2, "Mapping for ENTER to Fire KEY-ENTER-TRIGGER"
Section 4.11.1.2.4, "Mapping for ESC Key to exit out of a Web Form"
To map F2, change the default entry for F2, "List Tab Pages", to another key. Here is an example of the default entry:
113: 0 : "F2" : 95 : "List Tab Pages"
This must be explicitly changed to another key mapping such as the following:
113: 8 : "F2" : 95 : "List Tab Pages"
To map the F2 function to the F2 key, comment out the lines that begin with "113 : 0" and "113 : 3" with a # symbol and add the following lines to the bottom of the resource file:
113: 0 : "F2" : 84 : "Function 2" 113: 8 : " " : 95 : " "
Since a new function has been added which uses F2 by default, it is necessary to explicitly map this new function to something else in order to map the F2 key. This function was added to allow for keyboard navigation between the tab canvas pages and it defaults to F2. Even if it is commented out and not assigned to F2, the F2 key cannot be mapped unless this function, Forms Function Number 95, is mapped to another key.
By default, whether deploying client-server or over the web pressing the ENTER key takes the cursor to the next navigable item in the block. To override this default behavior it is necessary to modify the forms resource file to revise the key mapping details.
Modify FMRWEB.RES and change the Forms Function Number (FFN) from 27 to 75 for the Return Key. The line should be changed to the following:
10 : 0 : "Return" : 75 : "Return"
By default, the line is displayed with an FFN of 27 and looks as follows:
10 : 0 : "Return" : 27 : "Return"
This line should NOT fire the Key-Enter trigger since the Return or Enter key is actually returning the Return function represented by the FFN of 27. The FFN of 75 represents the Enter function and will fire the Key-Enter trigger.
The objective is to map CTRL+<number> keys in fmrweb.res for numbers 0 to 9 and there are no Java Function keys mentioned for the numbers in fmrweb.res. The steps to be performed along with an example that shows the steps needed to map CTRL+1 to 'Next Record'
List the java function key numbers that could be implemented in fmrweb.res file for the Key Mapping. For example:
public static final int VK_1 = 0x31;
The hexadecimal values have to be converted to their decimal equivalents before their use in fmrweb.res.
In step (1), 0x31 is a hexadecimal value that has to be converted to its decimal equivalent. (Note:1019580.6) e.g:
SQL> select hextodec('31') from dual;
HEXTODEC('31')
--------------
49
Use this decimal value for mapping the number key 1 in fmrweb.res For example, CTRL+1 can be mapped to 'Next Record' as:
49 : 2 : "CTRL+1" : 67 : "Next Record"
Make a backup copy of fmrweb.res
Open the fmrweb.res file present in the path ORACLE_HOME/FORMS and add the following entry in it:
27 : 0 : "Esc" : 32 : "Exit"
Ensure that you comment or delete the old entry
#115 : 0 : "F4" : 32 : "Exit"
The first number (115) might differ on different versions or platforms. When you run the Web Form and press the ESC key, then the Form will exit.
