Introduction
Oracle Applications Framework (OA
Framework) provides the capabilities to configure the look and feel of the
screens based on the business needs. To better understand these capabilities,
distinctions between personalization and extensibility need to be understood.
Personalization refers to the ability to declaratively tailor the following to
suit a business need or user preference:
·
Look
and feel of the user interface (UI)
·
Layout
of the UI
·
Visibility
of built-in content
Extensibility, on the other hand, refers to
the ability to extend the functionality of an application, beyond what can be
done through personalization, such as:
·
Adding
new content or business logic
·
Extending
or overriding existing business logic
This document explains the best practices
on the personalization used in a common implementation along with the effective
migration of the same to various other environments without redoing them
manually.
Personalization
Options
The following profiles need to be enabled
for a user to enable the personalization links.
·
FND:
Personalization Region Link Enabled
·
Personalize
Self-Service Defn
·
HR:
Enable User Personalization
All
the above profiles values should be set to ‘Yes’ for the user through which the
screens would be personalized.
Personalization
Levels
The following are the various levels at
which the personalization can be done
·
Site Level – This level is suitable if the screen
changes need to be reflected globally across business groups.
·
Location Level – This level is suitable if the screen
changes need to be reflected only for a single business group.
·
E.g.
If the self service module is rolled out for two countries GB and ES and if GB
calls department as ‘HR Organization’ and ES calls it as ‘Department’, then
this level has be used to change the prompt only for GB.
·
Organization Level – This level is suitable if the
screen changes need to be reflected only for a single operating unit.
·
Responsibility Level – This level is suitable if the
screen changes need to be reflected only for a specific responsibility
·
E.g.
If two responsibilities are created to display HR and iProc notifications
separately, then the filter needs to be set at responsibility level because the
underlying screens are common to both modules.
·
Function Level – This level is suitable if the screen
changes need to be reflected only for a specific function
E.g.
If two different screens are used to display two different Special Information
Types (SIT) details, two custom functions need to be created and personalized
to display different fields in different screens.
All
personalization made through the OA Personalization Framework are added on top
of the base product metadata at runtime. These personalizations never overwrite
the existing base product UI and are therefore preserved during upgrades and
patches and can also be translated.
Personalization
types
The
following are some of the common types of personalization that could be
accomplished using OA Framework.
§ Change the prompt
for a field or other text on a page
§ Hide or show a
field on a page
§ Make fields read
only
§ Reorder fields or
items on a page
§ Restrict data that
a user can access
§ Add new buttons,
links, text items, images, etc.
§ Restrict query
results in a table
§ Hide or Show
selected DFFs and KFFs
Migrating
Personalization
Once personalization is done in the
development environment they can be migrated to another instance without redoing
them. For each screen personalized, xml files are created with the
personalization information. These can be migrated using the following steps.
Export Personalization
All the
personalization needs to be exported from the development instance using the
following steps.
1.
Set
‘FND: Personalization Document Root Path’ to desired location in the
application server.
2.
Bounce
the Apache.
3.
Log
on to Functional Administrator à Home à Personalization
Tab à Import/Export à Personalization
Repository
4.
Date
filters and application filters could be used to narrow down the search.
5.
Select
the personalization that needs to be migrated. (Hint – Do not select the
complete list. Ensure that only the required personalization are exported to
avoid any wanted items going into the other instance)
6.
Click
Export to File System button
Establish Mapping
For the
responsibility level personalization, the export option creates the folder name
with the responsibility id in the source instance. This does not work in the
target instance with the same name because the target instance may have a
different responsibility id.
1.
Open
the folders under ‘/oracle/apps/per/customizations/responsibility/’
2.
Rename
the folders with the corresponding responsibility id from the target instance
3.
Repeat
this for all modules and screens
Import
Personalization
Import the
personalization in the target instance by doing the following steps.
1. Set ‘FND:
Personalization Document Root Path’ to desired location in the application
server.
2. Bounce the Apache.
3. Move the dump from
step 2 to this folder. Make sure all the folders are intact as they were from
source system.
4. Log on to
Functional Administrator à
Home à Personalization
Tab à Import/Export à Exported
Personalization
5. The folder
structure that is copied in step iii should appear
6. Select all or the
desired folders/files
7. Click Import form
File System.
