This chapter covers the following topics:
OA Framework includes the OA Personalization Framework which allows you to personalize an Oracle E-Business Suite application page without modifying any underlying code. Personalizing the appearance of or the data displayed in an OA Framework-based page is easy and straightforward.
Important: To personalize your OA Framework-based applications,we recommend and support only the use of OA Personalization Framework.
Dynamically created pages without OA Extension metadata behind them are not personalizable with the OA Personalization Framework.
Caution: A page may contain logic that depends on the regions or items that you personalize. To avoid unintended consequences, you should always familiarize yourself with the page's logic and thoroughly test your personalization before deploying it to a production environment.
All personalizations you make through the OA Personalization Framework are added on top of the base product meta data at runtime. These personalizations never overwrite the existing base product UI and are therefore preserved during upgrades and patches, and can also be translated. This means you can create your personalizations on a test system first, extract your personalizations to a flat file , then load your finalized personalizations to your production system with little interruption.
With OA Personalization Framework, your personalizations are reflected immediately on the page.
To begin personalizing your pages and portlets, refer to the instructions in these chapters:
OA Personalization Framework supports end-users as well as localization and customization teams in their efforts to tailor OA Framework-based applications to different users. OA Personalization Framework accomplishes this by allowing you to make personalizations at distinct levels so that you may target those personalizations to specific audiences.
There are different personalization levels available from the system administrative standpoint: Function, Industry, Localization, Site, Organization, Responsibility, and Admin-Seeded User. When you make personalizations at any of these levels, the personalizations are available only to the audience defined by that level. Since personalizations should only be made at these levels by a system administrator, these are collectively referred to as administrative-level (or admin-level) personalizations. Admin-level personalizations can be performed on any component in a page, including shared (extended) regions. Except for the Admin-Seeded User level, you can only have one set of personalizations per region per admin-level.
User-level or portlet-level personalizations, on the other hand, can be made only to certain tables in query regions or portlets. User or portlet-level personalizations can be made directly by an end-user and are visible only to that end-user, hence they are collectively referred to as end user-level personalizations.
All personalization levels are described in the following sections.
A function in the Oracle E-Business Suite is a token that is registered under a unique name for the purpose of assigning it to, or excluding it from, a responsibility. The OA Personalization Framework leverages the same infrastructure to drive the Personalization context at a feature or flow level. You can create personalizations for a region at the Function level, such that the personalizations are visible only when you display the region while the specific function is in context. For example, suppose you have an updatable region and you want that region to be updatable when accessed from FunctionA in the menu, but to be read-only when accessed from FunctionB in the menu. To accomplish this, you create a Function level personalization that makes all the fields read-only for FunctionB.
You can have only one set of personalizations per region per function; however, you can have as many functions as personalizations are needed, provided that these functions can be brought into context at runtime, such as by linking them to menus or passing them as parameters on the URL.
With the Industry personalization level, the OA Personalization Framework provides a way to tailor an application's user interface to suit a particular industry segment.
The Industry level includes a predefined list of vertical market categories, such as Healthcare - Provider and Utilities - Electricity. For each category, you can personalize the application interface to incorporate a unique combination of industry-specific terminology. For example, where one type of business might use the term "business unit," another might use the term "store," and another might use "location" or "franchise."
Suppose you need to distribute your applications to a particular locale of users, where certain fields or buttons are hidden and labels need to be changed to accommodate that locale. You can do that by creating Localization level personalizations in the relevant regions before delivering your applications. All end-users for the specific locale will see the applied localization personalizations. For example, Oracle's localization teams would make country-specific localization-level personalizations in HR applications before delivering the applications to customers in a given country.
A site refers to an installation of Oracle Framework-based applications. Personalizations that you make at the site level affect all users of the current installation. For example, as a system administrator, you might want to make a site level personalization where you change the table column labels to match your corporate standards.
An Org is an Organization or a business unit. Depending on the context, an Org can be a plant, a warehouse, a department, a division within a company or even a complete company. Personalizations that you make at the Org level affect all users of that Org. For example, you might make a personalization at the Org level to hide certain fields because they are not pertinent to the context of a particular Org.
A responsibility represents a specific level of authority within an application. Each responsibility lets you access specific functions or a set of product pages, menus, reports and data to fulfill your role in an application. When you make personalizations at the responsibility level, the changes are effective only for the users of a given responsibility. For example, you can personalize the Open Requisitions Line page for the "Office Supplies Purchasing Manager" responsibility to display only open requisition lines from a particular supplier.
As an administrator you may want to create some personalizations that are available to all your users and allow your users to choose whether they want to use those personalizations. You can accomplish this by creating an "admin-seeded user-level" personalization, also known as an "admin-seeded" end user view. For example, you can create two personalized views of the Oracle Workflow Worklist. One view shows open workflow notifications and the other view shows FYI notifications. Each user can have access to both of these views.
You can only create "admin-seeded user-level" personalizations on tables (including hierarchy tables) in a Query region. You can also secure "admin-seeded user-level" to a specific function so that is is published only to a specific group of users. These personalizations then get seeded into the appropriate users' Personal Table Views page, so that individual users can choose which views to display. You can have more than one "admin-seeded user-level" personalization per region.
Note: Although both "admin-seeded user-level" personalizations and site-level personalizations are propagated to all users, the two personalization levels are different. An "admin-seeded user-level" personalization is saved as a personalized view that a user can choose to display from the Personal Table Views page, whereas a site-level personalization is a change that is made across the entire site that all users see automatically.
Both Oracle-internal developers and customers are able to create seeded user-level customizations. To distinguish between seeded user-level personalizations that are shipped by Oracle and those that are defined by administrators at a customer site, the two types of personalizations are referred to as "Oracle-seeded user-level" personalizations (seeded by Oracle) and "admin-seeded user-level" personalizations (seeded by administrators at the customer site), respectively.
Note: An "Oracle-seeded user-level" personalization cannot be updated or deleted at the customer site; however, an administrator at a customer site who creates an "admin-seeded user-level" personalization can edit or delete that personalization.
Note: You can mark a seeded user-level personalization as a default view. End-user personalized views take highest precedence, followed by "admin-seeded user-level" personalizations, then "Oracle-seeded user-level" personalizations.
Oracle Portal provides users with corporate and customized personal home pages accessible via web browsers. These home pages may contain corporate announcements, stock tickers, news headlines, and links to other web-based services. Oracle Portal may also connect to partner applications that share their user authorization and session management models with Oracle Portal. Oracle E-Business Suite is a partner application to Oracle Portal. Oracle Portal users can add links to their home pages to access Oracle E-Business Suite modules, and can display Oracle E-Business Suite information, such as Oracle Workflow notifications, directly on their home pages. These links are called portlets. You can personalize these portlets just as you can personalize the tables of a query region in an application. Any personalizations you make at the portlet level affect only the portlet used to display the region. You can have only one set of personalizations per region per portlet.
As an end-user, you can personalize certain tables in query regions and the personalizations would affect no one else. For example you can personalize the Requisitions History page to display only requisitions prepared by you. Each user can save multiple sets of personalizations per page region. A saved set of personalizations is also known as a personalized "view" and can be selected and applied from the "View Personalizations" list.
The personalizations you make at the various levels are cumulative. Personalizations at the higher levels typically apply to broadly defined user populations, and those at lower levels apply to more narrowly defined groups. Personalizations made at lower levels are applied after those made at higher levels. The personalization levels are ordered as follows, from highest to lowest:
Function (highest)
Industry
Localization
Site
Organization
Responsibility
Seeded-User
Portlet (lowest)
User (lowest)
For example, the personalizations made at the Portlet and User levels always overlay personalizations made at the Organization level.
Note: Personalizations made at the Portlet and User levels are mutually exclusive.
For Oracle-internal developers, Function is the highest level at which you can personalize, followed by Industry, Localization, Site, and so on.
The granular nature of each personalization is maintained throughout the layering of personalizations for the different levels. For example, suppose you make a set of Site level personalizations to a region by changing the label of four fields from a, b, c and d to w, x, y, and z. Now suppose you want to make additional changes to that same region, where those changes are available only for users of Org 2. The Organization-level change for Org 2 that you make includes hiding the second and third fields and changing the label of the last field to zz. A user of Org 2 would see, as a result of the cumulative personalizations, a region with two fields labeled w and zz.
Personalizations made at an Admin level can only be modified, viewed, or deleted by an administrator at that respective level. Similarly, a personalized view made at the Portlet or User level can only be modified, viewed, or deleted from the portlet where the view was created or by the user who created the view.
At the User level, a particular region of an HTML page may have one or more sets of personalizations associated with it. Each set of personalizations is referred to as a personalized view of the region. You can identify a personalized view by assigning a view name to it. OA Personalization Framework also identifies each personalized view by assigning a unique ID to it.
Since you may define more than one personalized view at the User level, OA Personalization Framework lets you mark a specific view as the default view to apply to the region when you run the application.
Note: In the case of seeded personalized views, OA Personalization Framework applies a precedence rule to determine the default, if multiple defaults are defined (for example, if defaults exist at the User level, "Admin-seeded user level" and "Oracle-seeded user level"). The User-level default overrides any default set at any level. If no user-level view is marked as a default, then the "admin-seeded" default view takes precedence. Similary, if no user-level or "admin-seeded user-level" views are marked as defaults, the "Oracle-seeded" view becomes the default.
In the case where personalizations are made on a region that extends another region, at the User, "Admin-seeded user" or "Oracle-seeded user" levels, the default is resolved horizontally across the layers of the region. All of the default User views take precedence, followed by the default admin-seeded views, then the default Oracle-seeded views.
Example
Suppose you have region A, which extends region B, which in turn extends region C, and the following views have been created and marked as "Default":
| Region | Views Defined |
|---|---|
| A (extends B) | A.UserView - default A.Admin-seededUserView - default A.Oracle-seededUserView - default |
| B (extends C) | B.UserView - default B.Admin-seededUserView - default B.Oracle-seededUserView - default |
| C | C.UserView - default C.Admin-seededUserView - default C.Oracle-seededUserView - default |
The final default view is resolved based on the following order of precedence:
A.UserView >
B.UserView >
C.UserView >
A.Admin-seededUserView >
B.Admin-seededUserView >
C.Admin-seededUserView >
A.Oracle-seededUserView >
B.Oracle-seededUserView >
C.Oracle-seededUserView
The personalizations that you make to a region do not cause any performance degradation in your application. Admin-level personalizations for a region are statically cached on the JVM (Java Virtual Machine) and user-level personalizations are cached on the session.
The following system profile options affect the behavior of the OA Personalization Framework.
Disable Self-service Personal (FND_DISABLE_OA_CUSTOMIZATIONS)
This is a system profile option specifically created for use by Oracle Support. You can set this profile option to Yes at the site or application level. If this system profile option is set to Yes, any personalizations you make, regardless of the level at which you make the personalizations, will not be applied. Only the original base definition of each OA Framework-based application page is ever displayed. Use this profile option to help Oracle support staff determine whether a problem arises from applied personalizations or from the base application. The default is No.
FND: Personalization Region Link Enabled (FND_PERSONALIZATION_REGION_LINK_ENABLED)
When you set this profile option to Yes, Personalize Region links appear above each region in a page. Each link takes the user first to the Choose Personalization Context page, then to the Page Hierarchy Personalization page with focus on the region from which you selected the Personalize Region link. The default is null (not set).
Note: Note that enabling the Personalize Region links allows administrators to also personalize regions that are dynamically added to the page from custom code in the controller.
Personalize Self-service Defn (FND_CUSTOM_OA_DEFINTION)
You should set this profile option to Yes at the user level for an administrator. If you set this profile option to Yes, then when you log on as the Administrator, a global Personalize Page button appears on each OA Framework-based application page. When you select the global Personalize Page button on any page, the personalization user interface prompts you for the scope and administrative level at which you wish to create your personalizations before displaying the OA Personalization Framework UI. The default is No.
Xliff Export Root Path (FND_XLIFF_EXPORT_ROOT_PATH)
Use this profile option to specify the root path for extracting translated personalizations. The Xliff Export root path is used to generate the full path where the Xliff files are exported when administrators extract their translated personalizations from the Extract Translation Files page in OA Personalization Framework. The default is null (no root path is set).
Xliff Import Root Path (FND_XLIFF_IMPORT_ROOT_PATH)
Use this profile option to set the root path for uploading translated personalizations. The Xliff Import root path is used to derive the full path from where the Xliff files are uploaded when administrators use the Upload Translations page in OA Personalization Framework to upload translated personalizations. The default is null (no root path is set).