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 fields2. Changing the List of Values in a LOV field at runtime.3. Defaulting values4. Additional record level validations5. Navigation to other screens.6. Enabling Special Menu

Primarily there are two methods of extending Oracle Forms, and these are     CUSTOM.pll    FORMS PersonalizationsIn 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-DELETEPRE-UPDATE and POST-UPDATEPRE-INSERT and POST-INSERT

POST-FORMS-COMMITWHEN-CREATE-RECORDKEY-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 used1. Change the label of a fieldapp_item_property2.set_property ('BLOCK.FIELD', label,'New Label');

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

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

3. Alter the SQL for LOV QueryPROCEDURE 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 mandatoryapp_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 exampleFND_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 MenuPROCEDURE 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 functionfnd_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 conditionFor example to make 1st segment of a KFF display-only, we can useIF v_check_result='xyz' THENFND_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.pllAction Type in CUSTOM AllowedOpening SQL Cursors YesExecuting pl/sql stored procedures YesReferencing fields using bind notation like :block.field

No

Exception management Yes

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 table1. 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 below1. 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.pll3. Checks in XXPOXPOEPO.pll to Source Control4. Attaches XXPOXPOEPO.pll to CUSTOM.pll5. 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.pllWe 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.pldf60gen 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.plxf60gen module_type=LIBRARY module=CUSTOM userid=apps/apps