Using the Form Personalization you have option to alter Oracle code at runtime bypassing important validation logic.
Form Personalizations allows you to fundamentally alter the behavior of the seeded product forms that Oracle provides you to access data..
Form Personalizations looks very simple and easy things,but sometime this may jeopardize the integrity of your data. Therefore developer and solution provider context , you must have a clarity in architectural understanding.
Many People are bit confuse about the personalization, take a note ... "Personalizations are created Per Function , not per Form "
A function launches a form and passes specific parameters; the same form may be invoked by different functions and to a user could act completely differently.
UNDERSTANDING THE COMPONENTS
Lets take a EBS form , and try to understand various sub-section
What you can see in above form , a Typical Oracle apps form Personalization consist of four major things
- Trigger Events
these attributes also have link with personalization.
A Oracle Application Form is driven by form Function, therefore all subcomponent are tightly putin together.
It manages both Rules and Actions that have in Sequence that must be entered
- It is there in case you need things to be processed in a specific order
- The sequence does not have to be unique
If you aware with basic frame of Oracle EBS form(template.fmb) , then you must be aware with inbuilts triggers and there sequnce of firing, Some of the triggers can be best understood to handle the events. Here are the some of events:
- WHEN-NEW-FORM-INSTANCE: once, when the form starts up.
- WHEN-NEW-BLOCK-INSTANCE: each time the cursor moves to a new block.
- WHEN-NEW-RECORD-INSTANCE: each time the cursor moves to a new record.
- WHEN-NEW-ITEM-INSTANCE: each time the cursor moves to a new item.
- WHEN-VALIDATE-RECORD: each time the current record has any change that needed to be validated.
- SPECIAL1 through SPECIAL45: each time the user selects a menu entry from the Tools, Actions or Reports menu.
The Condition field lets you create an expression in SQL which evaluates the run time action. In case of TRUE at runtime, then the Actions are performed, where as in case of FALSE Actions are skipped. Each time condition is re-evaluated the rule is processed or not.
This handle controls of the personalization and it applies to either a)Level(Site, Responsibility, Industry, or User) or b)Value whiich is specific value when level is Responsibility, Industry, or User
- If you set the Rule has a context of ‘Site’, it will be applied for everyone
- If you set rule with a context of Responsibility that mena it does not ‘override’ Site
- If you set a rule with a context of User does not ‘override’ Site or Responsibility
- If 2 rules have the same Trigger Event, and Actions that change the same property, the rule with the higher sequence number will be performed last.
Actions determine what personalization does.
Personalizations are stored in tables, separate from the forms they alter:
AFTER APPLYING A PATCH
There is some confusion , with Form Personalizations and Patch in EBS.
A patch will not change any personalizations that you have created; however, they may no longer be valid. There might be couple of reason that may affect for non-avibality of Personalization in particular form , for example..
- Objects within a form may have been renamed or deleted
- Functionality at the various trigger points may be changed
- Property settings could interfere with your Rules
IF SOMETHING GOES WRING , WHAT CAN YOU DO?
You need to identify the forms affected by a patch , the first things you need to do is to run the personalization screen from any form and select Tools > Administration
This will identify all forms that have Personalizations and have just been patched.
Once you idetified ,run each function, possibly setting Custom Code to ‘Off’ if it fails to open
Then finally run the Personalization screen and select Tools > Validate All
This way you do able to resolve any pop-up issue beacuse of Patch.