You are on page 1of 10

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-ITEMINSTANCE 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 EBest | 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 cutdown 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

You might also like