Oralce-Form-Personalization-个性化.ppt

Agenda Securing Access The Architecture Debugging After Applying a Patch Using the Loader Interactions with the CUSTOM library Interactions with Folders Support Using the Form Personalization feature to alter Oracle code at runtime may bypass important validation logic and may jeopardize the integrity of your data. You should thoroughly test all changes you make in a Test instance before using it in a production environment. Setting both ‘Hide Diagnostics’ and ‘Utilities: Diagnostics’ to ‘No’ for all users is highly desireable. This way, if a clerk has an issue a DBA can stop by and immediately enable debugging features by supplying the Apps password. HOWEVER, you must log out after doing that otherwise the clerk will have access to those dangerous functions. Plus 2 sequences and lots of indexes of course. FND_INDUSTRIES is really for future use, though it is populated with 49 rows of seed data. 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. Copyright ? 2004, Oracle. All rights reserved. Form Personalization Administration After completing this module, you should be able to do the following: Secure access to Personalizations Understand the basic architecture Debug Personalizations, including Performance and multilingual issues Validate Personalizations after applying patches Use the Loader to move personalizations between instances Understand interactions with CUSTOM and Folders Know when to call Oracle Support Objectives Form Personalizations allows you to fundamentally alter the behavior of the product that Oracle ships, and access any and all data. Therefore, This feature should only be made available to trusted users. Avoid building Personalizations on a production system. Form Personalizations should first be entered and thoroughly QA’ed on a test system before they are loaded to a production system WARNING! Personalizations are created by invok