- Best practice to customize the EBS forms -

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

  • Oracle Folders
  • Descriptive Flex Fields (DFF)
  • Forms Personalization
  • CUSTOM.pll changes
  • Invasive Customizations




Oracle Folders

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

  • Easy to make the changes
  • End Users themselves can do the necessary changes
  • EBS fully supported. So any patch/upgrades won’t affect the changes

Limitations:

  • Restricted for the changes related to UI
  • End users should be trained to do these changes

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.

Advantages are

  • It is easy for Implementation Team/Administrations
  • EBS fully supported. So any patch/upgrades won’t affect the changes

Limitations:

  • Restricted to the Attribute columns defined in the tables. Most of the tables will have 15 columns. If the requirement is to have more than the defined columns then this setup can not be used.
  • Supports only very limited additional validations

Forms Personalization

This configuration tools is available from 11.5.10. It can be installed in prior versions as well. It allows

  • To make declarative changes to a form
  • Changes get applied at runtime when the proper trigger event occurs.
  • Changes can get applied based on security like user, responsibility
  • Change object properties
  • Execute certain Forms built-ins
  • Display messages
  • Activate menu entries

Advantages

  • Can be used instead of CUSTOM pll changes
  • Configurations survive upgrades
  • User with minimum Oracle technology skills can do the changes

Limitations

  • Can only change what Forms allows at runtime
  • Can only respond to certain Trigger Events

CUSTOM.pll changes

Library available in $AU_TOP/resource is modified to provide customizations to Oracle Application forms using forms builder to modify package body.

  • Hide fields, tabs
  • Make fields required
  • Restrict update or insert
  • Change prompts, tab labels
  • Alter LOVs
  • Create zooms and tool bar menu selections
  • Validate and format
  • Almost anything that can do in PL/SQL

Advantages

  • Much better controlled and additional features than Forms Personalization
  • Changes survive upgrades

Limitations

  • Only the developers having good knowledge in Oracle Technologies can make the pll changes
  • Can only respond to certain Trigger Events
  • Very difficult to maintain, if the number of customizations are more. Because same CUSTOM pll will be modified for each and every form customization.

Invasive Customizations

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.

Conclusion

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.

1 comment:

Anonymous said...

What's up colleagues, good piece of writing and good urging commented here, I am actually enjoying by these.

my blog post rhinoplasty Top surgeon