Sei sulla pagina 1di 11

Oracle forms personalization

In this article, I would like to explain different possibilities of Forms Personalizations. Surely before explaining what can be done, first we will touch base upon what exactly it is. Why was forms personalization introduced by Oracle in 11.5.10? 1. CUSTOM.pll is a programmatic methodology for extending Oracle Forms, even for trivial tasks. 2. Multiple developers working on same CUSTOM.pll could cause version related headaches Does Forms Personalization replace CUSTOM.pll? Not really, however it does provide an alternative to most common activities for which earlier one would use CUSTOM.pll Forms personalization is driven by the same set of events as that for CUSTOM.pll. Keep in mind that Oracle Forms Libraries first invoke the Forms Personalization, and then the CUSTOM.pll too for the same set of events. How do I enable Forms Personalizations? Enable the personalizations using the Help/Diagnostics menu.

What are the various components of Forms Personalizations?

Different components of Oracle Forms Personalizations are listed below. You begin with recognizing which Triggers/Events that you wish to trap and under what conditions. The condition can be entered using the syntax as defined in the picture below.

What does the Action Tab do? Here you will either change form property, or display messages or enable menu etc.

Can I modify SQL Query behind the LOV using Forms Personalizations? Of course you can. In the below example I am restricting the LOV to less than 3records by introducing where rownum <3 in record group query. Step 1. Create a new record group Step 2. Attach the newly created record group to existing LOV in EBS Form.

Can I call a PL/SQL Stored procedure passing it form field variables? Yes, using the syntax below. Note: You can also invoke FORMS_DDL built-in to perform DDL.

Can I call BuiltIn's? Indeed, as shown below, you can pick from all the form built-in's as below.

You can also call a form function and pass it parameters using Forms Personalizations

Processing can be aborted if validation were to fail

You can invoke equivalent to app_item_property.set_property. I am displaying the Required property below, however you can use this option for all supportable properties of app_item_property

You can initialize a global variable. Initialization code is executed if and only if the global variable does not already exist. Use global variables for passing variables back and forth between two forms. Please do not use Global Variables if your logic is restricted to a Single form itself.

You can assign values to form fields using global variable.

Using forms personalizations, you can set the Default where clause of the BLOCK too.

Note: Don't forget to reset this clause after your desired operation has been finished. This will facilitate the form to run in standalone mode too.

Ditto for Order by Clause on block.

For displaying messages, you can either enter a plain text, or your message can be displayed from the result of a SQL Statement.

Local variables can be defined and they will be active for throughout the session of the current form.

Use global variables if you wish to share the variable between multiple forms. Below, just for demo, I am setting the local variable to 0.

In the below picture, I am checking if local variable is 0 then display a message.

You can enable SPECIAL1-15 or MENU1-15, to create new menu entries under the Tool menu.

As seen below, the above two setups have instantiated the new Menu Items

SPECIAL16-30 will create entries under Reports menu SPECIAL31-45 will create entries under Actions menu You can capture the click on those newly created menu items by trapping event MENU1 or SPECIAL1 [or whatever you defined]

Anyway, lets have a look through some of the best practices for Forms Personalizations. Global Variable Names All the global variables defined must begin with XX. This will ensure there is no conflict with global variables that are defined by Oracles development team.

FNDLOAD You must always use FNDLOAD to transfer Forms Personalizations from one environment to another. However see below point too, which is very relevant to FNDLOAD

Decide a master environment Decide a master environment onto which all the forms personalization will be entered prior to scripting & patching those personalization using FNDLOAD. If "Functional Team" makes changes to TST Environment and then the "Development Team" makes changes to DEV Environment for the same form, then, changes done to TST Environment will be lost when FNDLOAD extract from DEV is uploaded onto TST. Usually developers make their personalization changes to DEV environment, Functional team makes their changes to TEST/UAT environments and Support team sometimes tends to make their FNDLOAD changes straight into production[ I mean without using FNDLOAD]. This is a bad practice. Do not make any Forms Personalization changes manually onto production. Decide an environment onto which developers, functional personnel & support staff will manually key in their personalization. Use this as a master environment to download the Forms Personalizations using FNDLOAD.

Tools Menu To create new Tool Menus, always use MENU1-MENU15, as Oracle guarantees never to use these during development. Same is not true for SPECIAL Menus, as Oracle development may release a patch utilising the same SPECIALx as you may have personalized. MENU1..15 is available starting from 11.5.10 CU2 onwards

Remember the sequence Keep in mind that Forms Personalization code fires prior to CUSTOM.pll code [in case you have the same form extended in both the places]. Use local variables when its usage is restricted to one single form If a variable scope is limited to single form which is being personalized, then do not unnecessarily create a GLOBAL Variable. Clear Global Variables once they have been used Use global variables when you wish to integrate two different screens using Forms Personalizations. In other words global variable act like a bridge between two forms [of course apart from parameters] Make sure you clear off the GLOBAL Variables after their usage is finished. This will ensure that screen works under normal scenarios too.

Before reporting a bug/SR in Forms via Metalink, reproduce the issue by disabling customizations The Forms Personalizations can be disabled by turning the custom code off. Before reporting any form related bug to Oracle, try reproducing the issue by turning Custom Code off

Identify the best possible triggers to use for personalizations See this link that explains how to recognise the best trigger to trap for forms personalization. Both forms personalization and CUSTOM.pll are fed the same set of triggers in Forms.

Potrebbero piacerti anche