Limitations of Forms Personalization (文档 ID 420518.1)

Posted 2020-06-28 ORACLE EBS

In this Document

Purpose

Scope

Details

Diagnostics & Utilities Community:

References

---

APPLIES TO:

Oracle Application Object Library - Version 11.5.10.0 to 12.1.3 [Release 11.5 to 12.1]
Information in this document applies to any platform.
Checked for relevance on 28JUL2014

PURPOSE

With the Oracle E-Business Suite release 11.5.10, the Oracle has introduced a mechanism which revolutionizes the way the forms can be customized to fulfill the customer needs. For many years, Oracle Applications has provided a custom library using which the look and behavior of the standard forms can be altered, but the custom library modifications require extensive work on SQL and PL/SQL. In the release 11.5.10, Oracle has provided a simple and easy feature to implement the customer specific requirements without modifying the underlying forms code or CUSTOM library. Although CUSTOM library still can be used for forms customization to implement the complex business logic, the personalization feature provided in the latest release is easy, faster and requires minimum development effort.

SCOPE

Oracle Applications release 11.5.10 has provided a user interface "Personalization form" which will be used to define the personalization rules. These personalization rules establish the custom actions to be performed by the forms during runtime. The actions may include changing prompts, showing custom messages or prevent the user from doing the transactions etc. This feature also provides a well-built controlling mechanism which restricts the execution of the personalization rules at different levels (Industry, site responsibility and user). The personalization does not violate the support from Oracle and these rules also conceded with the future upgrades without any additional effort.

DETAILS

This feature has several significant limitations due to the architecture of Oracle Forms and/or the e-Business Suite. 

[1] User can only change what Oracle Forms allows at runtime. For example, the following cannot be changed:

• User cannot create new items
• User cannot move items between canvases
• User cannot display an item, which is not on a canvas (thus, individual flexfield segments cannot be displayed)
• User cannot set certain properties such as the Data type of an Item.
• User cannot change frames, graphics, or boilerplate
• User cannot hide the item that currently has focus

[2] Form Personalization can only respond to events that are centrally processed and dispatched by APPCORE. These are limited to:

• WHEN-NEW-FORM-INSTANCE, WHEN-NEW-BLOCK-INSTANCE, WHENNEW-RECORD-INSTANCE, WHEN-NEW-ITEM-INSTANCE. These events occur as the user moves focus within the form.
• WHEN-VALIDATE-RECORD (in many but not all forms). This event occurs whenever changes have been made to the current record in the current block.
• SPECIAL1 through SPECIAL45. These occur when the user selects entries from the Tools, Reports and Actions drop down menus.
• Product-specific events. These are typically documented in implementation manuals, such as ‘Configuring, Reporting and System Administration in Oracle HRMS‘.
• Form Personalization can only respond to events that are centrally processed and dispatched by APPCORE. These are limited to:

WHENNEW-RECORD-INSTANCE
should read
WHEN-NEW-RECORD-INSTANCE

[3] User can see only the events that are being passed by enabling the ‘Show Events‘ option in the Custom Code menu. 

[4] Certain personalization must be performed at specific events:

• To specify the Initial Value of an Item, user must perform that action in the WHEN-NEW-RECORD-INSTANCE event of the block that contains the item.
• Special menu entries can only be created at form start up (WHEN-NEW-FORM INSTANCE)

[5] Both the Personalization form and the runtime-processing engine will report errors for these cases and skip processing of them. 

[6] Certain objects may not be available to user to change, or cannot be validated:

• If a Tab within a form has no items directly rendered on it, that Tab will not appear in the list of objects that user can modify. In some cases, making that Tab the active tab before invoking the Personalization feature may cause it to be detected.
• The object types GLOBAL and PARAMETER cannot be detected, thus these fields have no LOVs to restrict their input. Use the ‘Validate‘ or ‘Apply Now‘ buttons to determine if the values users have entered actually exist. Note that GLOBAL variables are dynamically created, so whether they exist or not can be a matter of timing.

[7] Most significantly, this may interfere with, or be overridden by, base product code; any change user make might interfere with the normal operation of the form. This can manifest itself in several ways, such as:

• User may make a personalization but it does not take effect, because there is code in the form that overrides it. In some cases user may be able to perform user personalization by moving the Trigger Event to a ‘lower‘ level, such as block or item-level.
• User personalization may simply produce the wrong result, because user change interacted with the base code in unexpected and untested ways. At best this error will occur immediately upon the personalization being applied; at worst it could affect some later processing which does not appear to be directly related to the object or event.
• In extreme cases, user changes may prevent the form from running at all, making it difficult to open the Personalization screen to remove the offending personalization unless user turn off Custom Code. Because of this, it is critical that any change be thoroughly tested in a Test environment. See the ‘Troubleshooting, Support, and Upgrade considerations‘ section later in this chapter for more information.

[9] Use of the Apply Now button does not always work if dependent on the results of another action. 

[10] Forms Personalization is not possible for any flexfield structure or segments.

This is a limitation of Forms Personalization on Flexfield. Logged an Enhancement Request Bug 5506506 - "PERSONALIZE FLEXFIELDS BY USING FORMS PERSONALIZATION" but was rejected the enhancement request as this is not feasible. A Flexfield is a single field in a Form but then when you click into it and it opens up the flexfields window, the multiple fields you see is actually a user exit with multi segment values, not form fields. No Form Personalization events are passed to flexfield windows (user exits). No Form Personalization events are passed to segments inside the flexfield window (user exit).

However, you can do a little more on Flexfields using some custom code and Forms Personalization like?

1. Make a Flexfield Segment as read only.
2. Populate a Flexfield Segment with some pre-defined value dynamically at run time business logic.
3. Can restrict users from entry in a particular segment of a Flexfield.

[11] The argument (sql) length for creating a record group must be within 2000 Characters.  A viable workaround is to create a view that contains the required SQL then use that view as the data source for the SQL creating the record group.

[12] Populating LOV dynamically from a Record Group must be against the WHEN-NEW-ITEM-INSTANCE of that LOV item. 

[13] The use of the action RAISE FORM_TRIGGER_FAILURE may not work properly in some triggers. 

[14] Use of Builtin Action "Raise Form_Trigger_Failure" and pressing the button "Apply Now" will show the message "One or more required fields are missing values". 

[15] It is not possible to use server-side functions that have OUT parameters as the condition to execute the actions. 

[16] Expected user is an Admin/Developer

• Knowledge of Oracle Developer is extremely desirable
• Knowledge of PL/SQL, Coding Standards and/or APIs required in some cases.

[17] Normal rules for customizations apply

• Extensive testing in a Test environment is required.
• A patch does not touch user code, but user still must re-test after applying a patch.