Search Results okc_api




Overview
Explore in AI Chat

Overview

OKC_API is the core public API package body for the Oracle Contracts (OKC) module in Oracle E-Business Suite, delivered in the APPS schema. It provides the foundational runtime services used throughout the contract authoring, servicing, and lifecycle stack, including message list initialization, exception handling, activity framing for the FND logging and message infrastructure, and resolution of contract-related message tokens. Because OKC_API is classified as an API and is referenced by 1,768 other packages, it functions as a shared utility layer rather than a business-transaction entry point. Its dependency footprint — FND_API, FND_MESSAGE, FND_MSG_PUB, FND_PROFILE, DBMS_TRANSACTION, and STANDARD — confirms its role in standardizing the Oracle Application Object Library error-handling and messaging conventions across the Contracts family of modules. The package is marked VALID in the ETRM 12.2.2 metadata set and behaves consistently across the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The documented program units (11 total) fall into three functional groups:

  • Message infrastructure: INIT_MSG_LIST initializes the message list for a calling process. SET_MESSAGE records an application or error message for eventual retrieval. RESOLVE_MESSAGE resolves a stored message token into its runtime text. These routines wrap FND_MSG_PUB and FND_MESSAGE behavior for Contracts-specific usage.
  • Activity framing and exception control: START_ACTIVITY and END_ACTIVITY bracket a unit of work for consistent logging and error propagation. HANDLE_EXCEPTIONS centralizes exception inspection and message publishing so that calling APIs share a single error-handling contract. These are the routines most commonly invoked by dependent OKC packages.
  • Token and contract-type resolution: RESOLVE_HDR_TOKEN and RESOLVE_DEL_TOKEN resolve header-level and detail/line-level message tokens respectively, supporting context-rich error text. GET_CONTRACT_TYPE and GET_CONTRACT_TYPE_UI_FUNC retrieve contract type and the associated user-interface function, allowing callers to determine UI navigation targets without querying base tables directly.

Parameter lists should be obtained from the live package specification on the target instance, as they are not exhaustively enumerated in the ETRM extract.

Tables Accessed

Three objects are documented as referenced through APPS synonyms:

  • OKC_BUS_DOC_TYPES_B — the business document type base table, queried to resolve contract type definitions and associated UI behavior for GET_CONTRACT_TYPE and GET_CONTRACT_TYPE_UI_FUNC.
  • OKC_REP_CONTRACTS_ALL — the repository of contracts accessible to the current organization, used to resolve contract header and detail tokens for message construction.
  • DBMS_TRANSACTION — a PUBLIC package rather than a table; typically used to set local transaction context (for example, rollback markers) when handling exceptions, ensuring message state remains consistent with the caller's transaction boundaries.

Usage Notes

OKC_API is generally not called from Oracle Forms or concurrent programs directly. Instead, it is invoked as a shared dependency by the higher-level Contracts APIs and by any custom code that must conform to standard OKC error reporting. The typical invocation pattern is: initialize the message list, start an activity, execute work, resolve any tokens needed for user-facing messages, call the appropriate handler on exception, then end the activity.

Because the package is referenced by 1,768 other packages and references no external objects beyond the three listed above, any modification carries broad regression risk. Customizations should wrap rather than alter OKC_API. When diagnosing Contracts errors, inspecting the message list populated by SET_MESSAGE and RESOLVE_MESSAGE is the recommended first step, since virtually all OKC entry-point APIs route their error text through this package. Confirm procedure signatures against the package specification on the specific instance, as the ETRM extract does not include parameter detail.