Search Results lock_trx_requests

Overview

OKL_TRX_REQUESTS_PUB is the public application programming interface for transaction requests within the Oracle Lease and Finance Management (OLFM) module of Oracle E-Business Suite. The package is owned by APPS and classified as a PUB API, meaning it is intended for external invocation by other application modules, extension code, and integration components rather than for internal use only. Its central responsibility is the management of transaction request records — the intermediate artifacts that capture, validate, and stage financial transactions before final processing within the leasing transaction lifecycle.

The package operates as a thin public wrapper over the private implementation package OKL_TRQ_PVT. It re-exports the PL/SQL record and table types trqv_rec_type and trqv_tbl_type through subtype declarations, allowing callers to work with single-record and bulk (table-based) transaction request structures without referencing the private package directly. A standard API framework is employed throughout: every procedure observes the p_api_version and p_init_msg_list conventions, returns x_return_status, x_msg_count, and x_msg_data, and relies on the OKL_API utility package for message handling and error reporting. Two standard error tokens, G_SQLERRM_TOKEN and G_SQLCODE_TOKEN, plus the application-wide G_UNEXPECTED_ERROR constant, support consistent exception translation. A package-level exception, G_EXCEPTION_HALT_VALIDATION, signals validation failures that must terminate processing.

Key Procedures and Functions

The documented API surface consists of five procedures, each provided in single-record and/or bulk table form:

• INSERT_TRX_REQUESTS — Creates new transaction request records. Overloaded variants accept either a single trqv_rec_type record or a trqv_tbl_type collection, returning the created record(s) with any system-populated attributes.
• LOCK_TRX_REQUESTS — Acquires a pessimistic lock on one or more transaction request records. Invoking this procedure protects a record from concurrent modification between the time it is read and the time it is updated or deleted, which is the standard mechanism callers use to enforce optimistic concurrency control on transaction requests.
• UPDATE_TRX_REQUESTS — Modifies existing transaction request records, applying changed attributes supplied by the caller.
• DELETE_TRX_REQUESTS — Removes transaction request records that are no longer required.
• VALIDATE_TRX_REQUESTS — Performs business-rule validation against transaction request data without persisting changes, allowing callers to detect errors before insert, update, or delete operations are attempted.

Tables Accessed

The package accesses transaction request data through APPS synonyms, most directly the OKL_TRX_REQUESTS table family, which stores the transaction request header information manipulated by these APIs. The documented table reference PLITBLM is the standard EBS temporary/PLSQL table used in bulk-processing paths, where collections are bound and processed in set-based fashion to improve performance for multi-record operations. All reads and writes occur under the APPS schema through the package's AUTHID CURRENT_USER declaration.

Usage Notes

OKL_TRX_REQUESTS_PUB is typically invoked from OLFM transaction entry forms, from concurrent programs that batch-process transaction requests, and from custom extension code or integration interfaces that need to create, maintain, or validate transaction requests programmatically. Callers should always check x_return_status after each invocation and inspect the message stack via x_msg_count and x_msg_data when errors are reported. Because the package is referenced by ten other packages, customizations should treat its signatures as a stable contract. Typical usage follows the pattern of validating, locking, then updating or deleting, ensuring that concurrent users cannot overwrite each other's changes.