Search Results update_class

Overview

OKC_CLASS_PUB is the public application programming interface for managing class definitions within the Oracle Contracts (OKC) module of Oracle E-Business Suite. In EBS 12.1.1 and 12.2.2, the Contracts application relies on a class framework to categorize and organize contract templates, contract terms, and related artifacts. The OKC_CLASS_PUB package exposes this class-management functionality to external callers, including Oracle Forms, concurrent programs, and custom PL/SQL code, while delegating the actual business logic and data manipulation to the private package OKC_CLASS_PVT.

The package is declared with AUTHID CURRENT_USER, meaning its unqualified database references resolve under the privileges of the invoking schema rather than the package owner. This design choice supports the standard EBS APIs layered-security model, in which the APPS schema owns the package and a runtime user context governs data access. The header identifies the package revision as 120.0, which corresponds to a stable, long-lived interface used across the 11i and R12 release families.

Key Procedures and Functions

The documented interface contains eleven callable entry points, organized primarily around paired overloads for single-record and multi-record (table) operations. The principal procedures are:

• ADD_LANGUAGE — Loads translated language rows for the class entities, supporting Oracle's multi-language (MLS) architecture by populating the corresponding _TL tables for supported languages.
• INSERT_CLASS — Creates one or more new class definitions. It is overloaded to accept either a single class record (clsv_rec_type) or a collection of class records (clsv_tbl_type), returning the created records with any system-populated attributes.
• LOCK_CLASS — Acquires a pessimistic lock on one or more existing class definitions to prevent concurrent modification. As with insert, it is overloaded for single-record and table-based invocation.
• UPDATE_CLASS — Modifies existing class definitions. This is the API of interest for the "update_class" search. It is overloaded for single-record and multi-record updates and returns the updated class records to the caller.
• DELETE_CLASS — Removes class definitions that are no longer required, subject to the referential and business validations enforced by the private package.
• VALIDATE_CLASS — Performs pre-operation validation of class data without persisting changes, allowing callers to detect errors before committing to an insert or update.

All procedures follow the EBS API conventions: a p_api_version input for interface versioning, p_init_msg_list to control message-stack initialization, and the standard x_return_status, x_msg_count, and x_msg_data output parameters for error reporting.

Tables Accessed

The ETRM metadata for this object does not enumerate specific base tables; the package operates through APPS synonyms. Consistent with the OKC_CLASS_PVT implementation, the primary objects are the OKC_CLASSES base table and its associated translation table, OKC_CLASSES_TL. The public package indirectly reads and writes these tables via the private layer, which also references related lookup and reference tables that define class types and categories. Because the metadata lists no explicit table mapping, integrators should treat the base and translation tables as the authoritative data stores for class records.

Usage Notes

OKC_CLASS_PUB is typically invoked in three contexts. First, Oracle Forms in the Contracts module call the API during class maintenance to create, update, and delete class definitions through the standard UI. Second, concurrent programs and batch processes use the table-based overloads to process multiple class records in a single call, improving efficiency for bulk operations. Third, custom extensions and integrations invoke the API when programmatically managing contract classes. The ETRM metadata indicates the package is referenced by zero other packages, so it is a leaf-level public interface rather than a shared internal dependency.

Callers should always initialize the message list, check x_return_status after every call, and invoke the API within a properly managed transaction. Because AUTHID CURRENT_USER is in effect, the invoking session must have the necessary object privileges on the underlying synonyms. The presence of the ADD_LANGUAGE procedure confirms that installations using additional languages must run language installation routines to keep the translation table synchronized.