Professional Documents
Culture Documents
Form Building Documentation
Form Building Documentation
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
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.
2. Default a value
copy (TO_CHAR (n_person_id),'PERSON_BLOCK.PERSON_ID' );
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
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
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.
The developer will not check-in these changes to source control, until their
changes have succeeded UAT.
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.
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