Basics of Core HRMS in Oracle Apps Part6

Basics of Core HRMS in Oracle Apps

APIs

Application Programmatic Interface: API is nothing but a logical grouping of PL/SQL packaged procedures and functions, which acts as an interface to the database.
APIs are used extensively in Oracle HRMS. For every insert/update or delete to any of the base tables, an API is available.
APIs are primarily used to validate the data being inserted into the base tables and also for inserting or updating the data on deleting the data from the base tables.
Object Version Number

In Oracle HRMS, every row in the database table has an object version number. When a new row is created, the object version number for the row is 1. When the row is changed, the object version number is incremented by one. When a user queries a record, the object version number is also fetched along with the other information.

Consider, two users A and B query the same record having Object Version Number 1 simultaneously. If user A makes changes to the records and saves the changes, the current object version number (in this case 1) is compared with the object version number of the record in the database (in this case 1). Since, these values are same, the changes are valid and so the changes are saved and the object version number of the record is incremented by 1. It will become 2.
If user B also does changes and tries to save them, the object version number in the database is 2 against the object version number of the record sent to client (in this case 1). Since, the object version numbers are different, it is evident that the record is already changed by another user and so the changes done by user B are not valid as they may override changes done by user A.
The user B will get an error message:”Record has been modified by another user”. He/she will have to re-query the record to do the changes.
This is one of the important parameters for an API.

Parameters
Every API has a number of parameters. Not all parameters are mandatory. Generally, the optional parameters are followed by a default value, e.g. p_email_address in varchar2 default null.

Control Parameters
Control parameters are the mandatory parameters common across all the APIs.

p_object_version_number
This is one of the control parameters. For insert APIs, p_object_version_number is an OUT parameter. For update APIs, p_object_version_number is an IN OUT parameter.

p_validate
This is an IN parameter. The parameter decides that the record needs to be saved to the database or not Default value for p_validate is FALSE. If TRUE value is passed, the data is only validated and not saved to the database.

p_effective_date
APIs that are used to insert/update/delete the date tracked data have this control parameter. This is a mandatory IN parameter that defines the date from which the current change needs to be applied.

p_datetrack_update_mode
APIs used to update the date tracked data have this control parameter. Valid values for this parameter are: UPDATE, CORRECTION, UPDATE_OVERRIDE and UPDATE_CHANGE_INSERT

p_datetrack_delete_mode
APIs used to delete date track data have this control parameter. Valid values for this parameter are: ZAP, DELETE, FUTURE_CHANGE, and DELETE_NEXT_CHANGE

List of Important APIs

Work Structures
HR_ORGANIZATION_API
HR_JOB_API
HR_POSITION_API
HR_GRADE_API
HR_VALID_GRADES_API
HR_LOCATION_API

People
HR_EMPLOYEE_API
HR_PERSON_API
HR_ASSIGNMENT_API
HR_PERSON_ADDRESS_API
HR_PHONE_API
HR_UPLOAD_PROPOSAL_API
HR_APPLICANT_API
HR_CONTACT_API
HR_CONTACT_REL_API
HR_PERIODS_OF_SERVICE_API

Payroll
PAY_ACTION_INFORMATION_API
PAY_BATCH_ELEMENT_ENTRY_API
PAY_COST_ALLOCATION_API
PAY_ELEMENT_ENTRY_API
PAY_ELEMENT_LINK_API
PAY_ELEMENT_TYPES_API
PAY_INPUT_VALUE_API

SIT

SIT stands for Special Information Types.
This is nothing but the Personal Analysis Key Flexfield. This can be used to define any special information that cannot be stored with the help of the main system. Any number of instances can be defined of the Personal Analysis KFF. Each instance is knows as Special Information Type. Each SIT can have up to thirty fields. Each field is a segment of the KFF.
When a new segment combinations is created, the system will first check to see whether that combination already exists in the table before creating a row. If the combination does exist, the system only retrieves the ID of the row it found. The system therefore has to scan through the whole SIT combinations table.
SITs are primarily attached to people. They can also be used with Jobs, Positions, and Activities (in OTA), but with skill meaning (competencies).

EIT

EIT stands for Extra Information Types.
EITs are a type of Descriptive Flexfield. When a new segment combinations is created, the row is just inserted into the appropriate table (without checking whether the combination already exists). There is now full scan of the underlying table and so performance shouldn't be affected by the size of the table.
EIT's can be attached to People, Assignment, Job, Position, Location and Organization.

*/