Search Results cs_kb_num_ses_del

Overview

CS_KB_TRACKING_PKG is an Oracle EBS Service (CS) module PL/SQL package body owned by APPS and classified as OTHER (not a public API). Its documented purpose is to purge tracking history for Oracle Knowledge Base browsing sessions. The package operates against the session-tracking infrastructure that records user interactions with knowledge base articles, and it removes records associated with session identifiers that are no longer valid — specifically, sessions whose source object code matches the 'KMT%' prefix pattern and whose source object identifier no longer corresponds to an active, enabled ICX session. In practical terms, the package reconciles the knowledge base activity tables against the ICX (Oracle Applications Framework / session management) session table and clears out orphaned or stale tracking rows that would otherwise accumulate indefinitely. This supports housekeeping, database growth management, and data integrity of Service module tracking data.

Key Procedures and Functions

The package body exposes a single documented procedure:

• PURGE_TRACKING_HISTORY — Declared with ERRBUF and RETCODE parameters following the standard concurrent-program interface convention. Its purpose is to identify and delete knowledge base session tracking records that reference invalid ICX sessions, and to report the outcome. The procedure opens two cursors, get_session_attr_count and get_session_count, to determine how many session attribute rows and how many session rows will be affected. It then writes progress and result messages to the concurrent program log via FND_FILE.PUT_LINE, combining localized text retrieved through FND_MESSAGE.GET_STRING (messages such as CS_KB_DEL_TRACKING_DATA, CS_KB_NUM_SES_ATTR_DEL, and CS_KB_NUM_SES_DEL) with the computed counts. The procedure subsequently performs DELETE statements against CS_KB_SESSION_ATTRS, removing attribute rows whose session identifiers belong to the invalid session set. RETCODE follows the standard convention: 0 for success, 1 for warning, and 2 for error, allowing the concurrent manager to interpret the run result.

The cursor named get_session_count, which the user searched for, is an internal private cursor rather than a standalone callable API. It selects COUNT(*) from CS_KB_SESSIONS where the source object code matches 'KMT%' and the source object identifier is not present among enabled (NVL(disabled_flag,'N') = 'N') ICX session identifiers. Its result is fetched into local variable l_session_count and reported to the log.

Tables Accessed

• CS_KB_SESSIONS — The primary knowledge base session table. The package counts candidate rows via get_session_count and deletes stale session records from it.
• CS_KB_SESSION_ATTRS — Holds session attribute detail rows keyed to a session identifier. The package counts candidates via get_session_attr_count and deletes matching attribute rows, preserving referential consistency with the parent session purge.
• ICX_SESSIONS — The Oracle Applications session table, used as the authoritative reference for session validity. Rows in ICX_SESSIONS with a disabled_flag other than 'N' are excluded, so tracking data tied only to disabled ICX sessions is treated as purgeable.

Usage Notes

The procedure's OUT NOCOPY ERRBUF/RETCODE signature and its use of FND_FILE and FND_MESSAGE.GET_STRING indicate that it is designed to run as an Oracle EBS concurrent program rather than being called from a form, workflow, or interactive UI. Administrators typically schedule or submit the purge as a periodic housekeeping job to control growth of the knowledge base tracking tables. Because the package is classified as OTHER and is referenced by no other documented packages, it is not a supported public API; custom code should not depend on its internal cursors or private variables, as these are subject only to version-specific behavior. The package header comment ($Header cskbtkb.pls 115.2) and structure are consistent across EBS 12.1.1 and 12.2.2, and message text is sourced from the CS message dictionary, meaning deployments must have the corresponding FND messages defined for meaningful log output.