Search Results cs_kb_histories_pkg




Overview
Explore in AI Chat

Overview

CS_KB_HISTORIES_PKG is a PL/SQL package owned by the APPS schema that manages the persistent history records associated with Oracle E-Business Suite Knowledge Base articles. In Oracle EBS 12.1.1 and 12.2.2, the Knowledge Base (formerly Interaction Center / iSupport knowledge management) relies on a set of base, translation, and language-specific tables to store audit trails of changes made to knowledge documents. CS_KB_HISTORIES_PKG serves as the primary data access layer for those history records, encapsulating the insert, update, delete, and locking logic required to maintain referential consistency across the multi-table Knowledge Base schema. By centralizing this logic in a single package, Oracle ensures that every history row written by concurrent programs, forms, or internal APIs conforms to the same validation and translation rules.

The package is classified as an OTHER API in the ETRM metadata, indicating that it is primarily an internal implementation package rather than a formally published public API. It references the SYS.STANDARD package and is referenced by CS_KNOWLEDGE_PVT, which acts as the orchestration layer for knowledge article processing. This dependency confirms that CS_KB_HISTORIES_PKG is invoked indirectly through higher-level Knowledge Base flows rather than directly by end-user applications.

Key Procedures and Functions

The ETRM documentation lists eight documented program units within the package:

  • CREATE_HISTORY — Creates a new history record for a Knowledge Base article, establishing the initial audit entry associated with the document's lifecycle.
  • INSERT_ROW — Performs the core insertion of history data into the underlying base table, including language and translation rows where applicable.
  • LOCK_ROW — Acquires a row-level lock on an existing history record to prevent concurrent modification during an update or delete operation.
  • UPDATE_ROW — Modifies an existing history record, typically to reflect status changes or corrections captured by the Knowledge Base workflow.
  • DELETE_ROW — Removes an individual history record from the base table.
  • DELETE_HISTORY — Removes the complete set of history records associated with a given article or history identifier.
  • ADD_LANGUAGE — Inserts translation rows for a history record, enabling multilingual support consistent with the Knowledge Base's TL table design.
  • TRANSLATE_ROW — Updates or maintains the translated content of a history record for a specified language.

No parameter lists are documented in the ETRM metadata and none are inferred here.

Tables Accessed

The package accesses the following tables through APPS synonyms:

  • CS_KB_HISTORIES_B — The base table storing language-independent history attributes; the primary target of CREATE_HISTORY, INSERT_ROW, UPDATE_ROW, LOCK_ROW, and both delete routines.
  • CS_KB_HISTORIES_TL — The translation table holding language-specific history text; written by ADD_LANGUAGE and TRANSLATE_ROW.
  • CS_KB_HISTORIES_S — A supplemental/sequence table used to support the history record numbering or secondary attribute storage.
  • FND_LANGUAGES — The Oracle Applications installed-languages table, queried to validate that a requested language is installed and active before translation rows are created.
  • DUAL — Used for single-row expressions such as sequence lookups or SYSDATE retrieval.

Usage Notes

CS_KB_HISTORIES_PKG is not intended to be called directly from custom forms or concurrent programs. In standard Oracle EBS 12.1.1 and 12.2.2 flows, it is invoked through CS_KNOWLEDGE_PVT, the private Knowledge Base API that coordinates article creation, revision, and translation events. History rows are typically generated when a user creates, updates, or deletes a knowledge article through the Knowledge Base authoring forms or when scheduled processes refresh article metadata.

Because the package performs direct DML against CS_KB_HISTORIES_B, _TL, and _S, any custom extension that writes to these tables should call the package rather than issuing raw SQL, ensuring that the OLTP validation and translation rules remain intact. The presence of LOCK_ROW and the paired DELETE_ROW/DELETE_HISTORY routines indicates that callers must manage transaction boundaries explicitly; the package does not commit on its own behalf. Administrators troubleshooting history-related issues should verify the package status as VALID in the APPS schema and confirm that CS_KNOWLEDGE_PVT is compiled and valid, since a compilation failure in either object will block knowledge article history processing.