Search Results okc_datatypes




Overview
Explore in AI Chat

Overview

OKS_CONTRACT_SLL_PUB is a public PL/SQL package in the APPS schema that supports the management of service line levels (SLL) within Oracle Service Contracts (OKS) in Oracle E-Business Suite 12.1.1 and 12.2.2. In the Service Contracts data model, a service line level defines the hierarchical position or tiering of a contract line—for example, a header level, line level, or a sub-line level used to group and structure contract coverage, pricing, and entitlement. The SLL public package exposes procedures for creating, maintaining, validating, and removing these stream level definitions and their associated contract data.

The package acts as a thin public API layer over the internal private package OKS_SLL_PVT. The "_PUB" suffix indicates that it is an officially published, callable interface intended for use by forms, concurrent programs, and external integration code, in contrast to the "_PVT" private implementation that holds the core business logic. It follows the standard EBS API conventions by delegating to FND_API for message handling and by leveraging OKC_API and OKC_DATATYPES, the public API and datatype specification packages of Oracle Contracts Core (OKC).

Key Procedures and Functions

The documented interface exposes sixteen public procedures and functions. The principal procedures are:

  • CREATE_SLL — Creates a new service line level definition and its associated record in the contracting structure.
  • LOCK_SLL — Obtains a lock on an existing service line level record to prevent concurrent modification during an update or delete operation.
  • UPDATE_SLL — Modifies attributes of an existing service line level.
  • DELETE_SLL — Removes a service line level record when it is no longer required.
  • VALIDATE_SLL — Performs business-rule validation against supplied values. It typically returns a validity flag and an outcome message, and is often called before create, update, or delete operations to surface errors through the FND_API message stack.
  • INSERT_ROW_UPG — An upgrade-support routine that inserts rows during data migration or version upgrade processing.

These routines mirror the CRUD pattern common to EBS public APIs: a validate step for checking inputs, and create, lock, update, and delete steps for persistence. Although sixteen procedures and functions are catalogued, the excerpt above documents the primary public entry points; the remaining routines support the same lifecycle and internal delegation to OKS_SLL_PVT. Parameter lists are intentionally omitted here because the metadata does not enumerate them, and exact signatures must be confirmed against the database package specification.

Tables Accessed

The package references two tables through APPS synonyms:

  • OKS_STREAM_LEVELS_B — The base table that stores service line level definitions. The API reads, inserts, updates, and deletes rows here as part of the SLL lifecycle.
  • PLITBLM — A standard EBS PL/SQL associative-array (index-by table) type utility used internally for array handling; it does not represent a persistent business table.

The package also depends on OKC_API, OKC_DATATYPES, FND_API, and OKS_SLL_PVT. OKC_DATATYPES supplies the standard record and table type definitions shared across the Contracts family, ensuring consistent structures between the public package and OKC core.

Usage Notes

OKS_CONTRACT_SLL_PUB is typically invoked by the Service Contracts user interface—particularly the contract authoring and line-level setup forms—where service line levels must be created and maintained. It is also the correct integration point for custom code, interfaces, and concurrent programs that need to manipulate service line levels programmatically, since calling the supported _PUB API preserves validation and messaging behavior.

Callers should invoke VALIDATE_SLL before committing, use LOCK_SLL to serialize concurrent updates, and check the FND_API return status and message stack to handle errors. Because OKS_CONTRACT_SLL_PUB is itself referenced by two other packages, changes to its behavior can ripple into dependent components, so it should be treated as a stable interface. Development should target the public package rather than the private OKS_SLL_PVT implementation to remain upgrade-safe.