add

About Me

My photo
Oracle Apps - Techno Functional consultant

Monday, October 3

CUSTOM.pll versus Forms Personalization

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

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.
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.


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 Menu
b. Trap the Menu event

Disable a Menu entry when certain conditions are met

Yes

No
See 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

Yes
See Note-2

Show FND Messages with their tokens replaced

Yes

See Note-3


Note-1

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.

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

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

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.


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

Personalizations are stored in tables, separate from the forms they alter:

  • FND_FORM_CUSTOM_RULES

  • FND_FORM_CUSTOM_ACTIONS

  • FND_FORM_CUSTOM_SCOPES

  • FND_FORM_CUSTOM_PROP_LIST

  • FND_FORM_CUSTOM_PROP_VALUES

  • FND_FORM_CUSTOM_PARAMS

  • FND_INDUSTRIES


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

Question: 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.

No comments: