Oracle Application Server Forms Services Deployment Guide 10g (9.0.4) Part Number B10470-01 |
|
This chapter contains the following sections:
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.
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:
When you install Forms Services, the Oracle Universal Installer automatically edits Enterprise Manager's targets.xml file. The targets.xml file contains a list of all the services to be managed by Enterprise Manager.
The first time you use Enterprise Manager to monitor Forms Services, you must perform the following steps for each Forms Services instance to be monitored.
See the Enterprise Manager documentation for information on how to use the Application Server Control to access the Enterprise Manager Administration page for a a node. (You will need to provide an administrator's username and password.)
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, you start by navigating to the Forms Home page for the Forms Server in the Application Server Control.
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.
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: You should backup the formsweb.cfg and default.env files before editing them with Enterprise Manager. |
For a description and the location of the Forms Servlet configuration file (formsweb.cfg), see Chapter 3.2.1.2, "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:
Parameter | Value |
---|---|
baseHTML |
base.htm |
|
baseie.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>/forms90/server.
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.
The Forms New Section Name page appears.
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:
Parameter | Value |
---|---|
forms |
<module> |
separateFrame |
True |
lookandfeel |
Generic |
Your users would type the following URL to launch a form that uses the "sepwin" (or whatever name you applied) configuration:
http://server:port/forms90/f90servlet?config=sepwin
You can also use Application Server Control to create named configuration sections (see Chapter 7, "Tracing and Diagnostics").
See Appendix B.1, "Default formsweb.cfg File" for other examples of special configurations.
You can make a copy of a named configuration for backup purposes, or create new configuration sections from duplicates.
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, select the radio button next to the section name and click Edit.
The Confirmation page appears.
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.
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.
The Edit Section page appears for that selected configuration.
Your changes are saved.
The Edit Section page appears for that selected configuration.
The Forms Configuration Section Parameters page refreshes and displays the new parameter.
The Edit Section page appears for the selected configuration.
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 single sign-on parameters, see Chapter 6.4, "Enabling Single Sign-On for an Application".
These sections include:
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.
All parameters from here on match variables (%parameterName%
) in the baseHTML file. These variables are replaced with the parameter values specified in the URL query string, or failing that, in the formsweb.cfg file. See Chapter 3.3.4, "Specifying Special Characters in Values of Runform Parameters" for information about how runform handles certain special characters that are specified in runform parameter values.
Parameter | Required / Optional | Parameter Value |
---|---|---|
|
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
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 |
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 may not be set using URL query 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%">
Parameter | Required / Optional | Parameter Value |
---|---|---|
|
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 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. |
|
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. |
|
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. |
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:
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 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.
The traffic light changes to green
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.
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 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:
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.
Consider creating your own HTML file templates (by modifying the templates provided by Oracle). By doing this, you can hard-code standard Forms parameters and parameter values into the template. Your template can include standard text, a browser window title, or images (such as a company logo) that would appear on the first Web page users see when they run Web-enabled forms. Adding standard parameters, values, and additional text or images reduces the amount of work required to customize the template for a specific application. To add text, images, or a window title, simply include the appropriate tags in the template HTML file.
See Chapter 3.3.4, "Specifying Special Characters in Values of Runform Parameters" for information about coding the serverArgs applet parameter.
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/.
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.
When deploying an Oracle Forms application, the icon files used must be in a Web-enabled format, such as JPG or GIF (GIF is the default format).
By default, the icons are found relative to the DocumentBase directory. That is, DocumentBase looks for images in the directory relative to the base directory of the application start HTML file. As the start HTML file is dynamically rendered by the Forms Servlet, the forms90 directory becomes the document base.
For example, if an application defines the icon location for a button with myapp/<iconname>, then the icon is looked up in the directory forms90/myapp
.
To change the default location, you can set the imageBase parameter to codebase in the Forms Web Configuration page of Enterprise Manager Application Server Control. Alternatively, you can change the default.icons.iconpath value of the Registry.dat file in the forms90/java/oracle/forms/regsistry directory.
Setting the imageBase parameter to codebase enables Oracle Forms to search the forms90/java directory for the icon files. Use this setting if your images are stored in a Java archive file. Changing the image location in the Registry.dat configuration file is useful if you want to store images in a central location independent of any application and independent of the Oracle Forms installation.
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.
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.
default.icons.iconpath=/mydir or http://myhost.com/mydir
default.icons.iconpath=mydir
default.icons.iconextension=gif
default.icons.iconextension=jpg
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)
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 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.
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.
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:
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
The icons and images search path depends on:
Forms Services searches for the icons depending on what you specify. This example assumes:
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:
Use the imageBase=CodeBase parameter to enable the search of the icons and images in a JAR file:
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.
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
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]).
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:
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.
|
Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|