Record Reservation Related Business Functions in EnterpriseOne

Purpose of Document

The purpose of Record Reservation is to maintain higher integrity by preventing other users/processes from accessing a certain table simultaneously by recording data into the F00095 - Business Object Reservation table. By implementing this constraint, two different processes do not compete to update/delete a certain table at the same time.

This document is to explain how EnterpriseOne applications make use of user record reservation across the system.

If there is any application which has to update critical information, record reservation routine will take place. This routine comes in Update Mode of the entry point of a transaction or in an application which updates any transaction created by another application.

A simple rule is to determine the target table and get the primary key of it (or primary key of header file) along with the application ID (or UKID).

For further details, review how the table F00095 is structured and how each business function can be implemented in a certain update routine.

This document is for the EnterpriseOne developer and system administrator for the purpose of:

• to understand how standard applications reserve records
• to implement custom applications which do not hurt standard routines

Table F00095 Layout

This table behaves like a work file, so the value inserted through the reservation will be removed at the end of the transaction. If needed, it may be necessary to truncate the table on a regular basis.

Business Functions that can be Called to Reserve a Record

Below are detail configuration of individual Business Functions.

N0000604 - ValidateApplicationId (Validate Application Id - Business Object Reservation Application Id Validation)

• Purpose: To determine whether to reserve record into F00095 or not
• Parameters
• Data Structure: D0000604A - Business Object Reservation Application Id Validation

X00022 - GetNextUniqueKeyID (Get Next Unique Key ID) (Optional)

• Purpose: To get unique key ID (F00022.UKID) against RRESERVE or a specific application ID. The reason for this implementation is that this new UKID will be used rather than program ID to prevent the same user from committing the same record multiple times
• Parameters
• Data Structure: DX00022A - Get Next Unique Key ID

N0000602 - F00095ReserveObject (F00095 Reserve Object)

• Purpose: To verify whether a specific record is reserved by and/or write a specific record into F00095
• Parameter
• Data Structure

• Detail routine
• Detail routine based on cModeOfProcessing
• - Interactive applications
• 1 - The 1st UBE (calling) from 2 cycle process UBEs
• 2 - The 2nd UBE from 1st (called) from 2 cycle process UBEs
• 3 - Single cycle UBEs

Case (cModeOfProcessing = 2): This is record reservation for called report so F00095 has to be written in running 1st calling UBE for 2nd UBE. So this mode is checking whether the object is reserved by composite key based on Input szGenericKey with szJobNumber and szComputerID.

Case (cModeOfProcessing = IN (1, 3, )): When N0000602 is called from interactive applications.

Case (cModeOfProcessing =  1 ): The 1st UBE (calling) from 2 cycle process UBEs which writes F00095 twice to secure transaction of calling and called UBE and 2nd insert will take place as below

B0000603 - SetReservationError (Set Object Reservation Text Substitution Error)

• Purpose: This function is to give more descriptive error message. Depends on input parameter cSuppressErrorMessage this function can be called from N0000602.
• Parameter
• Data Structure: D0000603

N0000602 - F00095RemoveReservation (F00095 Remove Business Object Reservation)

• Purpose: This function performs multiple deletion scenarios from the F00095 table based on the values passed into the function. Only the values required to control the desired delete should be passed in as parameters. Passing in extra values may result in an undesirable delete scenario being performed.
• Parameter
• Data Structure: D0000602B

• Sequence of deletion:
• If specific object and key is given only remove all reservations having that object/key (based on F00095.OBNM = szNameObject AND F00095.GENKEY = szGenericKey)
• Otherwise if object, user and application are provided remove all reservation records having that object/user/application (Based on F00095.OBNM = szNameObject AND F00095.USER = szUserId AND F00095.PID = szApplication)
• Otherwise if the user is specied but not the application and generic key remove all reservations for the user (F00095.USER = szUserId

For actual implementation, review :

• <Document 1142464.1> - E1: FDA: F00095 Record/Object Reservation in EnterpriseOne Interactive Application
• <Document 1145943.1> - E1: RDA: F00095 Record/Object Reservation in EnterpriseOne Batch Application

 Other business functions which makes use of above functions

Since record reservation routine is written as event rule for a certain application. Commonly, reservation takes place at Post Dialog Is Initialized event and remove occurs at Post Commit event. In case power edit or additional routine takes place then below business functions can be called to isolate a certain transaction from extended function/application.

Though it has individual business function as below overall routine is more or less same with basic business function described above. This is natural based on the way Reserve and Remove functions get called from application.