Oracle Application Express (Oracle Apex) is a rapid web application development tool for the Oracle database. Using only a web browser and limited programming experience, you can develop and deploy professional applications. We wanted to extend the E-Business Suite functionality with Apex features. Apex functions need to be available from the EBS user menu. Users have to be able to move seamlessly from EBS to Apex, without logging in twice. The context of the EBS user needs to specify which data the user is allowed to see in Apex. Our goal was to develop a calendar in Apex which shows a team's absences for the logged in supervisor. In EBS the "supervisor -> employee" relation has a hierarchical structure, which has to be available in the calendar.

The first challenge we have to deal with is authentication. Apex users have to log in to access an application. We used the EBS security to allow users to logon to Apex using their EBS username and password. In Apex we created a custom authentication scheme which calls an external function to validate the username and password. The authentication scheme calls our plsql function "apex_authorise" which uses the EBS "fnd_web_sec.validate_login" to validate the username and password. At this point we are able to log in to an Apex application using any valid EBS username and password combination.

Now we want to link Apex forms from the EBS menu. The first problem is that Apex requires a valid password for the user and the EBS database does not contain passwords, it holds a hash of the username/password combination. You can handle this by creating an alternative password using the DBMS_OBFUSCATION_TOOLKIT md5 function. The password will be generated by hashing the username, a time component and a key held within the database. This mechanism will be handled in two functions: "apex_generate_hash" and "apex_validate_hash". To check if the password is valid, we extend the already created function "apex_authorise".

Now we want to login in Apex automatically. We use a cookie to achieve this. The form function we use in EBS, sets a cookie containing the username and password and redirects to the Apex URL to launch the Apex application. In EBS we have to create a web enabled mod_plsql procedure to achieve this. This form function can then be added to the EBS menu. In Apex we use a "before header" process to read the cookie and log the user in.

The cookie we used:

OWA_COOKIE.send
(name=>'APEX_APPS_'||application,
value=>FND_GLOBAL.user_name||':'||
apex_generate_hash(FND_GLOBAL.user_name)||':'||
FND_GLOBAL.user_id||':'||
FND_GLOBAL.resp_id||':'||
FND_GLOBAL.resp_appl_id
);

We store the FND_GLOBAL values in global variables in Apex. We use these variables in the page query of an Apex application to only show the results for this specific user. In our case we used the standard calendar feature of Apex. In this calendar you can specify a sql query which selects the data to publish.

Ideally we want to save the context of the environment an APPS user is working in and seamlessly use this context in our Apex application. This way we don't have to care about which data is visible for the user, the APPS security mechanism will take care of that. This is something which has to be investigated. In our project we send the user information in the cookie, and use this information for our data selection.

We need to personalize OAF pages to customize users view of them, rather than to extend the functionality of an application. We cannot, for example, add a new region to an existing page, modify business logic, such as data validation, or build new pages using personalization. To do this we need to create extensions using Oracle 9i JDeveloper with OA Extension.

Benefits of personalizations 

Personalizing pages in the OA framework enables you to cater for site-wide and user-specific needs at several levels.

Benefits of page personalizations in the OA framework are that 

*    They survive upgrades and patches 
*    Administrators can apply personalizations on any component 
*    Users can apply personalizations on queries 
*    Administrators can easily disable personalizations for debugging 
*    Personalizations can be implemented on a test system, for testing prior to deployment 
*    Personalizations can be translated 

Save OA framework-based pages as page definitions, for which the database stores metadata. At runtime, a page definition is layered over the base page it personalizes, leaving the original page unchanged.

Personalization Llevels

Personalizations may occur at the administrator or user level, or be seeded by Oracle application developers. 

Administrator-level personalizations

At the administrator level, all OA framework-based pages can be personalized by default. However, administrators cannot personalize programmatically created pages or regions, or pages or regions for which the application developer has explicitly disabled administrator personalization.

Administrators may personalize pages, for example, by

*    Changing text for labels, prompts, and tip messages 
*    Hiding or showing components 
*    Reordering components 
*    Restricting query results 
*    Adding items, such as fields, buttons, links, pick lists, or images 
*    Structuring graphs and charts 
*    Seeding end-user views 
*    Specifying whether fields are required 
*    Changing the destination of hyperlinks

The extent to which an administrator can personalize page flow is limited, and depends on how the flow was implemented. In some cases, you can modify function URLs and personalize the destination URLs that display as navigational elements. Page flow changes are generally beyond the scope of systems administrators, however, because such changes may affect transaction flows, and need thorough testing.

Administrators can personalize OA framework pages at the following levels:

*    Function 
*    Location 
*    Site 
*    Organization 
*    Responsibility

As an administrator, you can define personalizations at the function level to determine which users can access specific functions, and when. For example, you can hide the salary field from a user updating an employee record, but display it when the user creates a new employee.

At the location level, you can use locales as the context for personalization – for example, to show different address field labels based on users' country settings.

Site-level – or global – personalizations apply to all users with access to a given application component, such as "setting the number of rows shown in a table."

Organization-level personalizations apply only to users in a specified organization or business unit. You can use organization-level personalizations, for example, to stipulate that notifications be sorted by age for one organization and by urgency for another.

Personalizations at the responsibility level display only to users under a specific responsibility. You may, for example, configure a trend graph to display only to users under the sales manager responsibility.

The level at which an administrator configures personalization settings determines their precedence over other settings. For example, a responsibility-level personalization takes precedence over site-level personalizations for users with the specified responsibility. Users at the site who are not using the relevant responsibility would see only the site-level changes.

User Level Personalizations

Default user personalizations, or user views, can exist at three levels. They can be seeded by Oracle developers, created by a system administrator, or created by the end user.

End users can access the personalization user interface by clicking the Save View or Personalize button. They can then personalize inquiry pages using query regions to create specific data views. For example, they can

*    Create and save searches 
*    Configure table column titles 
*    Hide or show columns 
*    Reorder columns 
*    Add data filters 
*    Change sort orders

Oracle Seeded Levels

Oracle 11i E-Business Suite developers can seed personalizations – or build them into – Oracle applications. Seeded function and user-level personalizations, which are like the function and user levels available to administrators and users, respectively, can only be changed or deleted by Oracle customer administrators. However, system administrators or users may duplicate functions and then alter them using personalization settings.

Seeded function personalizations may, for example, provide applications with customized

*    Menus and responsibilities 
*    Cascading style sheets (CSS) 
*    FND messages and lookups 
*    Icons and images 
*    Other required business or user personalizations

OA developers can create and ship seeded personalizations at any administrator personalization level, but system administrators at the customer site can change or delete these settings.

Translating and Deploying Personalizations

You should create personalizations in a test environment before deploying them to one or more production environments, and you should always create initial personalizations in the base language of the application instance.

To export a small number of personalization translations, you use the Export or Upload Translations buttons on the Manage Personalization Levels page. To import or export personalizations in bulk, you use the Export tool to obtain XML files. Because XLIFF (.xlf) files support translations, you then use the XLIFF Extractor to extract translation information from the page XML files.

Finally, you use the XLIFF Importer to load translations into the database repository. Personalizations are stored as documents in the MDS Repository.

Summary

Administrators and end users can personalize pages in the Oracle Application (OA) framework to meet their needs and preferences. Administrators can create, translate, and deploy page personalizations at the function, location, site, organization, and responsibility levels. End users can personalize inquiry pages. Personalized page definitions are stored in the Oracle database, and don't alter the base pages to which they apply.

• The AR Dunning Letters is obsolete in R12.
  
• The AR Collections Workbench is obsolete in Release 12.
  
• You will need to install the Oracle Advanced Collections application.
  
• The basic Collections functionality is available in Oracle Advanced Collections without any extra cost. However, if you wish to use the more complex functionality in the Oracle Advanced Collections, you will need to pay for license cost.
  
• In R12 Advanced collections, you will now need to run Oracle Advanced Collections Dunning Plans instead.
  
• To using the Dunning Plan basic functionality you donot requires Oracle Advanced Collections license.
  
• The Dunning process in R12 Collections is based on Scoring. You can set it up so that a particular score is associated to a Dunning Letter Plan. Then only allow that one customer to get that score. Dunning Plans in Advanced Collections replace Dunning Letters in 11i AR , thus dunning Plans will need to be setup.
  
• Staged Dunning Letters does not exist in R12 Collections rather can be used the Standard Dunning Plans in R12 of Collections. However, for a more complex timing and use of Dunning letters you will want to setup the highly configurable Strategies and send your letters in this manner.Customer interactions and correspondence, transaction processing, and dunning activities are consider as basic functionality whereas scoring, collections strategies, enhanced payment and promise processing, automated promise tracking, and automated collector work assignment are consider as advance feature of product.
  
• In R12, dunning functionality is executed by XML Publisher.