Most of us are confused to identify the right tool for data security and find difficult to distinguish OLS and VPD. Hope the following table will help to identify the right tool to enforce the data security.
Comparison between OLS and VPD
It is very common for any Oracle E-Business Suite (EBS) implementation to customize the existing standard forms. The customizations can be varying minimal to major invasive customizations. This document helps the developers/technical team to identify the relevant approach before start doing any customizations.
Following are the different methodologies can be used to change the form
Most of the standard forms are developed with Folders. If the requirements are UI related like changing the labels, show/hide columns, sorting the information can be easily done using Oracle Folders. Either administrator can do these changes and make it available to everyone or end users themselves can do the changes as per their individual usage.
Advantages of Folders
Descriptive Flex Fields (DFF)
If the requirement is to maintain the additional details then DFF can be enabled. This is one time setup, mostly done by the implementation team. Administrators can make the changes at any time, but not the end users.
This configuration tools is available from 11.5.10. It can be installed in prior versions as well. It allows
Library available in $AU_TOP/resource is modified to provide customizations to Oracle Application forms using forms builder to modify package body.
All of the above methodologies are EBS suggested methodologies to customize the standard forms. If the requirements are very complex and not able to achieve using any of the above approaches then the standard form needs to be modified. The changes done in the standard form is called invasive customization and not supported by Oracle. Also the changes won’t survive if any patches/upgrades applied and difficult to maintain.
Invasive Customizations can be avoided using different complex approaches. For example the requirement is having additional 20 columns in the standard form with complex validation logic. Since normally the standard table has only 15 attribute columns, this requirement can not be achieved using DFF. So, alternative approach could be modifying the standard form and tables. But this is invasive customization and not supported by Oracle EBS.
This invasive customization can be avoided by developing new form. Develop the new form and call the new form from the standard form either using forms personalization or CUSTOM pll change.
Some requirements can be achieved only by changing the standard form. In these cases take the copy of the standard form, rename it, do the necessary changes and register the form. Use the new form rather than standard form. Only the standard form will be affected, if any patches/upgrades applied. New copied form will work as existing.
The form can be customized in different ways. But it should be maintenance free and supported by Oracle. It is implementation team/developer responsibility to identify and use the right approach to make any standard forms.
If UI related changes then form can be customized using Oracle Folders. If that is not possible then it can be done using Forms Personalization or CUSTOM pll. Still the requirements are not meat then take the copy of the form and do the necessary changes.
If the requirements are to add additional columns then use DFFs. If there are not enough DFF attributes then create new form and execute it from the standard using SPECIAL menus or ZOOM.
If the requirements have very complex validation logics then try to achieve it using Forms Personalization or CUSTOM pll. If that is not possible then copy the form and do the changes in the copied form and register it. Use the copied new form rather than standard form.
For more details refer Oracle Applications Developer’s Guide and Oracle Applications User Interface Standards.