Form Personalization in Oracle Applications


These days Form personalization is keyword and almost all developer and analyst working in oracle application must be aware and conversant with feature and how-to use this. I recommend to have good amount of practice on this. here i am presenting very brief overview and like to know if it useful need kind of tutorial kind of article. 

Form Personalization in Oracle Applications

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  

 

 Thanks – Shivmohan Purohit

Oracle Applications – development, customization, extension


Oracle Supported way to include business needs without creating real customization

When developing with the Oracle eBusiness Suite, there are situations where Developers can use “hooks” in standard Applications code to insert or redirect to custom code. Oracle Applications provide some helpful layers of abstraction to make life easier for customization. Where possible it is nice for this to be done using a supported method. If a true blue customization is required, then its best to try to preserve the existing code so that any future upgrades are more likely to break your custom code by reverting to standard code, plus if you use a “hook” to independent code it is easier to maintain and upgrade the custom code. I regularly use a “copy and modify” approach to Apps Development where I use hooks to call the new code.

Concurrent Program Executable. Where an concurrent program is automagically submitted from a form or another concurrent process, e.g. “Print Pack Slip” in Oracle Shipping actions, as long as parameter requirements are the same, then a quick an easy method to code your own report is: Create a new executable registered under your custom application, e.g. XMODS_WSHRDPAK, Query the called concurrent program and update the executable to your custom executable, e.g. Query WSHRDPAK and replace executable with XMODS_WSHRDPAK

Personalization – Forms and Framework (OAF) plus CUSTOM.pll. Forms PL/SQL Library. Personalization has provided functionality to cover alot of the customizations traditionally coded to CUSTOM.pll, but both Personalization and CUSTOM.pll provide a number of hooks into the front end logic.

Database Triggers. Triggers on tables used carefully can provide hooks where all other methods don’t dare to tread. Of course watch out for the exception and try to avoid putting triggers on fnd_concurrent_requests!

Menu. Provides a prominent method to call new Forms, while potentially hiding behind the same prompt, Reports, Discoverer Workbooks, external links/URLs, etc. Gives the ability to save in the “Favourites” list. If you need to customize a standard form, copy it and create a new menu entry where possible.

Unix Softlink. An alternative to the concurrent program executable hook. Backup an existing standard Oracle file. Remove the existing standard Oracle file. Replace with a softlink to a file under you custom application code “top” directory

Workflow. Workflow customizations are “allowed” and a method I use here is to take a standard function call in workflow, copy and modify the underlying package, then change the function call in workflow to the custom function. E.g. AP Remittance Advice workflow (APPEWF) has “Get Check Info” function calling AP_PAYMENT_EVENT_WF_PKG.get_check_info. Copy AP_PAYMENT_EVENT_WF_PKG to XMODS_AP_PAYMENT_EVENT_WF_PKG and change function in workflow function “Get Check Info”

Printer Driver. Whenever concurrent request file post processing is required, e.g. to FTP or email a file – printer drivers provide an excellent way to perform post processing. Create a new printer driver with the appropriate command. Remember to restart the concurrent manager to pickup updates to print drivers.

Business Events. Not a widely used mechanism, but provides supported hooks into key events such as Payment Confirmations (AP Payment event).

Thanks – Shivmohan Purohit