| Oracle® Fusion Applications Developer's Guide 11g Release 4 (11.1.4) Part Number E15524-09 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Developer's Guide 11g Release 4 (11.1.4) Part Number E15524-09 |
|
|
PDF · Mobi · ePub |
This chapter describes how to define a profile, which is a set of changeable options that affect the way your application looks and behaves. Profiles control how Oracle Fusion Applications operate for users by the values that are set. Profiles can be set at different levels depending on how the profiles are defined.
This chapter includes the following sections:
Profiles are permanent user preferences and system configuration options. They allow for the centralized management of configuration data but with sophisticated, customized user, security, and session-context access to the values. The Profile Service application programming interface (API) provides the access to profile values.
Hierarchies enable system administrators to group and set profiles according to their business needs. The hierarchy is fixed in the profile definition, you cannot just randomly mix and match the levels. For more information about profile levels, see Section 55.4, "Managing Profile Definitions."
Users may be able to set their own profile options, depending on settings in the profile definition. However, not all profiles are visible to end-users, and some profiles, while visible, may not be updated by end-users.
Categories can be used to group profiles based on their functional area. Administrators can categorize profiles and then easily search on profiles by category.
When to define a profile:
Evaluate if there is a genuine need for an option before creating a profile. Do not force the customer to make a decision about an issue that is of no concern to them.
Look for duplicate or similar profiles, even in other products, before creating a new one. For example, you do not need multiple profiles to choose a preferred currency.
Do not use profiles to cache temporary session attributes. Profiles are permanent user preferences and system configuration options.
Every Oracle application registers task flows with a product called Oracle Fusion Functional Setup Manager. Functional Setup Manager provides a single, unified user interface that allows customers and implementers to configure all Oracle applications by defining custom configuration templates or tasks based on their business needs.
The Functional Setup Manager user interface (UI) enables customers and implementers to select the business processes or products that they want to implement.
Function Security controls your privileges to a specific task flow, and users who do not have the required privilege cannot view the task flow. For more information about how to implement function security privileges and roles, see Chapter 50, "Implementing Function Security."
For more information about task flows, see theOracle Fusion Applications Common Implementation Guide.
Table 55-1 lists the task flows related to profiles and their parameters.
Table 55-1 Profiles Task Flows and Parameters
| Task Flow Name | Task Flow XML | Parameters Passed | Behavior | Comments |
|---|---|---|---|---|
|
Manage Administrator Profile Values |
/WEB-INF/oracle/apps/fnd/applcore/profiles/ui/flow/ManageAdminProfileValuesTF.xml#profileValues_task-flow-definition |
mode='search' [moduleType] [moduleKey] [categoryName] [categoryApplicationId] mode='edit' profileOptionName [pageTitle] |
Search and edit all profile values for a system administrator. To search all profiles, do not pass any parameters. To search all profiles in a module, pass moduleType/moduleKey To search all profiles in a category, pass categoryName/categoryApplicationId. moduleType/moduleKey and categoryName/categoryApplicationId are mutually exclusive and cannot be passed in together. |
Search and edit all profile values for a system administrator. To search all profiles, do not pass any parameters. To search all profiles in a module, pass moduleType/moduleKey To search all profiles in a category, pass categoryName/categoryApplicationId. moduleType/moduleKey and categoryName/categoryApplicationId are mutually exclusive and cannot be passed in together. |
|
Manage Profile Categories |
/WEB-INF/oracle/apps/fnd/applcore/profiles/ui/flow/ManageProfileCategoriesTF.xml#profileCategories_task-flow-definition |
mode='search' [moduleType] [moduleKey] mode='edit' name applicationId [pageTitle] |
Search and edit profile categories. To search all profile categories, do not pass any parameters. To search all profile categories in a module, pass in moduleType/moduleKey. To edit a specific profile category, pass in name/applicationId. |
Search and edit profile categories. To search all profile categories, do not pass any parameters. To search all profile categories in a module, pass in moduleType/moduleKey. To edit a specific profile category, pass in name/applicationId. |
|
Manage Profile Options |
/WEB-INF/oracle/apps/fnd/applcore/profiles/ui/flow/ManageProfilesTF.xml#profiles_task-flow-definition |
mode='search' [moduleType] [moduleKey] mode='edit' profileOptionName [pageTitle] |
Search and edit profile definitions. In 'search' mode: To search all profile options, do not pass any parameters. To search all profile options in a module, pass in moduleType/moduleKey. In 'edit' mode: To edit a specific profile option, pass in profileOptionName. If mode is not explicitly passed, the default is 'search'. |
Search and edit profile definitions. In 'search' mode: To search all profile options, do not pass any parameters. To search all profile options in a module, pass in moduleType/moduleKey. In 'edit' mode: To edit a specific profile option, pass in profileOptionName. If mode is not explicitly passed, the default is 'search'. |
You can set profile values using the Setup UI, and access them programmatically or by using expression language.
You can use the Profile Option Values page to view the profile values. The page is shown in Figure 55-1.
Notes:
Any change you make to a profile option has an immediate effect on the way your applications run for that session. And, when you log on again, changes you made to your User-level options in a previous session are still in force.
When a profile value is changed, the user setting the value will always see the update immediately. Other users may not see the changed value until logging out and back in.
To view or edit profile values:
Go to the Manage Profile Option Values page to search for the required profile option.
Enter your search criteria, then click Search.
Note:
You can also select Reset to clear your entries and start again, or Save to save the entries for a future search.
In the Search Results: Profile Options section, highlight the required profile option.
In the Profile Values section, add a new value or delete an existing one.
Create a new row for every value set for this profile for every level/level value pair. The Profile Value is the value that has been defined in the profile definition's SQL Validation.
The ProfileServiceAM API can be found in the following package:
oracle.apps.fnd.applcore.profiles.profileService.applicationModule
Before you can use this profile, you must add the Applications Core library to your Model project. For more information, see Section 3.3, "Adding the Applications Core Library to Your Data Model Project."
To access profile values programmatically:
Import the Profile class and call the Profile.get()method to get the values for the profile name provided.
For example:
import oracle.apps.fnd.applcore.Profile;
...
fndDiagnostics = Profile.get("AFLOG_ENABLED");
Accessing a profile value using expression language (EL) simply requires defining the oracle.apps.fnd.applcore.Profile managed bean with the name Profile in the adfc-config.xml file at requestScope. See Figure 55-2.
Once the bean is defined, you can refer to any profile value as:
# {Profile.values.PROFILE_OPTION_NAME}
You can update profile definitions using either Functional Setup, or a standalone "super-web" type UI Shell page that embeds calls to the task flow directly in the menu.
When defining profile definitions you also define profile levels, which are part of a hierarchy. When working with profile levels, carefully consider the levels you enable for your profiles. Only enable them at the levels that make sense. You do not want end-users changing settings for profiles that they do not understand. At this time, only the following hierarchy is available:
Site (lowest level)
Product
User (highest level)
As most profiles are user preferences and can potentially be set at these three levels, this is the default hierarchy. Profiles can be set at one or more levels.
Note:
A higher-level profile value overrides a lower-level value.
Table 55-2 describes how profile settings are used:
Table 55-2 Profile Settings
| Hierarchy | Level | Profile Setting |
|---|---|---|
|
1 (Lowest) |
Site |
All users at an installation site. |
|
2 |
Product |
This level is intended to be the product owning the current code module. The product level is only available if it has been set on the session. Typically this is in a servlet filter, but it may be in other places in other technologies. |
|
3 (Highest) |
User |
An individual user, identified by their UserID (UserGUID) for the current session. |
When a profile is set at more than one level, Site has the lowest priority, superseded by Product, with User having the highest priority. A value entered at the Site level may be overridden by values entered at any other level. A value entered at the User level has the highest priority and overrides values at any other level.
For example, assume the Printer profile is set only at the Site and Product levels. When a user logs on, the Printer profile assumes the value set at the Product level, since it is the highest -level setting for the profile.
Tips:
System administrators should set site-level profile values before specifying values at any other level.
The profile values specified at the site-level work as defaults until profile values are specified at the other levels. Profiles are enterprise-striped. In a multi-tenant environment, VPD policies restrict the profile values to only those defined in the relevant enterprise. As a result, in a multi-tenant environment, a site-level profile value behaves like an enterprise-level profile value.
You can use the Profile editor to update profile definitions. Figure 55-3 shows the Manage Profiles Options page.
To edit profile definitions:
Go to the Manage Profiles Options page to search for the profile that you want to update.
In the Search Results: Profile Options section, highlight a profile option and do any of the following:
Use the Actions or View options
Create a new profile option
Edit an existing profile option. The Edit window is shown in Figure 55-4.
Delete an existing profile option
Detach a profile option to open it in a new window
In the Search Results: Profile Option Levels section, do any of the following:
Use the Actions or View options
Create a new profile level
Enable or disable user access to this profile:
Enabled: Select this option to allow user access.
Updateable: Select this option to give the user update privileges. Leave unselected if you want the user to have read-only access. This option is disabled unless the Enabled option is selected.
Enabling the profile for end-user access allows the user to set their own values.
Note:
The Enabled and Updateable check boxes determine whether or not you can read or write (respectively) values at that level.
Delete an existing profile level
Note:
Deleting a Profile Option level (or never creating one) is effectively the same as disabling it.
Detach the profile levels child table to open it in a new window
When registering a new profile option for a profile definition, one of the key properties is the SQL validation property. If the values for a profile option are limited to a discrete list from which to choose, the SQL validation property must be set.
It must be a valid SQL statement that selects two columns.
The first column should be the display value that the administrator will see in the Manage Profile Option Values task flow. This column can be a translated value if appropriate for the particular profile option.
The second column should be the code or ID that the product business logic will understand how to process. For example:
SELECT MEANING, LOOKUP_CODE FROM FND_LOOKUPS WHERE LOOKUP_TYPE = 'YES_NO'
Grouping profiles into categories makes them easier to find because Category is the main driver when searching for profiles. Group profiles into categories that make sense, such as categories based on their functional areas. Categories can be used to search for related profiles in the Administration UIs and also for defining data security rules. You can use the Manage Profile Categories editor to add new categories or add profiles to an existing category.
The grouping is many to many, which means that profiles can be in more than one category and categories can have more than one profile. The basic guideline for grouping profiles is that profiles affecting the same feature, or profiles an Administrator would likely want to see at the same time, should all be in the same category. Oracle seeds a number categories out of the box; customers are free to create their own or edit those that are shipped.
Like profile definitions, you can manage profile categories using either Functional Setup, or a standalone "super-web" type UI Shell page that embeds calls to the task flow directly in the menu.
To manage profile categories:
Go to the Manage Profile Categories page and search for the required profile category, as shown in Figure 55-5.
In the Search Results: Profile Categories section, highlight the required profile category and do any of the following:
Use the Actions or View options
Create a new profile category
Edit an existing profile category. The Edit window is shown in Figure 55-6.
Delete an existing profile category
Detach a profile category to open it in a new window
In the Search Results: Profile Options section, do any of the following:
Use the Actions or View options
Create a new profile option
Delete an existing profile category
Detach a profile category to open it in a new window
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
