CUSTOM.pll versus Forms Personalization | Print |  E-

mail

Written by Anil Passi   Tuesday, 23 October 2007It 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 CUSTOM.pll Forms Personalization

Change LOV Query Yes Yes

a. Create a New Record Group

b. Attach new RG to LOV

Change field properties like Mandatory/Display etc Yes Yes

Zoom to another screen Yes Yes

a. Enable Menub. Trap the Menu event

Disable a Menu entry when certain conditions are met Yes NoSee Note-1

Display messages, warnings, hints etc Yes Yes

Display message with Questions, and conditionally execute code based on users response to the question

Yes No

Execute PL/SQL Stored procedures Yes Yes

Change Navigation and Navigational Properties Yes Yes

Change block properties like “Query Where Clause” etc Yes Yes

Change is applicable across multiple screens, like Changing window title for all screens within one Organization/Responsibility

Yes YesSee Note-2

Show FND Messages with their tokens replaced Yes 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.

Note-1Once 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.

Note-2Lets 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.

Note-3The 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.pllFirst 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