Search Results cs_kb_tracking_pkg

Overview

The APPS.CS_KB_TRACKING_PKG package is a PL/SQL database object within the Oracle E-Business Suite (EBS) Service (Customer Service) application. Its name follows the CS_KB_ naming convention, associating it with the Knowledge Base (KB) subsystem of the Customer Service module. In Oracle EBS releases 12.1.1 and 12.2.2, the Knowledge Base supports the authoring, publishing, and retrieval of knowledge articles used by service agents to resolve customer issues. As part of that subsystem, this package provides maintenance functionality for tracking-related data — specifically the historical records that accumulate as users interact with the Knowledge Base through their application sessions.

The package is owned by the APPS schema and holds a documented status of VALID, reflecting a compiled and deployable object in the EBS database. Its API classification in the ETRM repository is OTHER, indicating that it is an internal supporting utility rather than a public, formally published integration API. It is not referenced by any other package (referenced-by count of zero), which confirms its role as a leaf-level maintenance utility rather than a shared infrastructure component reused across the application stack.

Key Procedures and Functions

The ETRM metadata documents a single procedure within this package:

• PURGE_TRACKING_HISTORY — Removes obsolete tracking records from the Knowledge Base session history. Its purpose is housekeeping: over time, the tables that log Knowledge Base usage grow continuously, and this procedure provides a controlled mechanism to delete stale rows, thereby reclaiming storage and preserving query performance. As with most EBS purge routines, the procedure is expected to operate within a defined retention window rather than deleting all history indiscriminately, though the exact parameter list and retention logic are intentionally not documented here.

No functions are documented for this package. Because the metadata exposes only this one subprogram, the package should be regarded as narrowly scoped to the purge operation rather than a broad Knowledge Base API.

Tables Accessed

The package operates against three documented tables, accessed through APPS synonyms:

• CS_KB_SESSIONS — Stores Knowledge Base session records, tracking user activity within the KB interface. The purge procedure targets this table as a primary source of accumulated history.
• CS_KB_SESSION_ATTRS — Holds attribute-level detail associated with those Knowledge Base sessions. Records here are logically dependent on the parent session rows, so purge logic must respect that relationship to avoid orphaned attribute data.
• ICX_SESSIONS — The Oracle EBS framework table for application (ICX) sessions from which Knowledge Base activity originates. Its inclusion indicates that the package correlates KB tracking data with the underlying application session context.

Collectively, these tables form the tracking backbone of the Knowledge Base: sessions, their attributes, and the parent EBS session. The package's sole documented purpose is to remove records from this set once they are no longer required.

Usage Notes

Because CS_KB_TRACKING_PKG exposes no documented public integration API and is referenced by no other package, it is best characterized as an internal maintenance routine. In practice, such packages in EBS are invoked in one of two ways:

• From a concurrent program scheduled by the system administrator. A recurring, off-peak purge job is the most likely invocation path, allowing the administrator to control runtime and retention policy without manual intervention.
• From custom or wrapper code that calls the purge procedure directly, for example during a data-migration or archival exercise.

Direct invocation from a standard Oracle Forms-based screen is unlikely, since the procedure performs bulk deletion rather than interactive processing. Administrators should ensure adequate tablespace and undo capacity before execution, and should verify that purging the session and attribute rows does not conflict with active Knowledge Base sessions or with reporting that depends on historical tracking data. Given the absence of a documented parameter list, implementers must inspect the package specification in the target environment to confirm the exact calling signature, any date-range inputs, and the commit behavior. Where the metadata is silent — such as retention thresholds and error handling — behavior should be validated against the deployed source in the specific EBS 12.1.1 or 12.2.2 instance before relying on it operationally.