Search Results okl_trx_requests_pub




Overview
Explore in AI Chat

Overview

The APPS.OKL_TRX_REQUESTS_PUB package body is a public (PUB-classified) API within the Oracle E-Business Suite Lease Management (OKL) module, part of the Enterprise Transaction Management (ETRM) application family. Its purpose is to expose a controlled, validated interface for managing lease transaction request records. In Oracle EBS 12.1.1 and 12.2.2, this package acts as the transactional entry point for creating, modifying, locking, validating, and removing rows associated with lease transaction requests, which underpin the origination and restructuring of lease contracts.

The package follows the standard EBS layered API architecture. As a PUB package, it provides an externally callable interface, delegating core business logic to the private layer, OKL_TRQ_PVT. This separation allows Oracle to change internal processing while preserving a stable public contract for customer extensions and integrations. The body is stored in the APPS schema and is currently VALID. Notably, the ETRM metadata records that OKL_TRX_REQUESTS_PUB is not referenced by any database object, indicating it sits at the top of the dependency chain and is intended for external invocation rather than internal reuse.

Key Procedures and Functions

The documented public interface contains ten procedures and functions, organized primarily around the five core DML and validation operations:

  • INSERT_TRX_REQUESTS — Creates new transaction request records, applying API-level defaults and validation before the record is persisted.
  • LOCK_TRX_REQUESTS — Acquires a lock on one or more transaction request records to prevent concurrent modification during a transaction.
  • UPDATE_TRX_REQUESTS — Modifies the attributes of existing transaction requests, respecting the same validation rules applied on insert.
  • DELETE_TRX_REQUESTS — Removes transaction request records, subject to the business rules enforced by the underlying private package.
  • VALIDATE_TRX_REQUESTS — Performs validation checks against the supplied request data without committing changes, allowing callers to verify data integrity before performing DML.

The remaining documented entry points are overloads or supporting routines that extend these five operations. Parameter lists are intentionally omitted here because the metadata does not enumerate them; callers should consult the package specification in the database for exact signatures. All procedures return status and message information consistent with the FND_API error-handling convention.

Tables Accessed

The ETRM metadata documents one table reference via an APPS synonym: PLITBLM, the PL/SQL table type used for message handling. This is a technical dependency rather than a business table; it supports the standardized message stack used to return errors and warnings to callers. The substantive lease transaction request data manipulation is not performed directly against base tables by this public package. Instead, the body depends on OKL_TRQ_PVT, the private package that holds the actual SQL statements and business logic. Consequently, the public body remains thin, delegating record-level reads and writes to the private layer while it manages locking, validation sequencing, and message propagation.

Usage Notes

OKL_TRX_REQUESTS_PUB is typically invoked from the Lease Management application forms, from concurrent programs that process lease transaction requests in batch, and from custom PL/SQL integrations that must populate or maintain transaction request data in a supported manner. Because the body depends on FND_API, FND_MSG_PUB, OKL_API, and OKL_TRQ_PVT, callers should initialize the FND message stack and check the returned API status before committing.

Direct DML against the underlying lease tables should be avoided in favor of this API so that validation, locking, and message handling remain consistent with Oracle's supported behavior. Because the package is referenced by ten other packages but depends on none at the public level, it is suitable as a stable integration surface. As with all EBS public APIs, developers should obtain the current package specification from the target instance before coding calls, since parameter signatures may vary between 12.1.1 and 12.2.2 releases.