Understanding form personalization architecture
Understanding form personalization architecture
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
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
- Sequences
- Trigger Events
- Conditions
- Context
- Action
- Property
- Message
Sequences
It manages both Rules and Actions that have in Sequence that must be enteredTECHICAL DETAILS Personalizations are stored in tables, separate from the forms they alter:Trigger Events 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:
- It is there in case you need things to be processed in a specific order
- The sequence does not have to be unique
Conditions 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. Context 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
- 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.
Actions Actions determine what personalization does.
- 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.
- FND_FORM_CUSTOM_RULES
- FND_FORM_CUSTOM_ACTIONS
- FND_FORM_CUSTOM_SCOPES
- FND_FORM_CUSTOM_PROP_LIST
- FND_FORM_CUSTOM_PROP_VALUES
- FND_FORM_CUSTOM_PARAMS
- 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