Two of my papers have been selected for the upcoming OHUG [Oracle HCM Users Group].

• XML Publisher to the rescue of Seeded Reports
• API User Hook's - A hidden strength of Oracle HRMS
  

We had a number of queries and discussions on the OA Framework Forum on OTN regarding OAF, ADF and Oracle Applications. In this article, I am going to cover where OAF and ADF stand with respect to Oracle Applications and what are the expectations out of them.

OAF stands for Oracle Applications Framework and is a MVC architecture based J2EE framework customized for use in Oracle Applications development. It is tailor made for use in the development, customization of Oracle Apps pages and any custom application development to be hosted, integrated in Oracle Apps. It has the inbuilt support for features like session management, AOL/J security, connection pooling etc. OAF provides classes for all the standard web widgets seen on the Self Service pages like Text field, List of Values, Table, HGrid, Buttons etc. I won't go deep into OAF architecture, you can get that detail in the OAF Dev guide.

Only choice of tool to work with OAF is Jdeveloper with OA Extension. There is no OA extension /plugin available for any other IDE. This is another factor where people keep getting confused. Jdeveloper is a generic Java IDE but the one without the OA extension can't be used for OAF development. OA extension is what provides the required OA libraries and enables OA based Workspace, Project creation.

OAF is the only option for any Oracle Apps related development [Here I am not considering PUI Forms interface for the simple reason that Oracle has stopped any new PUI based development a couple of years ago and is trying to convert them to OA pages]. Release 11i and recently launched Release 12 version of Oracle Apps is based on OAF. For look & feel and business logic changes to Oracle provided seeded Self Service pages, one can make use of Extension and Personalization features of OAF. Modifications done following the Extension and Personalization guidelines are upgrade and patch safe. Any direct modification made to seeded code will be overwritten during the patching.

ADF stands for Application Development Framework. Unlike OAF, it is not a vendor or technology specific framework. In fact it supports a number of technologies for each of its Model, View and Controller components and hence has received a good appreciation from the developer, architect community. It has gained popularity as the choice of framework for generic J2EE based applications development.

ADF is going to be used for Fusion release of Oracle Applications. As oracle itself is working on the Fusion release of Applications code and establishing the Applications specific standards, libraries, I don't see the fusion specific ADF development standards being out for customers, vendors anytime before 2009 or 2010 [ Might be even later based on the policy they come up with]. Though you can still create custom applications in ADF and host on a 10gAS server, the integration, maintenance, Apps LAF will be the issues you will have to face. ADF still doesn't have the native support for integration with release 11i or R12 based system and I don't see it coming as ADF is more of meant for fusion product which is still underway. As the path will be to move to fusion, I don't think that there will be any extra effort to provide native support of ADF for 11i or even in R12.

The first looks of the Fusion release Applications are supposed to be out in the Dec, 2008 [ % of functionality covered is not committed] and now with the exit [read firing] of John Wookey, Senior Vice President of Applications Development, who spearheaded the fusion development, I am not sure what's the new milestone dates as per new management [signs of further delays are out]. Well, this definitely means that all the customers will be on 11i or R12 release of code for a couple of more years and the biggest chunk of maintenance/enhancement work will be based on OAF. To stress on this aspect, you should consider the fact that there are no standards, guidelines available for customers, vendors with respect to ADF and Fusion. With the new framework going to take some time to get stabilize along with new fusion Apps code development, its going to take couple of more years.

Only scenario where I see ADF fit into current Apps related development is the kind of project where you have to develop a completely standalone application which just uses the Oracle Apps data but is not required to integrate with the Oracle Apps. For all Oracle Applications related development and customizations, stick to OA Framework.

What does the above mean? Good news for OAF developers as for next 5-6 years, most of the Oracle Applications related work will be on OA framework. Also keep in mind that ADF has many features which are similar to OAF. Hence it will be an easy path to learn ADF if you know OAF properly and want to move over to ADF related development. As the majority of current Oracle Applications code and customizations are OAF based, there should be an easy migration road map for OAF based customizations to fusion technology.

Mukul has put up a nice intro on the comparison of OAF and ADF tech stacks. Check it here.

Change and Late Audit is one of the most important functionalities of Oracle Time & Labor. Change and Late Audit feature known as CLA allows system to identify the time or attribute information on Timecard which should be audited and requires to enter an explanation/comment of why a change was made to the timecard or why the entry is late. It is an optional feature and doesn't fall into the mandatory setups of OTL.

What is a CHANGE entry and what is a LATE entry? Change and late rules are not fixed entities and can be configured through the appropriate OTL preferences and Time Entry Rules. Even the list of reasons for auditing is configurable. Change and Late audit enables you to track all changes to new Timecards, as well as previously saved and submitted Timecards. These changes include modifying a saved or submitted timecard and saving timecards after a defined due date. For example, you may wish to have workers enter a reason why they changed their hours worked on Friday from 4 to 6, or why an hours type was changed to overtime from regular.

CLA feature was added to OTL to comply with the US Defense Contractor Audit Agency [DCAA]. As in a change and audit scenario, you have to track all the changes , a basic building block upon which our tracking attributes are based on can't be deleted. Hence a Timecard once created, can't be deleted. An hour entry made against a day for a particular receiving application attribute can't be deleted. So what's the solution in a scenario where audit is enabled and a Timecard has to be deleted or a wrong hour entry value has to be deleted? Only option, set the hour entries to zero.

Considering the above fact, the very first preference change for CLA setup is to disable the "Delete Timecards". This will disable the delete icon on the Recent Timecard Page.

Next preference to be modified is the "Self Service Process Flow" preference. This preference needs to be set to "Audit" from the default value of "Standard" which will add the CLA logic to the normal timecard processing flow and will prompt for Change & Late reasons if they are required to be entered as per setup.

As CLA functionality will require a new screen to show the change, late entries and prompt user to provide reason/comment, this new screen is provided through the Audit Layout. Hence Audit Layout needs to be added to "Self Service Timecard Layout" preference. This preference will already have the values for the Timecard, Review and Confirmation layouts at a minimum. When CLA is enabled for employees, you definitely would like to show those audit information to approver also. That means you also need to set the CLA Approver layout.

Now to determine which entry is late and which is a change, we need to create time entry rules. Attach these rules to a Time entry rule group and assign the rule group to a person through the preference. Existing seeded rules can be used a starting point for any custom rule development.

CLA feature was initially enabled for Self Service Time Entry only and later on was developed for Timekeeper also.

In the previous post Timecard Layout Modification, we saw the basic setup changes required for the addition of new Context OHUGLOCATION in the OTL Time Store and the further steps to create/add the corresponding mapping component.

Lets see now, how do we modify the timecard layout LDT files.

Step 1. Define the data source for New Location Field

OTL provides 10 custom view objects which save the effort of creating/managing new database object.

Name : CustomXVO
Class Path : oracle.apps.hxc.selfservice.timecard.server.CustomXVO
View : HXC_CUI_CUSTOMX_V where X stands for 1 to 10

We will use Custom1VO for location choice list. Make sure that this view is not already in use.

create or replace view HXC_CUI_CUSTOM1_V as
select 
     STATE_NAME display_value, 
     STATE_CODE value
from 
     PAY_US_STATES

• Timecard : Timecard Entry Screen.
• Review : Timecard Review Screen.
• Confirmation : Timecard Confirmation Screen.
• Notification : Notification screen as seen by the Approver.

• Details : To capture extra details like DFF fields.
• Export : For Disconnected Time Entry.
• Approval Fragment : Used when multiple applications are used in single Timecard like Project and Payroll.

• Change the HXC_LAYOUT field value
  
• Change the DISPLAY_LAYOUT_NAME field value
  
• Do a Search and Replace All for the old DISPLAY_LAYOUT_NAME with the new name
• To add a new Choice List, copy the seeded Cost Center component and paste below Cost Center.
• Comment off the Cost Center field. # sign can be used to comment out the lines from layout files.
  

• Component header name
• Component_Value
• Attribute_Code set to AK Attribute created above
• Sequence : Determines the sequence of components on Timecard
• Parent_Component
• Comp_Qualifier Header
• Attribute1 : Custom1VO
• Attribute10 : Custom1VO class path
• Attribute26 : OTL Information Type DFF Context
• Attribute27 : Corresponding Segment from the Attribute26 context
• Attribute30 : Y for all the layouts except Timecard entry. A value of Y makes this component as Read Only
  

BEGIN HXC_LAYOUT_COMPONENTS "OHUG Payroll Timecard Layout - Locationr"
   OWNER = "ORACLE"
   COMPONENT_VALUE = "OHUGLOCATION"
   REGION_CODE = "HXC_CUI_TIMECARD"
   REGION_CODE_APP_SHORT_NAME = "HXC"
   ATTRIBUTE_CODE = "OHUG_HXC_LOCATION_PROMPT"
   ATTRIBUTE_CODE_APP_SHORT_NAME = "HXC"
   SEQUENCE = "195"
   COMPONENT_DEFINITION = "CHOICE_LIST"
   RENDER_TYPE = "WEB"
   PARENT_COMPONENT =
  "OHUG Payroll Timecard Layout - Day Scope Building blocks for worker timecard matrix"
   LAST_UPDATE_DATE = "2004/05/24"


   BEGIN HXC_LAYOUT_COMP_QUALIFIERS "OHUG Payroll Timecard Layout - Locationr"
     OWNER = "ORACLE"
     QUALIFIER_ATTRIBUTE_CATEGORY = "CHOICE_LIST"
     QUALIFIER_ATTRIBUTE1 = "Custom1VO"
     QUALIFIER_ATTRIBUTE4 = "N"
     QUALIFIER_ATTRIBUTE8 = "DisplayValue"
     QUALIFIER_ATTRIBUTE9 = "Value#NUMBER"
     QUALIFIER_ATTRIBUTE10 =
    "oracle.apps.hxc.selfservice.timecard.server.Custom1VO"     
     QUALIFIER_ATTRIBUTE17 = "OraTableCellText"
     QUALIFIER_ATTRIBUTE20 = "N"
     QUALIFIER_ATTRIBUTE21 = "Y"
     QUALIFIER_ATTRIBUTE22 = "L"
     QUALIFIER_ATTRIBUTE25 = "FLEX"
     QUALIFIER_ATTRIBUTE26 = "OHUGLOCATION"
     QUALIFIER_ATTRIBUTE27 = "Attribute1"
     LAST_UPDATE_DATE = "2004/05/24"
   END HXC_LAYOUT_COMP_QUALIFIERS 

Step 6. Login as the user and verify the modification on each of the layouts.

Timecard Entry Page

Timecard Review Page

Timecard Confirmation Page