Working with CUSTOM.pll

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
  begin
       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'
         THEN
            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
  begin
       --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 .