Search Results lock_act_atts

Overview

OKC_ACTIONS_PUB is the public application programming interface for managing contract actions and contract action attributes within the Oracle Contracts (OKC) module of Oracle E-Business Suite. Contract actions represent the discrete steps and tasks associated with a contract's lifecycle — for example, approval routing, signature capture, fulfillment tracking, or renewal activities. The package exposes a controlled, validated set of procedures by which forms, concurrent programs, and custom extensions can create, update, lock, validate, and delete action records and their associated attribute rows without writing directly to the underlying base tables.

The package is classified as a PUB API within ETRM, indicating that its procedures constitute a supported interface intended for external invocation. It builds on the private implementation packages OKC_ACN_PVT and OKC_AAE_PVT, from which it derives the acnv_rec_type, acnv_tbl_type, aaev_rec_type, and aaev_tbl_type subtypes used to pass action and action-attribute data in and out of the API. The package also declares the standard set of OKC_API global message constants (such as G_REQUIRED_VALUE, G_INVALID_VALUE, G_RECORD_CHANGED, and G_RECORD_LOGICALLY_DELETED) and exposes G_EXCEPTION_HALT_VALIDATION, which callers can raise to abort processing when validation logic fails.

Key Procedures and Functions

The documented interface comprises twenty-five procedures and functions, grouped as follows:

• Action-level operations: CREATE_ACTIONS inserts new contract action records; UPDATE_ACTIONS modifies existing actions; DELETE_ACTIONS removes them; VALIDATE_ACTIONS performs the business-rule checks that must precede a commit; and LOCK_ACTIONS obtains the record-level lock required to guard against concurrent modification.
• Action-attribute operations: CREATE_ACT_ATTS, UPDATE_ACT_ATTS, DELETE_ACT_ATTS, VALIDATE_ACT_ATTS, and LOCK_ACT_ATTS perform the equivalent lifecycle operations for the attribute rows attached to an action. LOCK_ACT_ATTS is the specific entry point associated with the lock_act_atts search term, and is used to reserve action-attribute records for update.
• Language maintenance: ADD_LANGUAGE inserts translated (MLS) rows for action and attribute data, supporting multi-language deployments.

All procedures follow the standard OKC API convention of accepting record or table-type collections plus a p_return_status output parameter that returns G_RET_STS_SUCCESS or an error status, with the corresponding message and token values returned through accompanying message parameters. No parameter signatures are invented here; refer to the package specification for exact argument lists.

Tables Accessed

According to the ETRM metadata, OKC_ACTIONS_PUB accesses the table PLITBLM through an APPS synonym. PLITBLM is the standard Oracle Application Object Library table used to hold runtime message and token values, and is referenced here to surface the validation and error messages generated by the API's business rules (for example, required-value or invalid-value feedback). The action and action-attribute base tables themselves are not listed in the documented table references; the package delegates that DML to its private implementation dependencies, OKC_ACN_PVT and OKC_AAE_PVT, whose record types are re-exported as public subtypes.

Usage Notes

OKC_ACTIONS_PUB is typically invoked from the Oracle Contracts forms (such as the contract authoring and actions user interfaces) in response to user actions — creating an action, editing action attributes, or saving the form — and from concurrent programs and custom PL/SQL extensions that need to maintain action data programmatically. The canonical calling pattern is: validate, then lock (via LOCK_ACTIONS or LOCK_ACT_ATTS), then perform the create, update, or delete, and finally commit in the caller's transaction. The presence of the lock procedures reflects the standard EBS optimistic-locking model: the API checks the OBJECT_VERSION_NUMBER of the row and raises G_FORM_RECORD_CHANGED if another session has modified it in the interim.

Custom code should always write through this published API rather than against OKC_ACN_PVT/OKC_AAE_PVT directly, since only the PUB layer guarantees the full set of validation, locking, MLS handling, and message propagation. The metadata indicates the package is referenced by one other documented package, confirming its role as an upstream dependency in the OKC call chain. In 12.1.1 and 12.2.2 the source header shows an unchanged generation, suggesting the interface has been stable across these releases.