Thursday, 25 August 2011

CUSTOM.pll versus Forms Personalization

It is indeed time to stop using CUSTOM.pll
If you are on 11.5.10, then it is important for development team to enforce the usage of Forms Personalization over CUSTOM.pll, where possible.

Most of the things that can be done using CUSTOM.pll can now be done via Forms Personalization.
However there are certain gaps for which we have no option but to rely on CUSTOM.pll

This article compares the two techniques i.e. CUSTOM.pll versus Forms Personalizations

Why should we prefer FP over CUSTOM.pll ?1.    CUSTOM.pll is a single file/entity, hence only one developer can make changes to CUSTOM.pll at any given point in time.
You may also read best practices in CUSTOM.pll at this link
2.    If for some reasons CUSTOM.pll causes issues in Production, you will have to re-release the code changes after another round of UAT.
Form Personalizations makes this much simpler by allowing you to disable specific personalizations.
3.    You do not need to resort to programming for trivial tasks like changing prompt, and more so for changing prompts in Muli-Lang environment

Lets do a quick comparison between Forms Personalization and CUSTOM.pll
Task/Business Requirement
Forms Personalization
Change LOV Query
a. Create a New Record Group
b. Attach new RG to LOV
Change field properties like Mandatory/Display etc
Zoom to another screen
a. Enable Menu
b. Trap the Menu event
Disable a Menu entry when certain conditions are met
See Note-1
Display messages, warnings, hints etc
Display message with Questions, and conditionally execute code based on users response to the question
Execute PL/SQL Stored procedures
Change Navigation and Navigational Properties
Change block properties like “Query Where Clause” etc
Change is applicable across multiple screens, like Changing window title for all screens within one Organization/Responsibility
See Note
Show FND Messages with their tokens replaced
See Note-3

Important: Oracle will keep on improving capabilities in Forms Personalizations.
Hence some of these limitations that we see now in Forms Personalization might disappear over a period of time.


Once a menu has been enabled using Forms Personalization, it then can not be conditionally disabled. However the proposed workaround over this issue is to display a message when MENU is clicked in the scenario’s it was meant to be disabled.

Lets say you want to change the window title for all the screens within a responsibility. In this case, in CUSTOM.pll you could do so by a pseudo code similar to below
    If fnd_global.responsibility like ‘XX%CASH%’ THEN
        Set window title ( ‘Note: All transactions are audited’);
    End if
As you can see, this can be achieved quite easily in CUSTOM.pll  and the changes will be visible across multiple screens in the context.
However, for Forms Personalization, you will have to go and personalize each and every screen for which you want this change to be effective.

The proposed workaround is to display the message that is returned as a result from SQL Statement.

Time for some Q&A

Question: Should we migrate code from CUSTOM.pll into Forms Personalization?
Not really, there is no value in doing so, given that CUSTOM.pll is still supported and will remain so within the realms of Apps Unlimited.

Where is the metadata for Forms Personalization stored?
These personalizations are stored in FND tables

What is called first? Forms Personalization or CUSTOM.pll
First your form personalization is called, and then CUSTOM.pll is called.

Is forms personalization called for additional set of triggers vis-à-vis CUSTOM.pll?
Not really, the same set of triggers are passed to both CUSTOM.pll and Forms Personalization. To understand the fundamentals, visit this link CUSTOM.pll concepts

1 comment:

  1. Nice article and explanation is good,Thank you for sharing your experience on oracle have clearly explained about the process thus it is very much interesting and i got more information from your blog.

    Oracle Fusion Cloud HCM Online Training