Search Results cs_kb_histories_s

Overview

The APPS.CS_KB_HISTORIES_PKG package body is a server-side PL/SQL API belonging to the Oracle E-Business Suite Customer Service (Service) application. It encapsulates the business logic that governs the creation, maintenance, and multilingual handling of knowledge base history records. In the Oracle EBS schema architecture, the package body implements the specification declared in CS_KB_HISTORIES_PKG and serves as the single programmatic entry point for inserting, updating, deleting, locking, and translating rows within the knowledge base histories entity. By centralizing these operations, the package enforces consistent validation, concurrency control, and translation management across all callers, whether they originate from Oracle Forms, concurrent programs, or custom extensions. The object is documented with a status of VALID in the APPS schema and is classified as an OTHER API type within the ETRM (E-Business Suite Technical Reference Manual) metadata. It is a foundational component of the Knowledge Base feature set, which records the lifecycle and change history of knowledge articles managed by service agents.

Key Procedures and Functions

The package body exposes eight documented program units, each addressing a specific operation against the histories entity:

• CREATE_HISTORY — Creates a new history record, applying the package's defaulting and validation rules before persisting the row. This is the primary business-facing entry point for generating history entries.
• INSERT_ROW — Performs the low-level physical insert into the base table, supporting the row-level DML that underlies CREATE_HISTORY and direct API callers.
• UPDATE_ROW — Modifies existing history rows, typically used to adjust descriptive or translated attributes while preserving the record's identity.
• DELETE_ROW — Removes a history row at the table level, complementing the higher-level DELETE_HISTORY operation.
• DELETE_HISTORY — Provides the business-level deletion of a history record, including any associated cleanup logic required by the entity.
• LOCK_ROW — Acquires a row-level lock to serialize concurrent access and protect against lost updates during multi-user editing.
• ADD_LANGUAGE — Inserts translation rows for additional languages, enabling a single history record to be represented in multiple installed languages.
• TRANSLATE_ROW — Populates or updates the translated (TL) attributes of a history row for a given language context.

Parameter lists are intentionally omitted here; the documented metadata confirms procedure names and purposes only.

Tables Accessed

The package operates against the following objects, referenced through APPS synonyms:

• CS_KB_HISTORIES_B — The base table holding the primary, language-independent attributes of each history record.
• CS_KB_HISTORIES_TL — The translation table storing language-specific text for records created in the base table; targeted by ADD_LANGUAGE and TRANSLATE_ROW.
• CS_KB_HISTORIES_S — The sequence used to generate unique primary keys for new history rows (the likely object of the user's search term).
• FND_LANGUAGES — The Oracle Application Object Library table of installed languages, queried to validate language codes during translation operations.
• DUAL — The standard single-row utility table used for scalar expressions and sequence lookups.

Supporting dependencies include FND_GLOBAL for session context such as user ID, FND_MESSAGE for standardized error messaging, and APP_EXCEPTION for the application's exception-handling framework.

Usage Notes

This package is typically invoked by Oracle Forms-based knowledge base maintenance screens, by concurrent programs that batch-process history data, and by custom code that requires controlled access to history records. Because the package body is not referenced by any other database object, callers depend on it directly rather than through a wrapper. Developers extending the Customer Service schema should invoke the documented procedures rather than issuing direct DML, so that locking, translation, and error handling remain consistent. Note that CS_KB_HISTORIES_S is a sequence, not a table, and cannot be queried for data.