Written by Anil Passi  

CUSTOM.pll is used to add extensions to Oracle's form Functionality. Some of

the common scenario where CUSTOM.pll can be used are:-
1. Enabling/Disabling the fields
2. Changing the List of Values in a LOV field at runtime.
3. Defaulting values
4. Additional record level validations
5. Navigation to other screens.
6. Enabling Special Menu

Primarily there are two methods of extending Oracle Forms, and these are
    CUSTOM.pll
    FORMS Personalizations
In this article we will cover the basics of using CUSTOM.pll for extending Oracle
Forms

How and why does CUSTOM.pll work?

Every form in Oracle Apps is created using something called as TEMPLATE.fmb.
But some of the modules like HRMS have their own HR Specific
Templates[HRTEMPLT.fmb]. These template files have form level triggers that
make call to CUSTOM.pll. The triggers that can be trapped using CUSTOM.pll in
HRMS screen can be different than those which can be trapped for other
modules.

Commonly used events that are trapped using CUSTOM.pll are:-

   ZOOM
   WHEN-NEW-FORM-INSTANCE
   WHEN-NEW-BLOCK-INSTANCE
   WHEN-NEW-RECORD-INSTANCE
   WHEN-NEW-ITEM-INSTANCE
   WHEN-VALIDATE-RECORD

However, for example in HRMS, you can also write code in CUSTOM.pll to trap
below listed events :-
PRE-DELETE and POST-DELETE
PRE-UPDATE and POST-UPDATE
PRE-INSERT and POST-INSERT
POST-FORMS-COMMIT
WHEN-CREATE-RECORD
KEY-DELREC

How to identify which trigger is most suitable for writing your business logic?
You can either open the FMB itself, and see the triggers which are calling
CUSTOM.pll.
However, there is a easier way to work out the most suitable triggers. You can
navigate to Help/Diagnostics/Custom Code/Show Custom Events
Once that radio button has been set, you will see the list of Events Displayed on
the screen.

In some cases, the desired WHEN-NEW-BLOCK-INSTANCE or  WHEN-NEW-ITEM-

INSTANCE are not being fired. What can I do?
It should always be possible to trap these events in CUSTOM.pll . But in some
cases, the form  might have these triggers at block/field level, with the trigger
property being OVERRIDE. Due to this, the corresponding form level triggers[ to
invoke CUSTOM.pll] do not fire. In this case you must  raise a bug with Oracle
on Metalink.

Structure code code in CUSTOM.pll

      IF event_name = 'WHEN-NEW-FORM-INSTANCE'
      THEN
         IF form_name = 'ARXTWMAI' AND block_name = 'INVOICE_HEADER'
         THEN
            xx_arxtwmai.default_customer;
         ELSIF form_name = 'ARXTWMAI' AND block_name = 'INVOICE_HEADER'
         THEN
                .....
         END IF;
       ELSIF event_name = 'WHEN-NEW-BLOCK-INSTANCE'
      THEN
                .....
      END IF ;

Lets take some scenario's where CUSTOM.pll can be used

1. Change the label of a field
app_item_property2.set_property ('BLOCK.FIELD', label,'New Label');

app_item_property2.set_property ('BLOCK.FIELD', label,’User Password');

2. Default a value
copy (TO_CHAR (n_person_id),'PERSON_BLOCK.PERSON_ID' );

3. Alter the SQL for LOV Query

PROCEDURE filter_customers_in_lov IS
  v_customer_group_id recordgroup;
  n_temp_id           NUMBER;
  v_customer_lov      lov;
BEGIN
  v_customer_group_id := create_group_from_query('XX_CUSTOMER_GROUP'
                                   ,'select ... from hz_cust_accounts where ..your custom
criteria here..');
  n_temp_id           := populate_group(v_customer_group_id);
  v_customer_lov    := find_lov('EXISTING_LOV_NAME_HERE');
  IF get_lov_property(v_customer_lov,group_name) =
'EXISTING_GROUP_NAME_HERE'
  THEN
         set_lov_property(v_customer_lov,group_name,'XX_CUSTOMER_GROUP');
  END IF;
END filter_customers_in_lov;

4. Make a field mandatory

app_item_property2.set_property ('XXBLOCK_NAME.XXFIELD_NAME', required,
property_true);
Similarly you can enable or disable the fields too.

5. You can display messages, for example

FND_MESSAGE.CLEAR;
fnd_message.set_name('APPL_SHORT_NAME_HERE', 'MSG_NAME_HERE'); or
fnd_message.set_string('message text');
fnd_message.warn or fnd_message.error or fnd_message.

6. Enable or Disable Special Menu

PROCEDURE manage_special_menu IS
  mi_id menuitem;
BEGIN
  mi_id := find_menu_item('SPECIAL.SPECIAL15');
  IF name_in('system.cursor_block') = 'INVOICE_HEADER' THEN
    app_special2.instantiate('SPECIAL15', 'Print Invoice');
    set_menu_item_property(mi_id, displayed, property_true);
    set_menu_item_property(mi_id, enabled, property_true);
  ELSE
    set_menu_item_property(mi_id, displayed, property_false);
  END IF;
END manage_special_menu;

7. Handle the click on Special Menu

  IF event_name = 'SPECIAL15' THEN
    IF form_name = 'INVOICE_FORM' THEN
      xx_invoice_form.process_printing;
    END IF;
    IF form_name = 'SUPPLIER_FORM' THEN
      xx_supplier_form.email_supplier;
    END IF;
  END IF;

8. Ask user a question, and take appropriate action

  v_token_value      VARCHAR2(1000);
  n_button_selection INTEGER;
BEGIN
  fnd_message.set_name('APPL', 'MESSAGE');
  fnd_message.set_token('XXTOKEN1', v_token_value);
  n_button_selection := fnd_message.question('Email Invoice', 'Fax Invoice', '', 1,
2, 'question');
  IF n_button_selection = 1 THEN
    xx_call_invoice_print;
  ELSE
    xx_fax_invoice;
  END IF;

9. Call Another form function

fnd_function.EXECUTE(
   function_name => 'XX_FORM_FUNCTION_NAME_HERE'
  ,open_flag        => 'Y'
  ,session_flag     => 'SESSION'
  ,other_params   => 'P_INVOICE_ID = "' || n_invoice_header_id || '"'
  ,activate_flag    => 'Y');

10. Make some segments of a KeyFlexfield Display-Only depending upon some

condition
For example to make 1st segment of a KFF display-only, we can use
IF v_check_result='xyz' THEN
FND_KEY_FLEX.UPDATE_DEFINITION(
     BLOCK => 'BLOCKNAMEHERE'
    ,FIELD => 'FLEXFIELDNAME'
   ,ENABLED => 'Y'
   ,DISPLAYABLE => 1);
END IF ;

As you may have gathered by now, almost any form related task can be done
using CUSTOM.pll
Action Type in CUSTOM Allowed
Opening SQL Cursors Yes
Executing pl/sql stored procedures Yes
Referencing fields using bind notation No
like :block.field
Exception management Yes
CUSTOM.pll
 E-
Best | Print |
mail
Practice

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

Please find some commands for CUSTOM.pll

To convert from CUSTOM.pll to CUSTOM.pld

f60gen module_type=LIBRARY module=CUSTOM script=YES userid=apps/apps

To convert back from CUSTOM.pld to CUSTOM.pll ( after having edited the text
pld file )
f60gen module_type=LIBRARY module=CUSTOM parse=YES userid=apps/apps

To convert from CUSTOM.pll to CUSTOM.plx

f60gen module_type=LIBRARY module=CUSTOM userid=apps/apps