|Oracle® Fusion Middleware Forms Services Deployment Guide
11g Release 2 (11.1.2)
Part Number E24477-02
|PDF · Mobi · ePub|
This chapter contains the following sections:
Tuning the connection between Oracle Forms Services and the Oracle Database Server is beyond the scope of this chapter.
Use Fusion Middleware Control to monitor Oracle Forms Services and review metrics information, including:
Forms Services Instances
Use the Forms Home page to monitor metrics for a Forms Services instance.
Start Enterprise Manager Fusion Middleware Control.
From the Enterprise Manager Fusion Middleware Control main page, select the link to the Forms Services instance that you want to monitor.
The Forms Home page for the Forms Services instance displays the following:
Status of Forms application instance (up, down, unknown)
URL of the Forms Services instance being monitored
Number of Forms sessions
Additionally, you can navigate to the following detail pages:
In the Performance Summary page, you can add charts for other Forms metrics to the page dynamically by using the Show Metric Palette. You can also overlay metrics to compare them. For example, drag and drop Private Memory consumed by two JVM Controllers into one chart to compare them. For more information, see the Oracle Fusion Middleware Performance Guide.
Use the Enterprise Manager Fusion Middleware Control to enable tracing for all events or specific ones. See Table 14-1 for a list of tasks you can perform on this page.
Forms Runtime Pooling (or Forms Runtime prestart) enables the startup of a configurable number of application runtime engines prior to their usage. Runtime Pooling provides quick connections at server peak times, which shortens the server-side application startup time. Runtime pooling is useful for situations where server configurations have a small window in which many users connect to a Forms application. All prestarted runtime engines run in the same environment serving the same application.
Use Enterprise Manager Fusion Middleware Control to configure runtime pooling for Forms Services with the following parameters as described in Table 14-2:
Table 14-2 Forms Runtime Pooling Parameters
|Parameter Name||Data type||Description||Default Value|
Runtime pre starting or pooling is enabled only if true
Number of the runtime processes that should be spawned initially
Time in minutes after which all the prestarted processes of this pool (configuration section) will be stopped. A runtime process is removed from the prestart pool once client connection is made and thus will not be stopped.
0 (When set to zero the timer never starts)
Minimum number of runtime processes to exist in the pool.
The number of runtime processes to be created when the number of prestarted runtime processes is less than minRuntimes.
prestartMin defines the minimum number of pre-started runtimes that must exist at any time while runtime pooling is still active for a specific application. The minimum value must be less than or equal to what's defined for the
prestartInit parameter. The
prestartMin parameter can be modified at any time and does not require the application server to be restarted. The new entries will be picked up when a client requests a connection to a pre-started runtime process and the prestarted runtime processes have not timed out. Once they have timed out, an application uses default behavior and a minimum threshold is not maintained.
Each configuration section can specify values for these parameter. If the
prestartRuntimes = true entry is found, but there is no associating prestart parameter, then default values are used.
In a load balanced system that has multiple instances of Oracle WebLogic Managed Server, the various values provided for the above parameters are on a per JVM basis, and not the total for the application.
An Administrator can configure specific application(s), from the Enterprise Manager Fusion Middleware Control, to enable Runtime Pooling. On the startup of the application server (Oracle WebLogic Managed Server), the configured number of Forms Runtime processes are pre-started for each application.
In the initialization phase of the Forms servlet, the configuration file (
formsweb.cfg) is read and the server pre-starts the applications which have the
prestartRuntimes parameter enabled.
Scheduling Runtime Pooling (or Scheduling Runtime Prestart) is a feature that enables you to schedule the prestart of Forms Runtime engines. In addition to managing the startup of a configurable number of Forms Runtime engines prior to their usage, Oracle Forms now allows you to schedule the prestarting of Forms Runtime processes on a more flexible basis, at any appropriate time. You can schedule a Forms Runtime prestart, view existing schedules, delete any existing schedule, and export and import a schedule using the Enterprise Manager Fusion Middleware Control.
Creating a Prestart Schedule
To create a prestart schedule, perform the following steps:
From the Forms Menu, select Schedule Prestart.
The Schedule Prestart page is displayed.
From the Scheduled Jobs region, click Create.
Figure 14-1 shows the page that is displayed for scheduling a prestart.
Figure 14-1 Scheduling Forms Runtime Prestart
In Job Name, enter a name for the schedule.
Maximum length of the job name must not exceed 100 characters. The name must not contain any special characters such as ampersand (&).
From the Configuration Section list, choose a configuration type.
This list contains a logical set of parameters.
In Prestart Init, enter a numerical value for the number of runtime processes that must be spawned initially. Ensure that the value is greater than or equal to 1.
In Prestart Timeout, enter a numerical value for the time in minutes after which the unused prestart process will be stopped. If this value is set to zero, the timer never starts and thus the processes do not time out.
From the Schedule Type options, select the appropriate schedule type.
Following are the three types of schedules that you can set:
One Time(Delay based): Select this option if you want to schedule a single occurence prestart based on the initial delay. Initial delay is a time based parameter that specifies the number of hours or minutes after which the prestart will begin. If you select this option, you must enter the initial delay time (in hours or minutes) in the Initial delay field that appears below the schedule type.
One Time(Date based): Select this option if you want to schedule a single occurence prestart based on a date. If you select this option, you must enter the date and time in the Start Date field that appears below the Schedule type.
Repeating: Select this option if you want to schedule a repeat prestart. From the Frequency list, you can select one of the following options:
Repeat date and interval: If you select this option, you must specify the start date and interval after which you want the prestart to repeat.
Repeat initial delay and interval: If you select this option, you must specify the initial delay and interval after which you want the prestart to repeat.
You can click Show Jobs to view all the prestart schedules that are created.
Deleting a Prestart Schedule
To delete a prestart schedule, perform the following steps:
From the Forms Menu, select Schedule Prestart.
The Schedule Prestart page is displayed.
From the Scheduled Jobs region, select the row of the scheduled prestart that you want to delete.
You can select multiple rows to delete at the same time.
The selected prestart schedule is deleted.
Exporting and Importing Prestart Schedules
This utility allows you to export all existing schedules from a particular managed server and import it to some other managed server. This feature does not allow the users to export schedules selectively; the user must export all existing schedules. To export and import prestart schedules, perform the following steps:
From the Forms Menu, select Schedule Prestart.
The Schedule Prestart page is displayed.
From the Scheduled Jobs region, click Export.
A dialog box appears.
Enter a new file name in the dialog box.
The file name must contain
This will create an xml file that contains the attributes of all prestart schedules. Depending on your browser settings, you will either be prompted to choose a location to save the file in, or the file will be saved at a default location on you local machine.
To import the schedules (that you have exported in the above steps) to some other managed server, go to the Schedule Prestart page of that server, and click Import.
A dialog box appears.
Enter the name of the file that you created while exporting the schedules. You can also click Browse on the dialog box and upload the
xml file from you local machine.
The imported schedules will now be listed in the Scheduled Jobs region.
If there is an error in any schedule entry in the
xml file, the server skips that particular schedule and imports the next schedule entry. If there are any expired schedules in the
xml file, they are ignored and not imported.
The Java client is primarily responsible for rendering the application display. It has no embedded application logic. Once loaded, a Java client can display multiple forms simultaneously. Using a generic Java client for all Oracle Forms applications requires fewer resources on the client when compared to having a customized Java client for each application.
The Java client is structured around many Java classes. These classes are grouped into functional subcomponents, such as displaying the splash screen, communicating with the network, and changing the look-and-feel. Functional subcomponents allow the Forms Developer and the Java Virtual Machine (JVM) to load functionality as it is needed, rather than downloading all of the functionality classes at once.
When a form definition is loaded from an FMX file, the profile of the executing process can be summarized as:
Of these, only the data segments section is unique to a given instance of an application. The encoded program units and boilerplate objects/images are common to all application users. Forms Services maps the shared components into physical memory, and then shares them between all processes accessing the same FMX file.
The first user to load a given FMX file will use the full memory requirement for that form. However, subsequent users will have a greatly reduced memory requirement, which is dependent only on the extent of local data. This method of mapping shared components reduces the average memory required per user for a given application.
Bandwidth is a valuable resource, and the general growth of Internet computing puts an ever increasing strain on the infrastructure. Therefore, it is critical that applications use the network's capacity sparingly.
Oracle Forms Services communicates with the Java client using metadata messages. Metadata messages are a collection of name-value pairs that tell the client which object to act upon and how. By sending only parameters to generic objects on the Java client, there is approximately 90-percent less traffic (when compared to sending new code to achieve the same effect).
Oracle Forms Services intelligently condenses the data stream in three ways:
When sets of similar messages (collections of name-value pairs) are sent, the second and subsequent messages include only the differences from the previous message. This results in significant reductions in network traffic. This process is called message diff-ing.
When the same string is to be repeated on the client display (for example, when displaying multiple rows of data with the same company name), Oracle Forms Services sends the string only once, and then references the string in subsequent messages. Passing strings by reference increases bandwidth efficiency.
Data types are transmitted in the lowest number of bytes required for their value.
The extensive use of triggers within the Forms Developer model is a strength, but they can increase the effect of latency by requiring a network round trip for each trigger. Latency can be the most significant factor that influences the responsiveness of an application. Note that latency is not the same as network speed. Network speed involves a measure of the bits that can be transported per time unit whereas latency is the time taken for one bit to travel from one end-point to the other. One of the best ways to reduce the effects of latency is to minimize the number of network packets sent during a conversation between the Java client and the Forms Services.
Oracle Forms Services implements event bundling by grouping trigger events together through Event Bundling. Event Bundling gathers all of the events triggered while navigating between the two objects, and delivers them as a single packet to Oracle Forms Services for processing.
For example, when a user navigates from item A to item B (such as when tabbing from one entry field to another), a range of pre- and post-triggers may fire, each of which requires processing on the Forms Services. When navigation involves traversing many objects (such as when a mouse click is on a distant object), Event Bundling gathers all events from all of the objects that were traversed, and delivers the group to Oracle Forms Services as a single network message.
All boilerplate objects in a given form are part of a Virtual Graphics System (VGS) tree. VGS is the graphical subcomponent that is common to all Forms Developer products. VGS tree objects are described using attributes such as coordinates, colors, line width, and font. When sending a VGS tree for an object to the Java client, the only attributes that are sent are those that differ from the defaults for the given object type.
Images are transmitted and stored as compressed JPEG images. This reduces both network overhead and client memory requirements.
Minimizing resources includes minimizing the memory overhead of the client and server processes. Optimal use of the network requires that bandwidth be kept to a minimum and that the number of packets used to communicate between the client and Oracle Forms Services be minimized in order to contain the latency effects of the network.
An application developer can take steps to ensure that maximum benefits are gained from Forms Services' built-in architectural optimizations. The remainder of this chapter discusses key performance issues that affect many applications and how developers can improve performance by tuning applications to exploit Forms Services features.
The Forms Java client is only responsible to display the GUI objects. All of the Oracle Forms logic runs in Oracle Forms Services, on the middle tier. This includes inserting or updating the data to the database, querying data from the database, executing stored procedures on the database, and so on. Therefore, it is important to have a high-speed connection (high bandwidth and not low latency) between the application server and the database server.
All of this interaction takes place without any communication to the Forms Java client. Only when there is a change on the screen is there any traffic between the client and Forms Services. This allows Oracle Forms applications to run across slower networks (high latency networks), such as with modems or satellites.
The configuration in Figure 14-2, displays how Forms Services and the database server are co-located in a data center.
First impressions are important, and a key criterion for any user is the time it takes to load an application. Startup time is regarded as overhead. It also sets an expectation of future performance. When a business uses thin-client technologies, the required additional overhead of loading client code may have a negative impact on users. Therefore, it is important to minimize load time wherever possible.
After requesting an Oracle Forms application, several steps must be completed before the application is ready for use:
Invoke Java Virtual Machine (JVM).
Load all initial Java client classes, and authenticate security of classes.
Display splash screen.
Load additional Java classes, as required.
Authenticate security of classes.
Render boilerplate objects and images.
Render all elements on the initial screen.
Remove splash screen.
Form is ready for use.
An application developer has little influence on the time it takes to launch the JVM. However, the Java deployment model and the structure of the Oracle Forms Developer Java client allow the developer to decide which Java classes to load and how. This, in turn, minimizes the load time required for Java classes.
The Java client requires a core set of classes for basic functionality (such as opening a window) and additional classes for specific display objects (such as LOV items). These classes must initially reside on the server, but the following techniques can be used to improve the time it takes to load these classes into the client's JVM:
Java provides the Java Archive (Jar) mechanism to create files that allow classes to be grouped together and then compressed (zipped) for efficient delivery across the network to the client. Once used on the client, the files are cached for future use.
It is also possible to double jar a file. This saves about 700k when done with
frmall.jar. For Oracle's plugin, the resulting file must have a suffix of
The following sections describe the pre-configured Jar files that Oracle Forms Services provides to support typical deployment scenarios.
frmall.jar includes all required classes for running with the Java Plug-in.
To specify one or more Jar files, use the archive setting in the named configuration section of the Forms Configuration file (
formsweb.cfg). For example,
Oracle's Java Plug-in supports the caching of Jar files for Oracle Forms Services. When the JVM references a class, it first checks the local client cache to see if the class exists in a pre-cached Jar file. If the class exists in cache, JVM checks the server to see if there is a more current version of the Jar file. If there isn't, the class is loaded from the local cache rather than from across the network.
Be sure that the cache is of proper size to maximize its effectiveness. Too small a cache size may cause valid Jar files to be overwritten, thereby requiring that another Jar file be downloaded when the application is run again. The default cache size is 20MB. This size should be compared with the size of the cache contents after successfully running the application.
Jar files are cached relative to the host from which they were loaded. This has implications in a load-balancing architecture where identical Jar files from different servers can fill the cache. By having Jar files in a central location and by having them referenced for each server in the load-balancing configuration, the developer can ensure that only one copy of each Jar file is maintained in the client's cache. A consequence of this technique is that certain classes within the Jar file must be signed to enable connections back to servers other than the one from which they were loaded. The Oracle-supplied Jar files already pre-sign the classes.
The developer can design the application to maximize the data stream compression, called message-diffing, that Forms automatically performs. This means that forms sends along data stream compression by using message diff-ing, which sends along only the information that differs from one message to another. The following steps can be taken to reduce the differences between messages:
Promote similarities between objects. Using similar objects improves message diff-ing effectiveness (in addition to being more visually appealing to the user). The following steps encourage consistency between objects:
Accept default values for properties, and change only those attributes needed for the object.
Use Smart Classes to describe groups of objects.
Lock the look-and-feel into a small number of visual attributes.
Reduce the use of boilerplate text. As a developer, you should use the PROMPT item property rather than boilerplate text wherever applicable. Forms Developer 6.0 and higher includes the Associate Prompt feature, which allows boilerplate text to be re-designated as the prompt for a given item.
Reduce the use of boilerplate items (such as arcs, circles, and polygons). All boilerplate items for a given Form are loaded at Form initialization. Boilerplate items take time to load and use resources on the client whether they are displayed or not. Common boilerplate items, namely rectangles and lines, are optimized. Therefore, restricting the application to these basic boilerplate items reduces network bandwidth and client resources while improving startup times.
Keep navigation to a minimum. An Event Bundle is sent each time a navigation event finishes, whether the navigation extends over two objects or many more. Design Forms that do not require the user to navigate through fields when default values are being accepted. A Form should encourage the user to quickly exit once the Form is complete, which causes all additional navigation events to fire as one Event Bundle.
Reduce the time to draw the initial screen. Once the Java client has loaded the required classes, it must load and initialize all of the objects to be displayed before it can display the initial screen. By keeping the number of items to a minimum, the initial screen is populated and displayed to the user more promptly. Techniques that reduce the time to draw the initial screen include:
Providing a login screen for the application with a restricted set of objects (such as a title, small logo, username, and password).
On the Form's initial display, hiding elements not immediately required. Use the canvas properties:
RAISE ON ENTRY = YES (Canvas only)
VISIBLE = NO
Pay attention to TAB canvases that consist of several sheets where only one will ever be displayed. For responsive switching between tabs, all items for all sheets on the canvas are loaded, including those that are hidden behind the initial tab. Consequently, the time taken to load and initialize a TAB canvas is related to all objects on the canvas and not just to those initially visible.
When using Tab canvases, use stacked canvases and display the right canvas in the when-tab-page-changed trigger. Remember to set the properties
RAISE ON ENTRY = YES and
VISIBLE = NO for all the canvases not displayed in the first screen.
Disable MENU_BUFFERING. By default, MENU_BUFFERING is set to True. This means that changes to a menu are buffered for a future "synchronize" event when the altered menu is re-transmitted in full. (Most applications make either many simultaneous changes to a menu or none at all. Therefore, sending the entire menu at once is the most efficient method of updating the menu on the client.) However, a given application may make only minimal changes to a menu. In this case, it may be more efficient to send each change as it happens. You can achieve this using the statement:
Set_Application_Property (MENU_BUFFERING, 'false');
The following techniques may further reduce the resources required to execute an application:
Examine timers and replace with JavaBeans. When a timer fires, an asynchronous event is generated. There may not be other events in the queue to bundle with this event. Although a timer is only a few bytes in size, a timer firing every second generates 60 network trips a minute and almost 30,000 packets in a typical working day. Many timers are used to provide clocks or animation. Replace these components with self-contained JavaBeans that achieve the same effect without requiring the intervention of Forms Services and the network.
Consider localizing the validation of input items. It is common practice to process input to an item using a When-Validate-Item trigger. The trigger itself is processed on the Forms Services. You should consider using pluggable Java components to replace the default functionality of standard client items, such as text boxes. Then, validation of items, such as date or max/min values, are contained within the item. This technique opens up opportunities for more complex, application-specific validation like automatic formatting of input, such as telephone numbers with the format (XXX) XXX-XXXX.
Reduce the application to many smaller forms, rather than one large form. By providing a fine-grained application, the user's navigation defines which objects are loaded and initialized from the Forms Services. With large Forms, the danger is that the application is delayed while objects are initialized, many of which may never be referenced. When chaining Forms together, consider using the built-ins OPEN_FORM and NEW_FORM:
With OPEN_FORM, the calling Form is left open on the client and the server, so that the additional Form on both the client and the server consumes more memory. However, if the Form is already in use by another user, then the increase in server memory is limited to just the data segments. When the user returns to the initial Form, it already resides in local memory and requires no additional network traffic to redisplay.
With NEW_FORM, the calling Form is closed on the client and the server, and all object properties are destroyed. Consequently, it consumes less memory on the server and client. Returning to the initial Form requires that it be downloaded again to the client, which requires network resources and startup time delays. Use OPEN_FORM to display the next Form in an application unless it is unlikely that the initial form will be called again (such as a login form).
Avoid unnecessary graphics and images. Wherever possible, reduce the number of image items and background images displayed in your applications. Each time an image is displayed to application users, the image must be downloaded from the application server to the user's Web browser. To display a company logo with your Web application, include the image in the HTML file that downloads at application startup. Do this instead of including it as a background image in the application. As a background image, it must be retrieved from the database or file system and downloaded repeatedly to users' computers.
Oracle Web Cache can be used as a load balancer with Oracle Forms applications.
The following setup instructions assume the following:
Oracle Web Cache instance running on Host A
Oracle HTTP Server instance and Oracle WebLogic Managed Server on Host B running Oracle Forms application D
Oracle HTTP Server instance and Oracle WebLogic Managed Server on Host C running Oracle Forms application D
Note that there could be more Oracle HTTP Server/Oracle WebLogic Managed Server, but only two instance pairs will be described here for purposes of simplification. The Oracle HTTP Server/Oracle WebLogic Managed Server are not configured for clustering/active failover because Oracle Forms applications cannot take advantage of Oracle WebLogic Server active failover.
Also note that a Web Cache 9.0.2.x cluster cannot be used. An Oracle Web Cache cluster can be used to load balance Oracle Forms starting with Oracle WebLogic Server.
A Forms client needs to be able to communicate with the same instance of the server process for the duration of a session. Since Forms applications are stateful, Web Cache must be configured for stateful load balancing using its session binding feature.
Configure Web Cache on Host A with the appropriate Site information for the Forms application, as well as Origin Server and Site-to-Server Mapping information for the Oracle HTTP Server instances running on Hosts B and C. When configuring Origin Server information for Hosts B and C, be sure to configure a ping URL that will detect whether Forms application D is running, for example,
Refer to the Oracle Fusion Middleware Installation Planning Guide for information on load balancing. Refer to the Oracle Fusion Middleware Enterprise Deployment Guide for Java EE and Oracle Fusion Middleware High Availability Guide for information on enterprise deployment architectures and high availability.
Add the following code to the weblogic.xml file located in
<session-tracking cookies="enabled"> </session-tracking>
Restart WLS_Forms Managed Server with:
Log on to the Web Cache Manager.
In the navigator pane, select Origin Servers, Sites, and Load Balancing |Session Binding.
In the Session Binding screen, select Default Session Binding, then select Edit Selected.
The Edit Session Binding dialog box appears.
From the Please select a session: pull-down list, select JSESSIONID.
Select Cookie-based as the session binding mechanism from the dropdown list for Oracle Forms application D.
Apply changes and restart Oracle Web Cache.
Using a browser, point it to the Web Cache host and access Oracle Forms application D. Ensure that the application works as expected. Keep the browser window open.
Identify the Oracle HTTP Server/Oracle WebLogic Managed Server that handled the requests. For example, assume this is Host B and shut down the Oracle HTTP Server/WebLogic Managed Server on that host. Now only the Oracle HTTP Server/WebLogic Managed Server running on Host C will be accessible.
Using the same browser that is running the Oracle Forms client, access Oracle Forms application D again. The request will fail, and the Forms client will lose its session. Remember that Oracle Forms session state is not replicated among Oracle WebLogic Managed Server.
Next, use the browser to start a new Forms session. Web Cache will direct the requests to the remaining Oracle HTTP Server/WebLogic Managed Server running on Host C. Ensure that the application works as expected.
Restart the Oracle HTTP Server/WebLogic Managed Server on Host B. Using a browser, log on to the Web Cache Manager. In the navigator pane, select Monitoring | Health Monitor.
On the Health Monitor screen, make sure that Host B is marked UP.
For additional information about Web Cache, see Oracle Fusion Middleware Web Cache Administrator's Guide.