Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
87 views24 pages

Scribd Upload A Document Search Documents Explore Sign Up Log in

Using The Personalization form to create personalizations for a particular function, first invoke that function from the Navigation menu. Each Rule consists of the following fields: Seq: The sequence in which rules will be processed. Trigger Object: Depending on the trigger Event, this field may be Disabled, or Enabled and Required.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
87 views24 pages

Scribd Upload A Document Search Documents Explore Sign Up Log in

Using The Personalization form to create personalizations for a particular function, first invoke that function from the Navigation menu. Each Rule consists of the following fields: Seq: The sequence in which rules will be processed. Trigger Object: Depending on the trigger Event, this field may be Disabled, or Enabled and Required.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 24

Scribd Upload a Document Search Documents Explore

Sign Up | Log In

/ 18 Download this Document for Free

familiar with Oracle Forms including the PL/SQL programming language, and the Oracle Applications Development Guide. Additionally, any change made could interfere with the base code of a form (the code that Oracle ships), thus the Support statements discussed later in this chapter must be followed diligently.
Using the Personalization Form

To create personalizations for a particular function, first invoke that function from the Navigation menu. While in the form, choose Help->Diagnostics->Custom Code-> Personalize from the pulldown menu. This menu entry is secured by the FND_HIDE_DIAGNOSTICS (Hide Diagnostics

menu entry) and DIAGNOSTICS (Utilities:Diagnostics) profiles, as are most other entries on the Diagnostics menu. The Personalization form will open and automatically query existing Rules for that function. After making changes, Save them then close and re-run the function to have them take effect. You can also Validate or Apply certain changes immediately to test them without having to re-run the target form by pressing the Validate or Apply Now buttons.
Figure 1: The Personalization screen, when opened from the Users form (Function Name FND_FNDSCAUS)

Each Rule consists of the following fields: Seq: The sequence in which rules will be processed. This is a value between 1 and 100, with 1 being processed first. The sequence of rules does not have to be unique. Note that there is an interaction with the Trigger Event field, described below. Description: Use this field to document the personalization you are making. Enabled: Uncheck this checkbox to temporarily disable processing of a Rule. The following fields appear on the Condition tab:

Trigger Event: Select the event at which you want the Rule to be processed. You can pick from

the list of standard events, or type in a specific event unique to the form. Note that this field is a Combobox, which is a hybrid of a Poplist and Text Item. Rules are processed first by matching the Event, then by their Sequence number.
Trigger Object: Depending on the Trigger Event, this field may be Disabled, or Enabled and

Required in which case it will validate against a List of Values. For example, if Trigger Event WHEN-NEW-ITEMINSTANCE is selected, then you must enter a specificblock.field for that trigger to be processed.
Condition: This is an optional SQL code fragment that is evaluated when the Event occurs; if it

evaluates to TRUE then the Actions are processed. The condition can contain any of the following:

SQL functions and operators, such as AND, OR, TO_CHAR, DECODE, and NVL References to bind variables (:block.field), including :system, :global and :parameter values. Use Calls to server-side functions that do not have OUT parameters

the 'Add Item...' button to assist with item names.

The entire fragment must be syntactically correct, and can be tested with the 'Validate' button, which will evaluate it in the current context of the target form. If the evaluation fails, the processing engine will return an ORA error as if the condition had been part of a SQL expression. Some examples:
Condition Comments

:users.user_name is not null and :users.description is null The rule will be processed if the user_name field has a value and the description field does not sysdate >= to_date(1-1-2005, DDMM-RRRR) The rule will be processed if the current date is equal to or after January 1, 2005. You can Get a property in your expression of your condition. Conditions can refer to properties of objects using a SPEL syntax (Simplest Possible Expression Language). For example, this enables you to build a Condition that tests if a field is displayed or not. These expressions take the following general format: ${objectType.objectName.Property} Internally, the SPEL expression is a cover for Oracle Forms builtins like GET_ITEM_PROPERTY, GET_BLOCK_PROPERTY, etc. Additionally, the SPEL expressions support retrieving Profile values, Message Dictionary text, and Local Variables (described later). A new window, activated by the "Insert 'Get' Expression" button, has been provided to automatically construct the expression. When complete, the expression is inserted into the Value or Condition field from where the window was launched. You can manually type the expression too; however, we strongly recommend using the window to build it to reduce mistakes. For completeness, the SPEL expression supports the 'Value' property for an item; however, runtime performance is faster with the :block.field syntax. All processing drives off the existence of the string '${', so that string is no longer valid in any Condition or Value except for this purpose. If a Value contains a SPEL expression, it is processed as if it started with '=' (See Evaluation of Strings, above). Some examples:
Type String typed in Personalization form Result at runtime

Value ='The prompt is:' || ${item.block.field.prompt_text}||', located at: '||${item.block.field.x_pos}

The prompt is: User Name, located at: 2.0 {assuming that the current Prompt of field

block.field is 'User Name', and it's X position is 2.0} Condition ${item.block.field.required} = 'TRUE' {True or False, depending on the current Required property of field block.field}
Fire in Enter-Query Mode:Specify whether the Rule(s) should be applied while not in Enter-

Query mode (the default), only in Enter-Query mode, or in Both modes. Each Rule consists of one or more Scope rows, and one or more Actions. If a Rule has no Scope rows or Action rows, it is not processed. Note that upon saving a Rule, if no Scope rows have been entered the form will automatically create a row at the Site level. If any scope matches the current runtime context then the Rule will be processed. The following Scope fields appear in the Context region of the Condition tab: Level: Select the level at which you want the rule to be applied, either Site, Responsibility, User, or Industry. Value: Based on the Level, either Disabled, or Enabled and Required in which case it will validate against a List of Values. All Action fields appear on the Actions tab.
Figure 2: the Actions tab of the Personalization form

Seq: The sequence in which actions will be processed within that Rule. This is a value between 1

and 100, with 1 being processed first. The sequence does not have to be unique. All of the actions associated with a particular rule are processed as a group, then the next rule (if any) is processed. This feature is particularly useful when moving items, in which case a canvas may have to be resized first before an X Position can be altered.

Type: the type of action to take:

Property: allows you to select a specific object, a property of that object, and specify a new value

for that property

Builtin: allows execution of a standard Forms Builtin, such as GO_BLOCK or DO_KEY Message: displays a message in one of several styles Menu: enables a special menu entry, defining its label, icon name and which blocks it applies to.

Description: Use this field to document the personalization action you are making. Language: Specify 'All' to have the action processed for any language, or select a specific

language. Typically text-related personalizations would be applied for a specific language. Enabled: Uncheck this checkbox to temporarily disable processing of the action. Apply Now: For several Types, this button will be enabled. It allows you to apply the change immediately to the target form to test its effect. Note that the actual effect that will occur during normal runtime execution of rules may be different, due to timing of triggers and other considerations. The following buttons are enabled conditionally based on the Type field: Add Parameter: List of Values that displays currently used parameters. Applies to the builtin FND_FUNCTION.EXECUTE only.

Add Block: List of Values that displays block names. Add Item: List of Values that displays item names. Validate:Used to test if the syntax of your string is valid. If the evaluation fails, the processing

engine will return an ORA error as if the string had been part of a SQL expression. Otherwise, it

will display the text exactly as it would appear at runtime in the current context. The following fields appear conditionally based on the Type field: For a Type of 'Property':
Figure 3: The fields associated with an action of 'Property'

Select By Text: This button allows you to select an object based on text appearing on the screen

at the point in time that you invoke the Personalization form, including any changes that current rules might have performed. For example, if you want to change a field with the current prompt of 'Item Number', you should see 'Item Number' in this list, and selecting it will automatically fill in the Object Type and Target Object fields. Note: As the visible text for objects may be identical across multiple windows of the same form, it is sometimes difficult to determine exactly which object you wish to personalize. The Select By Text list includes the window title in parentheses following the normal object text.
Object Type: the type of object, including Item, Window, Block, Tab, Canvas, Radio button,

List of Value (LOV), View, Global variable, Local variable, or Parameter. A Local variable is similar to a Global variable, except that it creates a variable local to the current form, with a maximum length of 4000 bytes (Global variables are limited to 255 bytes).
Target Object: based on the Object Type, the internal name of the object. For Object Types of

GLOBAL and PARAMETER, the Target Object name must not include those keywords. For example, to refer to GLOBAL.XX_MY_VARIABLE, only enter XX_MY_VARIABLE. Note: If a Tab page does not appear in the list of objects its name can be entered manually. This is meant to address the known limitation that some tab names cannot be automatically detected at runtime. You will need to open the form in the Oracle Forms Builder to determine these tab names, and then you can type it into this Combobox.
Property Name: based on the Object Type, the properties that can be personalized. The

Object Type of Item supports a vast array of properties including:

Item-level properties, which set the property for all instances of that object.

Item-instance properties, which set the property for the current record of that block using set_item_instance_property()

Applications cover properties, which are a hybrid of multiple item and iteminstance level properties. These are fully documented in the Oracle Applications Developers Guide. For the LOV object type, simple LOV properties can be modified using Form Personalization, including GROUP_NAME, HEIGHT, TITLE, WIDTH, X_POS and Y_POS. At this point in time, the property RECORD_GROUP_QUERY, which would allow you to dynamically change the underlying query of an LOV, cannot be changed; this is being considered for a future release. For the Block object type, the property ALLOW_NON_SELECTIVE_SEARCH is provided. For those blocks where a Blind Query has been prevented by development for performance reasons, this new property allows you to re-enable Blind Query on a block-by-block basis. Also for the Block object type, the property EXPORT_HIDDEN_CANVASES allows for exporting block data that is on hidden canvases. See: Exporting Data on Hidden Canvases, below.
Value: the new value. The appearance and validation of this field changes based on whether

the property accepts Boolean values (True/False), numbers, a restricted set of values, or a string (See Evaluation of Strings below) Get Value:This button gets the current property value of the object. For a Type of 'Message':

Form Personalization for R12


Download this Document for FreePrintMobileCollectionsReport Document

Info and Rating


Technology Information Form General Oracle Personalization Business-European (more tags) Follow joelasselin@video...

Share & Embed

Related Documents
PreviousNext 1.

p.

p.

p.

2.

p.

p.

p.

3.

p.

p.

p.

4.

p.

p.

p.

5.

p.

p.

p.

6.

p.

p.

p.

7.

p.

p.

p.

8.

p.

p.

p.

9.

p.

p.

p.

10.

p.

p.

p.

11.

p.

p.

p.

12.

p.

p.

p.

13.

p.

p.

p.

14.

p.

p.

p.

15.

p.

p.

p.

16.

p.

p.

p.

17.

p.

p.

p.

18.

p.

p.

p.

More from this user


PreviousNext 1.

2 p.

4 p.

18 p.

2.

113 p.

36 p.

1 p.

3.

2 p.

Recent Readcasters

Add a Comment

Ahmad Al-naqourileft a comment Nice Doc 05 / 19 / 2010

Larry Sherrodleft a comment It doesn't explain froms presonalizations in the R12 HTML forms 01 / 03 / 2008 Upload a Document Search Documents

Follow Us! scribd.com/scribd twitter.com/scribd facebook.com/scribd About Press Blog Partners Scribd 101 Web Stuff Support FAQ Developers / API Jobs Terms Copyright Privacy

Copyright 2011 Scribd Inc. Language: English

You might also like