APIs of Oracle HRMS
APIs of Oracle HRMS
APIs of Oracle HRMS
An Application Programmatic Interface (API) is a logical grouping of external process routines. The Oracle HRMS strategy delivers a set of PL/SQL packaged procedures and functions that together provide an open interface to the database. For convenience we have called each of these packaged procedures an API. This document provides all the technical information you need to be able to use these APIs and covers the following topics: API Overview Describes how you can use the Oracle HRMS APIs and the advantages of this approach. Understanding the Object Version Number (OVN) Explains the role of the object version number. The APIs use it to check whether a row has been updated by another user, to prevent overwriting their changes. API Parameters Explains where to find information about the parameters used in each API; parameter naming conventions; the importance of naming parameters in the API call instead of relying on parameter list order; and how to use default values to avoid specifying all parameters. Also explains the operation of certain control parameters, such as those controlling DateTrack operations. API Features Explains that commits are handled by the calling program, not the APIs, and the advantages of this approach. Also explains how to avoid deadlocks when calling more than one API in the same commit unit. Flexfields with APIs Describes how the APIs validate key flexfield and descriptive flexfield values. Multilingual Support Explains how to use the Multilingual Support APIs. Alternative APIs Explains that we provide legislation-specific APIs for some business processes, such as Create Address. API Errors and Warnings Explains how the APIs raise errors and warnings, and how the calling code can handle them. A message table is provided for handling errors in batch processes. Example PL/SQL Batch Program Shows how to load a batch of person address data and how to handle validation errors. WHO Columns and Oracle Alert Explains how to populate the WHO columns (which record the Applications user who caused the database row to be created or updated) when you use the APIs.
API User Hooks A user hook is a location where you can add processing logic or validation to an API. There are hooks in the APIs for adding validation associated with a particular business process. There are also hooks in table-level modules for validation on specific data items. This section explains where user hooks are available and how to implement them. It also explains their advantages over database triggers. Using APIs as Building Blocks Explains how you can write your own APIs that call one or more of the supplied APIs. Handling Object Version Numbers in Oracle Forms Explains how to implement additional Forms logic to manage the object version number if you write your own forms that call the APIs.
API Overview
Fundamental to the design of all APIs in Oracle HRMS is that they should provide an insulating layer between the user and the data-model that would simplify all datamanipulation tasks and would protect customer extensions on upgrade. They are parameterized and executable PL/SQL packages that provide full data validation and manipulation. The API layer enables us to capture and execute business rules within the database - not just in the user interface layer. This layer supports the use of alternative interfaces to HRMS, such as web pages or spreadsheets, and guarantees all transactions comply with the business rules that have been implemented in the system. It also simplifies integration of Oracle HRMS with other systems or processes and provides supports for the initial loading
to the HRMS applications could be applied electronically. Modifications can be made in batches or immediately on an individual basis. Customers who want to build a custom version of the standard forms supplied with Oracle HRMS. An alternative version of one or more forms could be implemented using the APIs to manage all database transactions. Customers who want to develop web-based interfaces to allow occasional users to access and maintain HR information without the cost of deploying or supporting standard Oracle HRMS forms. This is the basis of most SelfService functions that allow employees to query and update their own information, such as change of name, address, marital status. This also applies to managers who want to query or maintain details for the employees they manage. Managers who are more familiar with spreadsheet applications may want to export and manipulate data without even being connected to the database and then upload modifications to the HRMS database when reconnected. In all these examples, the programs would not need to modify data directly in the Oracle HRMS database tables. The specific programs would call one or more APIs and these would ensure that invalid data is not written to the Oracle HRMS database and that existing data is not corrupted.
APIs help to protect any customer-specific logic from database structure changes on upgrade. While we cannot guarantee that any API will not change to support improvements or extensions of functionality, we are committed to minimize the number of changes and to provide appropriate notification and documentation if such changes occur.
Note: Writing programs to call APIs in Oracle HRMS requires knowledge of PL/SQL version 2. The rest of this essay explains how to call the APIs and assumes the reader has knowledge of programming in PL/SQL.
User A updates the Town field to a different value and calls the update_person_address API passing the current object_version_number equal to 1. As this object_version_number is the same as the value on the database row the update is allowed and the object_version_number is incremented to 2. The new object_version_number is returned to user A and the row is committed in the database. User B, who has details of the original row, notices that first line of the address is incorrect. User B calls the update_person_address API, passing the new first line and what he thinks is the current object_version_number (1). The API compares this value with the current value on the database row (2). As there is a difference the update is not allowed to continue and an error is returned to user B. To correct the problem, user B then re-queries this address, seeing the new town and obtains the object_version_number 2. The first line of the address is updated and the update_person_address API is called again. As the object_version_number is the same as the value on the database row the update is allowed to continue. Therefore both updates have been applied without overwriting the first change.
API Parameters
This section describes parameter usage in Oracle HRMS.
Parameter Names
Each API has a number of parameters that may or may not be specified. Most parameters map onto a database column in the HR schema. There are some control parameters that affect the processing logic that are not explicitly held on the database.
Every parameter name starts with p_. If the parameter maps onto a database column, the remaining part of the name is usually the same as the column name. Some names may be truncated due to the 30 character length limit. The parameter names have been made slightly different to the actual column name, using a p_ prefix, to avoid coding conflicts when a parameter and the corresponding database column name are both referenced in the same section of code. When a naming conflict occurs between parameters, a three-letter short code (identifying the database entity) is included in the parameter name. Sometimes there is no physical name conflict, but the three-letter short code is used to avoid any confusion over the entity with which the parameter is associated. For example, create_employee contains examples of both these cases. Part of the logic to create a new employee is to insert a person record and insert an assignment record. Both these entities have an object_version_number. The APIs returns both object_version_number values using two OUT parameters. Both parameters cannot be called p_object_version_number, so p_per_object_version_number holds the value for the person record and p_asg_object_version_number holds the value for the assignment record. Both these entities can have text comments associated with them. When any comments are passed into the create_employee API, they are only noted against the person record. The assignment record comments are left blank. To avoid any confusion over where the comments have allocated in the database, the API returns the id using the p_per_comment_id parameter.
in in in
varchar2 default null in out varchar2 out out out out out out out out out out out out out number number number number date date varchar2 number number varchar2 boolean boolean boolean
Because no PL/SQL default value has been defined, the p_sex parameter must be set. The p_person_type_id parameter can be passed in with the ID of an Employee person type. If you do not provide a value, or explicitly pass in a null value, the API sets the database column to the ID of the active default employee system person type for the business group. The comments in each API package header creation script provide more information. The p_email_address parameter does not have to be passed in. If you do not specify this parameter in your call, a null value is placed on the corresponding database column. (This is similar to the user of a form leaving a displayed field blank.) The p_employee_number parameter must be specified in each call. When you do not want to set the employee number, the variable used in the calling logic must be set to null. (For the p_employee_number parameter, you must specify a value for the business group when the method of employee number generation is set to manual. Values are only passed out when the generation method is automatic or national identifier.) Example 1 An example call to the create_employee API where the business group method of employee number generation is manual, the default employee person type is required and the e-mail attributes do not need to be set.
declare l_emp_num varchar2(30); l_person_id number; l_assignment_id number; l_per_object_version_number number; l_asg_object_version_number number; l_per_effective_start_date date; l_per_effective_end_date date; l_full_name varchar2(240); l_per_comment_id number; l_assignment_sequence number; l_assignment_number varchar2(30); l_name_combination_warning boolean; l_assign_payroll_warning boolean; l_orig_hire_warning boolean; begin --- Set variable with the employee number value, -- which is going to be passed into the API. -l_emp_num := 4532; --- Put the new employee details in the database -- by calling the create_employee API -hr_employee.create_employee (p_hire_date => to_date('06-06-1996','DD-MM-YYYY') ,p_business_group_id => 23 ,p_last_name => 'Bloggs' ,p_sex => 'M' ,p_employee_number => l_emp_num ,p_person_id => l_person_id ,p_assignment_id => l_assignment_id
,p_per_object_version_number => l_per_object_version_number ,p_asg_object_version_number => l_asg_object_version_number ,p_per_effective_start_date => l_per_effective_start_date ,p_per_effective_end_date => l_per_effective_end_date ,p_full_name => l_full_name ,p_per_comment_id => l_per_comment_id ,p_assignment_sequence => l_assignment_sequence ,p_assignment_number => l_assignment_number ,p_name_combination_warning => l_name_combination_warning ,p_assign_payroll_warning => l_assign_payroll_warning ,p_orig_hire_warning => l_orig_hire_warning ); end;
Note: The database column for employee_number is defined as varchar2 to allow for when the business group method of employee_number generation is set to National Identifier. Example 2 An example call to the create_employee API where the business group method of employee number generation is Automatic, a non-default employee person type must be used and the email attribute details must be held.
declare l_emp_num varchar2(30); l_person_id number; l_assignment_id number; l_per_object_version_number number; l_asg_object_version_number number; l_per_effective_start_date date; l_per_effective_end_date date; l_full_name varchar2(240); l_per_comment_id number; l_assignment_sequence number; l_assignment_number varchar2(30); l_name_combination_warning boolean; l_assign_payroll_warning boolean; l_orig_hire_warning boolean; begin --- Clear the employee number variable -l_emp_num := null; --- Put the new employee details in the database -- by calling the create_employee API -hr_employee.create_employee (p_hire_date => to_date('06-06-1996','DD-MM-YYYY') ,p_business_group_id => 23 ,p_last_name => 'Bloggs' ,p_sex => 'M' ,p_person_type_id => 56 ,p_email_address => 'bloggsf@uk.uiq.com' ,p_employee_number => l_emp_num ,p_person_id => l_person_id
end;
,p_assignment_id ,p_per_object_version_number ,p_asg_object_version_number ,p_per_effective_start_date ,p_per_effective_end_date ,p_full_name ,p_per_comment_id ,p_assignment_sequence ,p_assignment_number ,p_name_combination_warning ,p_assign_payroll_warning ,p_orig_hire_warning ); --- The l_emp_num variable is -- employee_number allocated --
=> => => => => => => => => => => =>
l_assignment_id l_per_object_version_number l_asg_object_version_number l_per_effective_start_date l_per_effective_end_date l_full_name l_per_comment_id l_assignment_sequence l_assignment_number l_name_combination_warning l_assign_payroll_warning l_orig_hire_warning
Default Parameters with Update Style APIs With update style APIs the primary key and object version number parameters are usually mandatory. In most cases it is not necessary provide all the parameter values. You only need to specify any control parameters and the attributes you are actually altering. It is not necessary (but it is possible) to pass in the existing values of attributes that are not being modified. Optional parameters have one of the following PL/SQL default values, depending on the datatype as shown in the following table:
Data Type varchar2 number date Default value hr_api.g_varchar2 hr_api.g_number hr_api.g_date
These hr_api.g_ default values are constant definitions, set to special values. They are not hard coded text strings. If you need to specify these values, use the constant name, not the value. The actual values are subject to change. Care must be taken with IN OUT parameters, because they must always be included in the calling parameter list. As the API is capable of passing values out, you must use a variable to pass values into this type of parameter. These variables must be set with your values before calling the API. If you do not want to explicitly modify that attribute you should set the variable to the hr_api.g_... value for that datatype. The update_emp_asg_criteria API contains examples of these different types of parameters.
procedure update_emp_asg_criteria (... ,p_assignment_id in number ,p_object_version_number in out number ... ,p_position_id in number default hr_api.g_number ... ,p_special_ceiling_step_id in out number ... ,p_employment_category in varchar2 default hr_api.g_varchar2 ,p_effective_start_date out date ,p_effective_end_date out date
Note: Only the parameters that are of particular interest have been shown. Ellipses (...) indicate where irrelevant parameters to this example have been omitted. The p_assignment_id and p_object_version_number parameters are mandatory and must be specified in every call. The p_position_id parameter is optional. If you do not want to alter the existing value, then exclude the parameter from your calling logic or pass in the hr_api.g_varchar2 constant or pass in the existing value. The p_special_ceiling_step_id parameter is IN OUT. With certain cases the API sets this attribute to null on the database and the latest value is passed out of the API. If you do not want to alter this attribute, set the calling logic variable to hr_api.g_number. Example The following is an example call to the update_emp_asg_criteria API, with which you do not want to alter the position_id and special_ceiling_step_id attributes, but you do want to modify the employment_category value.
declare l_assignment_id number; l_object_version_number number; l_special_ceiling_step_id number; ... begin l_assignment_id := 23121; l_object_version_number := 4; l_special_ceiling_step_id := hr_api.g_number; hr_assignment_api.update_emp_asg_criteria (... ,p_assignment_id => l_assignment_id ,p_object_version_number => l_object_version_number ... ,p_special_ceiling_step_id => l_special_ceiling_step_id ... ,p_employment_category => 'FT' ... ); --- As p_special_ceiling_step_id is an IN OUT parameter the -- l_special_ceiling_step_id variable is now set to the same -- value as on the database. i.e. The existing value before -the API was called or the value which was derived by the -- API. The variable will not be set to hr_api.g_number. -end;
Default Parameters with Delete Style APIs Most delete style APIs do not have default values for any attribute parameters. In rare cases parameters with default values work in a similar way to those of update style APIs.
that savepoint at the end. You do not have access to these internal savepoints. If the procedure is successful, without raising any validation errors, then non-warning OUT parameters are set to null, warning OUT parameters are set to a specific value, and IN OUT parameters are reset to their IN values. In some cases you may want to write your PL/SQL routines using the public API procedures as building blocks. This enables you to write routines specific to your business needs. For example, say that you have a business requirement to apply a DateTracked update to a row and then apply a DateTrack delete to the same row in the future. You could write an "update_and_future_del" procedure that calls two of the standard APIs. When calling each standard API, p_validate must be set to false. If true is used the update procedure call is rolled back. So when the delete procedure is called, it is working on the non-updated version of the row. However when p_validate is set to false, the update is not rolled back. Thus, the delete call operates as if the user really wanted to apply the whole transaction. If you want to be able to check that the update and delete operation is valid, you must issue your own savepoint and rollback commands. As the APIs do not issue any commits, there is no danger of part of the work being left in the database. It is the responsibility of the calling code to issue commits. The following simulates some of the p_validate true behavior. Example
savepoint s1; update_api_prc(.........); delete_api_prc(..........); rollback to s1;
You should not use our API procedure names for the savepoint names. An unexpected result may occur if you do not use different names.
Example 2 This example creates a new employee who joins the company at the start of March 1997.
Some APIs that do not modify data in DateTrack entities still have a p_effective_date parameter. The date value is not used to determine when the changes take effect. It is used to validate Lookup values. Each Lookups value can be specified with a valid date range. The start date indicates when the value can first be used. The end date shows the last date the value can be used on new records and set when updating records. Existing records, which are not changed, can continue to use the Lookup after the end date.
It may not be possible to use every mode in every case. For example, if there are no existing future changes for the record you are changing, the DateTrack modes UPDATE_OVERRIDE and UPDATE_CHANGE_INSERT cannot be used. Some APIs that update DateTrack entities do not have a p_datetrack_update_mode parameter. These APIs automatically perform the DateTrack operations for that business operation. Each dated instance for the same primary key has a different object_version_number. When calling the API the p_object_version_number parameter should be set to the value that applies as of the date for the operation (that is, p_effective_date). Example Assume grade rate values shown in the following table already exist in the pay_grade_rules_f table:
Grade_rule_i Effective d Start_Date 12122 01-JAN-1996 12122 21-FEB-1996 Effective_ End_Date 20-FEB-1996 20-JUN-1998 Object_Version_ Number 2 3 Value 45 50
Also assume that the grade rate value was updated to the wrong value on 21-FEB-1996. The update from 45 to 50 should have been 45 to 55 and you want to correct the error.
declare l_object_version_number number; l_effective_start_date date; l_effective_end_date date; begin l_object_version_number := 3; hr_grade_api.update_grade_rate_value (p_effective_date => to_date('21-02-1996','DD-MM-YYYY') ,p_datetrack_update_mode => 'CORRECTION' ,p_grade_rule_id => 12122
,p_object_version_number => l_object_version_number ,p_value => 55 ,p_effective_start_date => l_effective_start_date ,p_effective_end_date => l_effective_end_date ); -- l_object_version_number will now be set to the value -- as on database row, as of 21st February 1996. end;
It may not be possible to use every mode in every case. For example, if there are no existing future changes for the record you are changing, the DateTrack modes FUTURE_CHANGE and DELETE_NEXT_CHANGE cannot be used. Some APIs that update DateTrack entities do not have a p_datetrack_delete_mode parameter. These APIs automatically perform the DateTrack operations for that business operation. Refer to the comments in each API package header creation script for further details. Each dated instance for the same primary key has a different object_version_number. When calling the API the p_object_version_number parameter should be set to the value that applies as of the date for the operation (that is, p_effective_date). Example Assume that the grade rate values shown in the following table already exist in the pay_grade_rules_f table:
Grade_rule_i Effective_ d Start_Date 5482 15-JAN-1996 5482 24-MAR-1996 Effective_ End_Date 23-MAR-1996 12-AUG-1996 Object_Version_ Number 4 8 Value 10 20
Also assume that you want to remove all dated instances of this grade rate value from the database.
declare l_object_version_number number; l_effective_start_date date; l_effective_end_date date; begin l_object_version_number := 4; hr_grade_api.update_grade_rate_value (p_effective_date => to_date('02-02-1996', 'DD-MM-YYYY') ,p_datetrack_delete_mode => 'ZAP' ,p_grade_rule_id => 5482 ,p_object_version_number => l_object_version_number
,p_effective_start_date ,p_effective_end_date );
The update_grade_rate_value API is called to perform a DateTrack mode of UPDATE_CHANGE_INSERT with an effective date of 10-MAR-1996. The API then modifies the database rows as shown in the following table:
Grade_rule_id 17392 17392 17392 Effective_ Start_Date 01-FEB-1996 10-MAR-1996 25-MAY-1996 Effective_ End_Date 09-MAR-1996 24-MAY-1996 01-SEP-1997
If this parameter is set to null or hr_api.g_varchar2, the hr_api.userenv_lang default is still used. See: Multilingual Support
API Features
Commit Statements
None of the HRMS APIs issue a commit. It is the responsibility of the calling code to issue commit statements. This ensures that parts of a transaction are not left in the database. If an error occurs, the whole transaction is rolled back. Therefore API work is either all completed or none of the work is done. You can use the HRMS APIs as "building blocks" to construct your own business functions. This gives you the flexibility to issue commits where you decide. It also avoids conflicts with different client tools. For example, Oracle Forms only issues a commit if all the user's changes are not in error. This could be one or more record changes, which are probably separate API calls.
Avoiding Deadlocks
If calling more than one API in the same commit unit, take care to ensure deadlock situations do not happen. Deadlocks should be avoided by accessing the tables in the order they are listed in the table locking ladder. For example, you should update or delete rows in the table with the lowest Processing Order first. If more than one row in the same table is being touched, then lock the rows in ascending primary key order. For example, if you are updating all the assignments for one person, then change the row with the lowest assignment_id first. If it is impossible or impractical for operations to be done in locking ladder order, explicit locking logic is required. When a table is brought forward in the processing order, any table rows that have been jumped and will be touched later must be explicitly locked in advance. Where a table is jumped and none of the rows are going to be updated or deleted, no locks should be taken on that table. Example Assume that the locking ladder order is as shown in the following table:
Table A B C D A D C 1st 2nd 3rd 10 20 30 40 Processing Order
Also assume that your logic has to update rows in the following order:
Then your logic should: 1. Update rows in table A. 2. Lock rows in table C. (Only need to lock the rows that are going to be updated in step 4.) 3. Update rows in table D. 4. Update rows in table C. Table B is not locked because it is not accessed after D. Your code does not have to explicitly lock rows in tables A or D, because locking is done as one of the first steps in the API.
In summary, you can choose the sequence of updates or deletes, but table rows must be locked in the order shown by the table locking ladder.
Multilingual Support
Several entities in the HRMS schema provide Multilingual Support (MLS), where translated values are held in _TL tables. For general details of the MLS concept refer to the following documentation: See: Oracle Applications Concepts Manual for Principles of MLS, and Oracle Applications Install Guide for Configuration of MLS. As the non-translated and translated values are identified by the same surrogate key ID column and value, the Multilingual Support APIs manage both groups of values in the same PL/SQL procedure call.
Create and update style APIs have a p_language_code parameter which you use to indicate which language the translated values apply to. The API maintains the required rows in the _TL table, setting the source_lang and language columns appropriately. These columns, and the p_language_code parameter, hold a language_code value from the FND_LANGUAGES table. The p_language_code parameter has a default value of hr_api.userenv_lang, which is equivalent to:
select userenv('LANG') from dual;
Setting the p_language_code parameter enables you to maintain translated data for different languages within the same database session. If this parameter is set to null or hr_api.g_varchar2 then the hr_api.userenv_lang default is still used. When a create style Multilingual Support API is called, a row is inserted into the _TL table for each base and installed language. For each row, the source_lang column equals the p_language_code parameter and the translated column values are the same. When the other translated values are available they can be set by calling the update API, setting the p_language_code parameter to the appropriate language code. Each call to an update style Multilingual Support API can amend the non-translated values and one set of translated values. The API updates the non-translated values in the main table and translated data values on corresponding row, or rows, in the _TL table. The translated columns are updated on rows where the p_language_code parameter matches the language or source_lang columns. Including a matching against the source_lang column ensures translations that have not been explicitly set remain synchronised with the created language. When a translation is being set for the first time the source_lang column is also updated with the p_language_code value. If you want to amend the values for another translation, call the update API again setting the p_language_code and translated parameters appropriately. For delete style Multilingual Support APIs there is no p_language_code parameter. When the non-translated data is removed, all corresponding translation rows in the _TL table are also removed. So the API does not need to perform the process for a particular language. When a Multilingual Support API is called more than one row may be processed in the _TL table. To avoid identifying every row that will be modified, _TL tables do not have an object_version_number column. The main table, holding the non-translated values, does have an object_version_number column. When you use a Multilingual Support API, set the p_object_version_number parameter to the value from the main table, even when only updating translated values.
Alternative APIs
In some situations it is possible to perform the same business process using more than one API. This is especially the case where entities hold extra details for different legislations. Usually there is a main API, which can be used for any legislation, and also specific versions for some legislations. Whichever API is called, the same validation and changes are made to the database. For example, there is an entity to hold addresses for people. For GB style addresses some of the general address attributes are used to hold specific details, as shown in the following table:
PER_ADDRESSES Table Column Name style address_line1 address_line2 address_line3 town_or_city region_1 region_2 region_3 postal_code country telephone_number_1 telephone_number_2 telephone_number_3
create_person_address API create_gb_person_ address API Parameter Name Parameter Name p_style N/A p_address_line1 p_address_line1 p_address_line2 p_address_line2 p_address_line3 p_address_line3 p_town_or_city p_town p_region_1 p_county p_region_2 N/A for this style p_region_3 N/A for this style p_postal_code p_postcode p_country p_country p_telephone_number_1 p_telephone_number p_telephone_number_2 N/A for this style p_telephone_number_3 N/A for this style
Note: Not all database columns names or API parameters have been listed. The p_style parameter does not exist on the create_gb_person_address API because this API only creates addresses for one style. Not all of the address attributes are used in every style. For example, the region_2 attribute cannot be set for a GB style address. Hence, there is no corresponding parameter on the create_gb_person_address API. When the create_person_address API is called with p_style set to "GB" then p_region_2 must be null. Both interfaces are provided to give the greatest flexibility. If your company only operates in one location, you may find it more convenient to call the address style interface that corresponds to your country. If your company operates in various locations and you want to store the address details using the local styles, you may find it more convenient to call the general API and specify the required style on creation. Refer to comments in each API package header creation script for further details of where other alternative interfaces are provided. See also: User Hooks and Alternative Interface APIs
Warning Values
Warnings are returned using OUT parameters. The names of these parameters ends with _WARNING. In most cases the datatype is boolean. When a warning value is raised, the parameter is set to true. Other values are returned when the datatype is not boolean. Refer to the comments in each API package header creation script for further details.
The API assumes that although a warning situation has been flagged, it is acceptable to continue. If there was risk of a serious data problem, a PL/SQL error would have been raised and processing for the current API call would have stopped. However, in your particular organization you may need to make a note about the warning or perform further checks. If you do not want the change to be kept in the database while this is done, you will need to explicitly roll back the work the API performed. Example When the create_employee API is called, the p_name_combination_warning parameter is set to true when person details already in the database include the same combination of last_name, first_name and date_of_birth.
declare l_name_combination_warning boolean; l_assign_payroll_warning boolean; begin savepoint on_name_warning; hr_employee.create_employee (p_validate => false ... ,p_last_name => 'Bloggs' ,p_first_name => 'Fred' ,p_date_of_birth => to_date('06-06-1964', 'DD-MM-YYYY') ... ,p_name_combination_warning => l_name_combination_warning ,p_assign_payroll_warning => l_assign_payroll_warning ); if l_name_combination_warning then -- Note that similar person details already exist. -- Do not hold the details in the database until it is -- confirmed this is really a different person. rollback to on_name_warning; end if; end;
Note: It would not have been necessary to rollback the API work if the p_validate parameter had been set to true. You should not use our API procedure names for the savepoint names. An unexpected result may occur if you do not use different names.
For a full description of each API, refer to the comments in the package header creation script. For handling API errors in a PL/SQL batch process it is recommended that any messages should be stored in the HR_API_BATCH_MESSAGE_LINES table.
Sample Code
declare -l_rows_processed number := 0; -- rows processed by api l_commit_point number := 20; - Commit after X successful rows l_batch_run_number hr_api_batch_message_lines.batch_run_number%type; l_dummy_line_id hr_api_batch_message_lines.line_id%type; l_address_id per_addresses.address_id%type; l_object_version_number_id per_addresses.object_version_number_id %type; --- select the next batch run number -cursor csr_batch_run_number is select nvl(max(abm.batch_run_number), 0) + 1 from hr_api_batch_message_lines abm; --- select all the temporary 'GB' address rows -cursor csr_tpa is select tpa.person_id , tpa.primary_flag , tpa.date_from , tpa.address_type , tpa.address_line1
, , , , , , , , from where
tpa.address_line2 tpa.address_line3 tpa.town tpa.county tpa.postcode tpa.country tpa.telephone_number tpa.rowid temp_person_addresses tpa tpa.address_style = 'GB';
begin -- open and fetch the batch run number open csr_batch_run_number; fetch csr_batch_run_number into l_batch_run_number; close csr_batch_run_number; -- open and fetch each temporary address row for sel in csr_tpa loop begin -- create the address in the HR Schema hr_person_address_api.create_gb_person_address (p_person_id => sel.person_id ,p_effective_date => trunc(sysdate) ,p_primary_flag => sel.primary_flag ,p_date_from => sel.date_from ,p_address_type => sel.address_type ,p_address_line1 => sel.address_line1 ,p_address_line2 => sel.address_line2 ,p_address_line3 => sel.address_line3 ,p_town => sel.town ,p_county => sel.county ,p_postcode => sel.postcode ,p_country => sel.country ,p_telephone_number => sel.telephone_number ,p_address_id => l_address_id ,p_object_version_number => l_object_version_number ); -- increment the number of rows processed by the api l_rows_processed := l_rows_processed + 1; -- determine if the commit point has been reached if (mod(l_rows_processed, l_commit_point) = 0) then -- the commit point has been reached therefore commit commit; end if; exception when others then --- An API error has occurred -- Note: As an error has occurred only the work in the -- last API call will be rolled back. The -uncommitted work done by previous API calls will not be -affected. If the error is ora-20001 the fnd_message.get -function will retrieve and substitute all tokens for -- the short and extended message text. If the error is -- not ora20001, null will be returned. -hr_batch_message_line_api.create_message_line (p_batch_run_number => l_batch_run_number
,p_api_name
=>
'hr_person_address_api.create_gb_person_address' ,p_status => 'F' ,p_error_number => sqlcode ,p_error_message => sqlerrm ,p_extended_error_message => fnd_message.get ,p_source_row_information => to_char(sel.rowid) ,p_line_id => l_dummy_line_id); end; end loop; -- commit any final rows commit; end;
You can view any errors that might have been created during the processes by selecting from the HR_API_BATCH_MESSAGE_LINES table for the batch run completed, as follows:
select from where order * hr_api_batch_message_lines abm abm.batch_run_number = :batch_run_number by abm.line_id;
If you call this procedure it is your responsibility to pass in valid values, as incorrect values are not rejected. The above procedure should also be called if you want to use Oracle Alert and the APIs.
By using AOL profiles, it is possible to associate a HR security profile with an AOL responsibility. Care should be taken when setting the apps_initialize resp_id parameter to a responsibility associated with a restricted HR security profile. To ensure API validation is not over restrictive, you should only maintain data held within that responsibility's business group. To maintain data in more than one business group in the same database session, use a responsibility associated with an unrestricted HR security profile.
data you have defined, the package procedure you want to call and builds logic to execute your PL/SQL from the specific user hooks. This step is provided to optimize the overall performance of API execution with user hooks. Effectively each API knows the extra logic to perform without needing to check explicitly. As the link between the APIs and the extra logic is held in data, upgrades are easier to support. Where the same API user hooks and parameters exist in the new version, the pre-processor program can be executed again. This process rebuilds the extra code needed to execute your PL/SQL from the specific user hooks without the need for manual edits to Oracle applications or your own source code files. To implement API user hooks: 1. Identify the APIs and user hooks where you want to attach your extra logic. See: Available User Hooks 2. Identify the data values available at the user hooks you intend to use. See: Data Values Available at User Hooks 3. Implement your extra logic in a PL/SQL server-side package procedure. See: Implementing Extra Logic in a Separate Procedure Package 4. Register your extra PL/SQL packages with the appropriate API user hooks by calling the hr_api_hook_call_api.create_api_hook_call API. Define the mapping data between the user hook and the server-side package procedure. See: Linking Custom Procedures to User Hooks 5. Execute the user hook pre-processor program. This validates the parameters to your PL/SQL server-side package procedure and dynamically generates another package body directly into the database. This generated code contains PL/SQL to call the custom package procedures from the API user hooks. See: The API User Hook Preprocessor Program
Before Process Logic Before Process user hooks execute any extra logic before the main API processing logic modifies any data in the database. In this case, the majority of validation will not have been executed. If you implement extra logic from this type of user hook, you must remember that none of the context and data values have been validated. It is possible the values are invalid and will be rejected when the main API processing logic is executed. After Process Logic After Process user hooks execute any extra logic after all the main API validation and processing logic has successfully completed. All the database changes that are going to be made by the API have been made. Any values provided from these user hooks have passed the validation checks. Your extra validation can assume the values provided are correct. If the main processing logic does not finish, due to an error, the After Process user hook is not called. Note: You cannot alter the core product logic, which is executed between the 'Before Process' and 'After Process' user hooks. You can only add extra custom logic at the user hooks. Core Product Logic Core Product Logic is split into a number of components. For tables that can be altered by an API there is an internal row handler code module. These rows handlers are implemented for nearly all the tables in the system where APIs are available. They control all the insert, update, delete and lock processing required by the main APIs. For example, if a main API needs to insert a new row into the PER_ALL_PEOPLE_F table it will not perform the DML itself. Instead it will execute the PER_ALL_PEOPLE_F row handler module. Oracle Applications does not support any direct calls to these internal row handlers, as they do not contain the complete validation and processing logic. Calls are only allowed to the list of supported and published APIs. This list is provided in the Publicly Callable Business Process APIs in Oracle HRMS topic. Any new APIs introduced in the new version of a release will be listed in What's New in Oracle HRMS In each of the row handler modules three more user hooks are available, After Insert, After Update and After Delete. The user hook extra logic is executed after the validation specific to the current table columns has been successfully completed and immediately after the corresponding table DML statement. These row handler user hooks are provided after the DML has been completed for two reasons: All core product validation has been carried out. So you know that the change to that particular table is valid.
For inserts, the primary key value is not known until the row has actually been inserted.
Note: Although the update or delete DML statements may have been executed, the previous - before DML, column values are still available for use in any user hook logic. This is explained in more detail in a later section of this essay. When an API inserts, updates or deletes records in more than one table there are many user hooks available for your use. For example, the create_employee API can create data in up to six different tables. Create Employee API Summary Code Module Structure
In the above diagram, create_employee is the supported and published API. Only three of the internal row handlers have been shown, PER_ALL_PEOPLE_F, PER_PERIODS_OF_SERVICE and PER_ALL_ASSIGNMENTS_F. These internal row handlers must not be called directly. Order of user hook execution: 1st) Create employee API Before Process user hook. 2nd) PER_ALL_PEOPLE_F row handler After Insert user hook. 3rd) PER_PERIODS_OF_SERVICE row handler After Insert user hook. 4th) PER_ALL_ASSIGNMENT_F row handler After Insert user hook. ... last) Create employee API After Process user hook. Note: Core product validation and processing logic is executed between each of the user hooks. When a validation or processing error is detected, processing is immediately aborted by raising a PL/SQL exception. API validation is carried out in each of the separate code modules. For example, when the create_employee API is used, validation logic is executed in each of the row handlers that are executed. Let's assume that a validation check is violated in the PER_PERIODS_OF_SERVICE row handler. The logic defined against the first two user hooks is executed. As a PL/SQL exception is raised, the 3rd and all remaining user hooks for that API call are not executed. Note: When a DateTrack operation is carried out on a particular record, only one row handler user hook is executed. For example, when updating a person record using the DateTrack mode 'UPDATE', only the After Update user hook is executed in the PER_ALL_PEOPLE_F row handler. The published APIs are also known as Business Processes as they perform a business event within HRMS.
From the After Delete user hooks only old values are available with _o suffix style parameter names. The primary key ID value is available with a parameter that does not have the _o suffix. Old values are only made available at the row handler After Update and After Delete user hooks. Old values are NOT available from any of the Before Process, After Process or After Insert user hooks. Wherever the database column name is used, the end of the name may be truncated, to fit the PL/SQL 30 character limit for parameter names. For DateTrack table row handlers, whenever data values are made available from the After Insert, After Update or After Delete user hooks, the provided new and old values apply as of the operation's effective_date. If past or future values are required the custom logic needs to select them explicitly from the database table. The effective_start_date and effective_end_date column and DateTrack mode value are made available. A complete list of available user hooks and the data values provided can be found by executing a PL/SQL script. See: API User Hook Support Scripts
Limitations There are some limitations to implementing extra logic as custom PL/SQL code. Only calls to server-side package procedures are supported. But more than one package procedure can be executed from the same user hook. Custom PL/SQL cannot be executed from user hooks if it is implemented in: Stand alone procedures (not defined within a package) Package functions Stand alone package functions (not defined within a package) Package procedures that have overloaded versions Note: Do not try to implement commit or full rollback statements in your custom PL/SQL. This will interfere with the API processing and will generate an error. When a parameter name is defined it must match exactly the name of a data value parameter that is available at the user hooks where it will be executed. The parameter must have the same datatype as the user hook data value. Any normal implicit PL/SQL data conversions are not supported from user hooks. All the package procedure parameters must be defined as IN, without any default value. OUT and IN OUT parameters are not supported in the custom package procedure. At all user hooks many data values are available. When implementing a custom package procedure every data value does not have to be listed. Only the data values for parameters that are required for the custom PL/SQL need to be listed. A complete list of available user hooks, data values provided and their datatypes can be found by executing a PL/SQL script. See: API User Hook Support Scripts When you have completed your custom PL/SQL package you should execute the package creation scripts on the database and test that the package procedure compiles. Then test that this carries out the intended validation on a test database. Example A particular enterprise requires the previous last name for all married females when they are entered in the system. This requirement is not implemented in the core product, but an implementation team can code this extra validation in a separate package procedure and call it using API user hooks. When marital status is `Married' and sex is `Female', use a PL/SQL exception to raise an error if the previous last name is null. The following sample code provides a server-side package procedure to perform this validation rule.
Create Or Replace Package cus_extra_person_rules as procedure extra_name_checks (p_previous_last_name in varchar2 ,p_sex in varchar2 ,p_marital_status in varchar2 ); end cus_extra_person_rules; / exit; Create Or Replace Package Body cus_extra_person_rules as procedure extra_name_checks (p_previous_last_name in varchar2 ,p_sex in varchar2 ,p_marital_status in varchar2
) is begin -- When the person is a married female raise an -- error if the previous last name has not been -- entered if p_marital_status = 'M' and p_sex = 'F' then if p_previous_last_name is null then dbms_standard.raise_application_error (num => -20999 ,msg => 'Previous last name must be entered for married females' ); end if; end if; end extra_name_checks; end cus_extra_person_rules; / exit;
2000. Oracle specific user hook logic will then be executed first. This will avoid the need to duplicate Oracle's additional logic in the custom logic. There are two other tables that contain data used by the API user hook mechanism, HR_API_MODULES and HR_API_HOOKS. HR_API_MODULES Table The HR_API_MODULES table contains a row for every API code module that contains user hooks. HR_API_MODULES Description Main Columns API_MODULE_ID Unique identifier A code value representing the type of the API code module. API_MODULE_TYPE 'BP' for Business Process APIs - the published APIs. 'RH' for the internal Row Handler code modules. The value depends on the module type. MODULE_NAME For 'BP' the name of the published API, such as CREATE_EMPLOYEE. For 'RH' modules the name of the table, such as PER_PERIODS_OF_SERVICE. HR_API_HOOKS Table The HR_API_HOOKS table is a child of the HR_API_MODULES table. It contains a record for each user hook in a particular API code module. HR_API_HOOKS Main Description Columns API_HOOK_ID Unique identifier API_MODULE_ID Foreign key. Parent ID to the HR_API_MODULES table. API_HOOK_TYPE Code value representing the type of user hook. The API_HOOK_TYPE code represents the type of user hook, as shown in the following table:
User Hook Type After Insert After Update After Delete Before Process After Process API_HOOK_TYPE AI AU AD BP AP
Caution: Data in the HR_API_MODULES and HR_API_HOOKS tables is supplied and owned by Oracle. Oracle also supplies some data in the HR_API_HOOK_CALLS table. Customers must not modify data in these tables. Any changes you make to these tables may affect product functionality and may invalidate your support agreement with Oracle.
Note: Data in these tables may come from more than one source and API_MODULE_IDs and API_HOOK_IDs may have different values on different databases. Any scripts you write must allow for this difference. Full details for each of these tables can be found in the Oracle HRMS electronic Technical Reference Manual (eTRM) available on MetaLink. Example For the example where you want to make sure previous name is entered, the extra validation needs to be executed whenever a new person is entered into the system. The best place to execute this validation is from the PER_ALL_PEOPLE_F row handler After Insert user hook. The following PL/SQL code is an example script to call the create_api_hook_call API. This tells the user hook mechanism that the cus_extra_person_rules.extra_name_checks package procedure should be executed from the PER_ALL_PEOPLE_F row handler After Insert user hook.
declare --- Declare cursor statements -cursor cur_api_hook is select ahk.api_hook_id from hr_api_hooks ahk , hr_api_modules ahm where ahm.module_name = 'PER_ALL_PEOPLE_F' and ahm.api_module_type = 'RH' and ahk.api_hook_type = 'AI' and ahk.api_module_id = ahm.api_module_id; --- Declare local variables -l_api_hook_id number; l_api_hook_call_id number; l_object_version_number number; begin --- Obtain the ID if the PER_ALL_PEOPLE_F -- row handler After Insert API user hook. -open cursor csr_api_hook; fetch csr_api_hook into l_api_hook_id; if csr_api_hook %notfound then close csr_api_hook; dbms_standard.raise_application_error (num => -20999 ,msg => 'The ID of the API user hook was not found' ); end if; close csr_api_hook; --- Tell the API user hook mechanism to call the -- cus_extra_person_rules.extra_name_checks -- package procedure from the PER_ALL_PEOPLE_F row -- handler module 'After Insert' user hook.
-hr_api_hook_call_api.create_api_hook_call (p_validate => false ,p_effective_date => to_date('01-01-1997', 'DD-MM-YYYY') ,p_api_hook_id => l_api_hook_id ,p_api_hook_call_type => 'PP' ,p_sequence => 3000 ,p_enabled_flag => 'Y' ,p_call_package => 'CUS_EXTRA_PERSON_RULES' ,p_call_procedure => 'EXTRA_NAME_CHECKS' ,p_api_hook_call_id => l_api_hook_call_id ,p_object_version_number => l_object_version_number ); commit; end;
In this example, the previous_last_name, sex and marital_status values can be updated. If you want to perform the same checks when the marital_status is changed, then the same validation will need to be executed from the PER_ALL_PEOPLE_F After Update user hook. As the same data values are available for this user hook, the same custom package procedure can be used. Another API hook call definition should be created in HR_API_HOOK_CALLS by calling the create_api_hook_call API again. This time the p_api_hook_id parameter needs to be set to the ID of the PER_ALL_PEOPLE_F After Update user hook.
Caution: It is IMPORTANT that you do not make any direct edits to the generated hook package body. Any changes you make may affect product functionality and may invalidate your support agreement with Oracle. If you choose to make alternations, these will be lost the next time the pre-processor program is run. This will occur when the Oracle install or upgrade scripts are executed. Other developers in the implementation team could execute the preprocessor program. If any changes are required, modify the custom packages or the calling definition data in the HR_API_HOOK_CALLS table. Then rerun the pre-processor program to generate a new version of the hook package body. For example, if you want to stop calling a particular custom package procedure then: 1. Call the hr_api_hook_call_api.update_api_hook_call API, setting the p_enabled_flag parameter to 'N'. 2. Execute the API user hook pre-processor program so the latest definitions are read again and the hook package body is dynamically recreated. If you want to include the call again, then repeat these steps and set the p_enabled_flag parameter in the hr_api_hook_call_api.update_api_hook_call API to 'Y'. If you want to permanently remove a custom call from a user hook then remove the corresponding calling definition. Call the hr_api_hook_call_api.delete_api_hook_call API. Remember that the actual call from the user hook package body will be removed only when the pre-processor program is rerun. Running the Pre-processor Program The pre-processor program can be run in two ways. Execute the hrahkall.sql script in SQL*Plus This creates the hook package bodies for all of the different API code modules. Execute the hrahkone.sql script in SQL*Plus This creates the hook package bodies for just one API code module - one main API or one internal row handler module. An api_module_id must be specified with this script. The required ID values are found in the HR_API_MODULES table. Both the hrahkall.sql and hrahkone.sql scripts are stored in the $PER_TOP/admin/sql operating system directory. Example Continuing the previous example: After the calling definitions and custom package procedure have been successfully created in the database the api_module_id can be found with the following SQL statement:
select api_module_id from hr_api_modules where api_module_type = 'RH' and module_name = 'PER_ALL_PEOPLE_F';
Then execute the hrahkone.sql script. When prompted, enter the api_module_id returned by the SQL statement above. This will generate the hook package bodies for all of the
PER_ALL_PEOPLE_F row handler module user hooks After Insert, After Update and After Delete. Log Report Both pre-processor programs produce a log report. The hrahkall.sql script only lists errors. So if no text is shown after the 'Created on' statement, all the hook package bodies have been created without any PL/SQL or application errors. The hrahkone.sql script outputs a successful comment or error details. If any errors occurred, a PL/SQL exception is deliberately raised at the end of both scripts. This highlights to the calling program that a problem has occurred. When errors do occur the hook package body code may still be created with valid PL/SQL. For example, if a custom package procedure lists a parameter that is not available, the hook package body is still successfully created. No code is created to execute that particular custom package procedure. If other custom package procedures need to be executed from the same user hook, code to perform those calls is still created assuming they pass all the standard PL/SQL checks and validation checks. Attention: It is important that you check these log reports to confirm the results of the scripts. If a call could not be built the corresponding row in the HR_API_HOOK_CALLS table will also be updated. The STATUS column will be set to 'I' for Invalid Call and the ENCODED_ERROR column will be populated with the AOL application error message in the encoded format. The encoded format can be converted into translated text by the following PL/SQL:
declare l_encoded_error varchar2(2000); l_user_read_text varchar2(2000); begin -- Substitute ??? with the value held in the -- HR_API_HOOK_CALLS.ENCODED_ERROR column. l_encoded_error := ???; fnd_message.set_encoded(encoded_error); l_user_read_text := fnd_message.get; end;
It is your responsibility to review and resolve any problems recorded in the log reports. Options: Alter the parameters in the custom package procedures. If required, change the data defined in the HR_API_HOOK_CALLS table. When you have resolved any problems, rerun the pre-processor program. The generated user hook package bodies must be less than 32K in size. This restriction is a limit in PL/SQL. If you reach this limit, you should reduce the number of separate package procedures called from each user hook. Try to combine your custom logic into fewer procedures. Note: Each linked custom package procedure can be greater than 32K in size. Only the user hook package body that is dynamically created in the database must be less than 32K. One advantage of implementing the API user hook approach is that your extra logic is called every time the APIs are called. This includes any HRMS Forms or Web pages that perform their processing logic by calling the APIs.
Attention: The user hook mechanism that calls your custom logic is supported as part of the standard product. However the logic in your own custom PL/SQL procedures cannot be supported by Oracle Support.
Data values provided at the Before Process and After Process user hooks will be the same as the values passed into the API. For update type business processes the API caller has to specify only the mandatory parameters and the values they actually want to change. When the API caller does not explicitly provide a parameter value, the system reserved default values will be used, as shown in the vollowing table:
Data Type varchar2 number date Default Value hr_api.g_varchar2 hr_api.g_number hr_api.g_date
Depending on the parameters specified by the API caller, these default values may be provided to Before Process and After Process user hooks. That is, the existing column value in the database is only provided if the API calling code happens to pass the same new value. If the real database value is required then the custom package procedures must select it explicitly from the database. This is another reason why After Update and After Delete user hooks are preferred. At the row handler user hooks the actual data value is always provided. Any system default values will have been reset with their existing database column value in the row handler modules. Any extra logic from these user hooks does need to be concerned with the system reserved default values. If any After Process extra logic must access the old database values then a different user hook needs to be used. It will not be possible to use the After Process user hook because all the relevant database rows will have been modified and the old values will not be provided by the user hook mechanism. Where API specific extra logic requires the old values, they will need to be explicitly selected in the Before Process user hook. User Hooks and Alternative Interface APIs Alternative Interface APIs provide an alternative version of the generic APIs. Currently there are legislative or vertical specific versions of the generic APIs. For example, create_us_employee and create_gb_employee are two alternative interfaces to the generic create_employee API. These alternatives make clear how specific legislative parameters are mapped onto the parameters of the generic API. In the future other alternative APIs may be provided to support specific implementations of generic features, such as elements and input values. Attention: User hooks are not provided in alternative interface APIs. User hooks are provided only in the generic APIs. In this example the user hooks are provided in the create_employee API and not in the create_us_employee and create_gb_employee APIs. Alternative interface APIs always perform their processing by executing the generic API and any extra logic in the generic API user hooks is executed automatically when the alternative APIs are called. This guarantees consistency in executing any extra logic and reduces the administrative effort to set up and maintain the links. Example 1 You want to perform extra validation on the job and payroll components of employee assignments to make sure only `Machine Workers' are included in the `Weekly' payroll.
There is more than one published API that allows the values to be set when a new assignment is created or an existing assignment is updated. Suggestion: Implement the extra validation in a custom server-side package procedure. Link this to the two user hooks, After Insert and After Update, in the PER_ALL_ASSIGNMENTS_F table internal row handler module. Example 2 You have a custom table and you want to create data in this table when a new employee is created in the system, or an existing applicant is converted into an employee. The data in the custom table does not need to be created in any other scenario. Suggestion: Implement the third party table; insert DML statements in a custom server-side package procedure. Link this to two user hooks: After Process in the create_employee API module and After Process in the hire_applicant API module.
current DateTrack operation. The last day the record is affected is known as the validation_end_date.
With API user hooks it is not possible to change any of the data values. So the building block approach can be used to default or set any values before the published API is called.
The major disadvantage with the building block approach is that any Forms or Web pages supplied by Oracle will NOT call any custom APIs. If a user interface is required then you must also create your own custom Forms or Web pages to implement calls to your custom APIs.
2. The user presses commit. Row A has no user errors and is validated in the API. The OVN is updated in the database and the new OVN is returned to the form.
Row A B OVN in Database 7 3 7 3 OVN in Form
3. The form calls the API again for row B. This time there is a validation error on the user-entered change. An error message is raised in the form and Forms issues a rollback to the database. However, the OVN for row A in the form is now different from the OVN in the database.
Row A B OVN in Database 6 3 7 3 OVN in Form
4. The user corrects the problem with row B and commits again. Now the API will error when it validates the changes to row A. The two OVNs are different. Solution The solution to this problem is to use a non-basetable item to hold the new version number. This item is not populated at query time. 1. The user queries two rows and updates both.
Row A B OVN in Database 6 3 6 3 OVN in Form New_OVN in Form
2. The user presses commit. Row A is valid, so the OVN is updated in the database and the new OVN is returned to the form. Note: The actual OVN in the form is not updated.
Row OVN in Database OVN in Form New_OVN in Form
A B
7 3
6 3
3. The forms calls the API again for row B. The validation fails and an error message is raised in the form. Forms issues a rollback to the database.
Row A B OVN in Database 6 3 6 3 OVN in Form 7 New_OVN in Form
4. The user corrects the problem with row B and commits again. The API is called to validate row A again. The OVN value is passed, not the NEW_OVN. There is no error because the OVN in the database now matches the OVN it was passed. The API passes back the updated OVN value.
Row A B OVN in Database 7 3 6 3 OVN in Form 7 New_OVN in Form
5. The API is called again to validate row B. The validation is successful; the OVN is updated in the database and the new OVN value is returned to the form. The commit in the form and the database is successful.
Row A B OVN in Database 7 4 6 3 OVN in Form 7 4 New_OVN in Form
What would happen when the user updates the same row again without re-querying? Following on from the previous step: 6. When the user starts to update row A, the on-lock trigger will fire. The trigger updates the OVN when New_OVN is not null. (Theoretically the on-lock trigger will only fire if the previous commit has been successful. Therefore the New_OVN is the OVN value in the database.)
Row A OVN in Database 7 7 OVN in Form 7 New_OVN in Form
7. The on-lock trigger then calls the API to take out a lock using OVN. The lock is successful as the OVN values match.
Row A OVN in Database 7 7 OVN in Form 7 New_OVN in Form
8. The user continues with the update, the update API is called, and the commit is successful.
Row A OVN in Database 8 7 OVN in Form 8 New_OVN in Form
If user does delete instead of update, the on_lock will work in the same way. When key_delrec is pressed, the delete API should be called with p_validate set to true. Doing so ensures that the delete is valid without removing the row from the database. Therefore, the OVN value in the form should be set with the New_OVN, when New_OVN is not null. This ensures that the delete logic is called with the OVN value in the database. However, there is another special case that has to be taken into consideration. It is possible for the user to update a row (causing a new OVN value to be returned from the API), the update of the next row in the same commit unit fails, the user navigates back to
the first row and decides to delete it. To stop the new_OVN from being copied into the OVN in the form, only do the copy in key_delrec if the record_status is query. Example Code Using the Grade Rate Values The above descriptions are handled in the following example. In this example, <block_name>.object_version_number is a basetable item and <block_name>.new_object_version_number is non-basetable. Forms Procedure Called from the ON-INSERT Trigger
procedure insert_row is begin --- Call the api insert routine -hr_grade_api.create_grade_rate_value (<parameters> ,p_object_version_number => :<block_name>.object_version_number ,p_validate => false ); end insert_row;
l_rec_status varchar2(30); begin -- Ask user to confirm they really want to delete this row. --- Only perform the delete checks if the -- row really exists in the database. -l_rec_status := :system.record_status; if (l_rec_status = `QUERY') or (l_rec_status = `CHANGED') then --- If this row just updated then the -- new_object_version_number will be not null. -- If that commit was successful then the -- record_status will be QUERY, therefore use -- the new_object_version_number. If the commit -- was not successful then the user must have -- updated the row and then decided to delete -- it instead. Therefore just use the -- object_version_number. --(Cannot just copy the new_ovn into ovn -- because if the new_ovn does not match the -- value in the database the error message will -- be displayed twice. Once from key-delrec and -- again when the on-lock trigger fires.) -if (:<block_name>.new_object_version_number is not null) and (l_rec_status = 'QUERY') then l_api_ovn := :<block_name>.new_object_version_number; else l_api_ovn := :<block_name>.object_version_number; end if; --- Call the api delete routine in validate mode -hr_grade_api.delete_grade_rate_values (p_validate => true ,<parameters> ,p_object_version_number => l_api_ovn ,p_validate => true ); end if; -delete_record; end key_delrec_row;
:<block_name>.new_object_version_number is not null then :<block_name>.object_version_number := :<block_name>.new_object_version_number; end if; --- Call the table handler api lock routine -pay_grr_shd.lck (<parameters> ,p_object_version_number => :<block_name>.object_version_number ); return; EXCEPTION When APP_EXCEPTIONS.RECORD_LOCK_EXCEPTION then APP_EXCEPTION.Record_Lock_Error(l_counter); END; end LOOP; end lock_row;
----if
That commit unit must have been successful for the on_lock trigger to fire again, so use the new_object_version_number.