Forms Personalization

The Form Personalization feature allows you to declaratively alter the behavior of Forms-based screens, including changing properties, executing builtins, displaying messages, and adding menu entries.

For each function (a form running in a particular context based on parameters passed to it), you can specify one or more Rules. Each Rule consists of an Event, an optional Condition, the Scope for which it applies, and one or more Actions to perform. An Event is a trigger point within a form, such as startup (WHEN-NEW-FORM-INSTANCE), or when focus moves to a new record (WHEN-NEW-RECORD-INSTANCE). There are standard events that almost every form sends, and certain forms send additional product-specific events.The Scope is evaluated based on the current runtime context to determine if a Rule should be processed or not. The Scope can be at the Site, Responsibility, User, or Industry level. Each Rule can have one or more Scopes associated with it.

The Condition is an optional SQL code fragment that is evaluated when the Event occurs; if it evaluates to TRUE then the Actions are processed.

Each Action consists of one of the following:

·   setting a Property, such as making a field Required or hiding a Tab page

·   executing a Builtin, such as GO_BLOCK, DO_KEY or FND_FUNCTION.EXECUTE

·   displaying a Message

·   enabling a Special menu entry

Once Rules are defined, when the target function is run then the Rules are automatically applied as events occur within that form. Although the Form Personalization feature is declarative, the intended audience is a person familiar with Oracle Forms including the PL/SQL programming language, and the Oracle Applications Development Guide. Additionally, any change made could interfere with the base code of a form (the code that Oracle ships), thus the Support statements discussed later in this chapter must be followed diligently.

Using the Personalization Form

To create personalizations for a particular function, first invoke that function from the Navigation menu. While in the form, choose Help->Diagnostics->Custom Code-> Personalize from the pulldown menu. This menu entry is secured by the FND_HIDE_DIAGNOSTICS (Hide Diagnostics menu entry) and DIAGNOSTICS (Utilities:Diagnostics) profiles, as are most other entries on the Diagnostics menu.

The Personalization form will open and automatically query existing Rules for that function. After making changes, Save them then close and re-run the function to have them take effect. You can also Validate or Apply certain changes immediately to test them without having to re-run the target form by pressing the ‘Validate’ or ‘Apply Now’ buttons.

 Why personalization?

Ø      Oracle Supports personalization unlike customization

Ø      Personalization are stored in tables rather than files

Ø      Will not have a bigger impact when you upgrade or apply patches to the environment

Ø      Can be moved easily through FNDLOAD from one instance to other

Ø      Can be restricted at site/responsibility/user level

Ø      Easy to disable/enable with click of a button.

Ø      Personalization will store who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don’t have that ability.

Ø      Can be applied to new responsibilities/users easily.

Ø      Can be restricted to function or form.

What can be done through personalization?

Ø      Zoom from one form to another

Ø      Pass data from one form to another through global variables

Ø      Change LOV values dynamically

Ø      Enable/Disable/Hide fields dynamically

Ø      Display user friendly messages when required

Ø      Launch URL directly from oracle form

Ø      Execute PL/SQL programs through FORM_DDL package

Ø      Call custom libraries dynamically

Personalization Tables:

FND_FORM_CUSTOM_RULES

FND_FORM_CUSTOM_ACTIONS

FND_FORM_CUSTOM_SCOPES

FND_FORM_CUSTOM_PARAMS

FND_FORM_CUSTOM_PROP_LIST

FND_FORM_CUSTOM_PROP_VALUES