<-----Google Analytics Code Start----> <-----Google Analytics Code Close---->
Skip to content



Default screen resolution  Wide screen resolution  Increase font size  Decrease font size  Default font size  Skip to content Default color Pink color Green color Green color
This website has now moved to http://apps2fusion.com

CUSTOM.pll Best Practice | Print |  E-mail
Written by Anil Passi   
Sunday, 25 February 2007
Why is a best practice needed for CUSTOM.pll?
Lets say you have different environments in which different developers are working for a single instance Production System. Assuming they all want to work upon CUSTOM.pll in parallel. In order to manage such situation efficiently, you need to have some methodology/rules when working on CUSTOM.pll

First lets consider various options that we have on table
1. One developer works on CUSTOM.pll at a time, checks out from source control while working, so that no other developer can work upon it until 1st developers changes go to production.
Limitation:- You can impact timescales, as other project teams may require to modify CUSTOM.pll at the same time.

2. Let two developers work on CUSTOM.pll library and let their work independently go to Production.
Limitation:- This is a painful process, as it will hurt when non-tested code in CUSTOM.pll reaches production.
This can happen if first developer's changes to CUSTOM.pll FAIL UAT and second developers changes PASS the UAT. The second developer would have included the CUSTOM.pll changes made by first developer which is still undergoing testing. Second developer needs to includes 1st developers changes too into CUSTOM.pll, to factor for a situation whereby both developer's code were to succeed UAT.

3. Use CUSTOM.pll simply as a stub [Best Practice]. The actual event handling takes place in a separate set of libraries [pll] which are attached to CUSTOM.pll.
What does this mean?
To explain this, lets consider a situation as below

Lets assume two developers want to work on CUSTOM.pll simultaneously
-->First developer wants to work on form named POXPOEPO.fmb [via CUSTOM.pll]
          Lets say, to make a duplicate check for Supplier Name against an existing company record in TCA, and warn user.
-->Second developer wants to work on form named PERWSSPP.fmb [via CUSTOM.pll]
          Lets say, to make a duplicate check for Employee Name against an existing person record in TCA, and warn user.  

First developer will do the steps below
1. Create XXPOXPOEPO.pll [ if does not already exist]
Within this, add a procedure as below within package XXPOXPOEPO
  procedure check_warn_duplicate_supplier is
       NULL ;
  end check_warn_duplicate_supplier ;
2. Attaches APPCORE2.pll and FNDSQF.pll to XXPOXPOEPO.pll
3. Checks in XXPOXPOEPO.pll to Source Control
4. Attaches XXPOXPOEPO.pll to CUSTOM.pll
5. In CUSTOM.pll
         IF form_name = 'POXPOEPO' AND block_name = 'XXXWHATEVER'
            XXPOXPOEPO.check_warn_duplicate_supplier ;
         END IF;
6. Checks in CUSTOM.pll into source control.

Note:- Second developer will do exactly the same steps, but by using XXPERWSSPP.pll instead

Both the developers will have their skeleton code checked into source control, which does nothing at all [just NULL command].
Also, both the developers will have their respective XXFORMNAME.pll files checked into source control.

What happens next?
First developer will checkout his XXPOXPOEPO.pll and make changes for vendor name validation.
  procedure check_warn_duplicate_supplier is
       --pseudo code below
       if duplicate THEN
              fnd_message to warn to user
       end if;
  end check_warn_duplicate_supplier ;

The developer will not check-in these changes to source control, until their changes have succeeded UAT.

Second developer too, will make their changes to XXPERWSSPP.pll, without checking in XXPERWSSPP.pll into source control.

What we have done here is that, as soon as above steps are done, any other developer can start working on CUSTOM.pll.
Effectively this will allow multiple developers to work on CUSTOM.pll, with their changes being promoted to production independent of other developers changes to CUSTOM.pll. This becomes possible, because each developer will work on the respective XXFORMNAME.pll for their respective form.

Any new developer, say third developer, will pick up the CUSTOM.pll from source control, which will either call "NULL" procedures [no effect] or actual procedures, depending upon the progress of code of other developers.

After the successful UAT, a developer must check-in changes to their XXFORMNAME.pll into source control.

Are there any catches?
You need some procedures in the way code is released to production. Lets say 1st developers patch goes to production after 2nd developers patch? This can happen if 1st developers UAT happens after second developers UAT.
Well... This situation can be avoided, by releasing patches to production in one bundle, whilst maintaining the sequence of the patching.
If worst does happen, then you can re-apply "second developers" patch again to production...at least you do not have to tinker the source code directly within production.

You may ask, why don't we attach APPCORE.pll to XXFORMNAME.pll
We do this, to avoid recursion, as is discussed in link CUSTOM.pll commands.
Hence we attached APPRCORE2.pll instead, which happens to be a slightly cut-down version of APPCORE.pll .

Comments (7)add
written by Uma , March 31, 2007
Hi Anil, i want to use custom lookup values for my custom form LOv.using my custom form user can assign an Item-group(which is a LOV)to an Item.if i need to identify which item belongs to a particular item-group , then i guess we need to design the databse table to store custom lookup id as one of the column.(EG: Itemcode,Description,customLookupid)am i right? Thanks Uma
written by Anil Passi , March 31, 2007
Thats right Uma. You need to store the lookup_code in the table, whilst the screen will display value from meaning column

working with custom.pll
written by Sachin Salvi , November 15, 2007
Hi Anil,
I need the customise the PO base apps form. Based on the ship to and all item description flag i want to freeze the unit Price in the PO, the price will default from the item master.

presently i have done the changes in the form and entered the validation on on-click and post text trigger..

i want do this using custom.pll how can i go about it... pld let me know..

Custmization of CUSTOM.pll
written by Vinay , November 26, 2007
Can I add a button on CUSTOM.pll.
If yes what effect will happen?
If no why?

written by venki , February 20, 2008
hi anilpass
so first of all i am saying many special thanks to u for sharing knoweldge thru u r beatifull web site.so plz keep going on moving.
custom.pll attached to itself
written by Oramonc , February 22, 2008
Hi Anil,

What kinds of errors recursion can produce. We face the following scenario:

PL/SQL library
Attached library

Thanks for sharing.


Need to call a procedure before commit or closing the form
written by Ajay Singh , March 21, 2008
Hi Anil
Can u put your light on the process to be followed for FP or custom.pll to execute a procedure before clossing the form "(conditional proceure)...

thanx in advance
You must be logged in to a comment. Please register if you do not have an account yet.