Search Results bsc_current_sessions

Overview

BSC_CURRENT_SESSIONS is a table owned by the BSC schema (Oracle Balanced Scorecard module) in Oracle E-Business Suite 12.1.1 and 12.2.2. As its description indicates, the table stores current BSC sessions — a transient record of active Balanced Scorecard user sessions against the EBS instance. It acts as a lightweight registry that the BSC application consults to determine which users currently hold an active scorecard session, enabling session-scoped behavior such as personalization caching, scorecard state, and timeout enforcement.

From a Data Vault modeling perspective, the heuristic classification mined from the FK structure is standalone. This means the table is not a pure hub, link, or satellite in the classic sense, but rather an operational/transactional accumulator. If modeled in Data Vault terms, SESSION_ID would function as the hub key and the descriptive session attributes as satellite payload. The single foreign key — BSC_CURRENT_SESSIONS.ICX_SESSION_ID referencing FND_SESSION_VALUES — is an interesting cross-module link, tying the BSC session registry to the underlying ICX (self-service framework) session value store, which is the foundation of EBS session management.

Key Information Stored

The table documents 9 columns in the ETRM 12.1.1 physical schema. The most important are:

• SESSION_ID — The surrogate primary key uniquely identifying each BSC session row. This is the column to use for direct lookups and as the join target from dependent BSC tables.
• ICX_SESSION_ID — The foreign key to FND_SESSION_VALUES. This is the business-key candidate that correlates the BSC session to the EBS/ICX session layer. It is the most operationally significant value in the table because it chains BSC activity to the underlying application session.
• USER_ID — The EBS user (FND_USER.USER_ID) who owns the session. This is the primary filter for user-specific session queries and the natural grouping column for concurrency reporting.
• PROGRAM_ID — The concurrent program / application program identifier responsible for the session context, useful for tracing which BSC process spawned the session.
• CREATED_BY, CREATION_DATE — Standard EBS WHO columns capturing the creating user and creation timestamp. CREATION_DATE supports session-age and timeout analysis.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard audit columns recording the last modifying user, timestamp, and login. LAST_UPDATE_DATE is the key column for determining session freshness and detecting stale entries.

Note that while the standard WHO columns are present, the table does not carry a full set of descriptive session attributes; it is intentionally a thin registry.

Common Use Cases and Queries

The principal use case is identifying and cleaning orphaned or expired BSC sessions. A DBA or developer might query active sessions for a specific user or age:

SELECT s.SESSION_ID, s.ICX_SESSION_ID, s.USER_ID,
       s.CREATION_DATE, s.LAST_UPDATE_DATE
  FROM BSC.BSC_CURRENT_SESSIONS s
 WHERE s.USER_ID = :p_user_id
 ORDER BY s.LAST_UPDATE_DATE DESC;

To find sessions that have not been touched beyond a timeout threshold (candidate stale rows):

SELECT s.SESSION_ID, s.USER_ID, s.LAST_UPDATE_DATE
  FROM BSC.BSC_CURRENT_SESSIONS s
 WHERE s.LAST_UPDATE_DATE < SYSDATE - :p_timeout_days;

Joining to the ICX session layer correlates BSC registry rows to the underlying EBS session values, useful for diagnosing "session not found" errors or double-login conditions:

SELECT s.SESSION_ID, s.ICX_SESSION_ID, f.SESSION_VALUE
  FROM BSC.BSC_CURRENT_SESSIONS s
  JOIN FND_SESSION_VALUES f
    ON f.SESSION_ID = s.ICX_SESSION_ID;

Reporting use cases include concurrent-user counts per USER_ID or PROGRAM_ID, and historical auditing via CREATION_DATE. Because the table captures only "current" sessions, it is not a historical fact table; treat it as operational state rather than an analytical source.

Related Objects

The relationship data identifies a single documented foreign key, which constrains the direct referential neighborhood:

• FND_SESSION_VALUES — Referenced by ICX_SESSION_ID. The core EBS session-value store underlying the ICX self-service framework. This is the most significant related object, providing the authoritative session identity behind each BSC registry row.
• FND_USER — Implied join target via USER_ID. Supplies the user name and login context for the session owner; not documented as an FK in the metadata but a standard EBS WHO join.
• FND_LOGINS / FND_LOGIN_RESPONSIBILITIES — Adjacent session/login tables commonly joined for login history and responsibility context.
• BSC_* configuration and scoring tables — Sibling objects in the BSC schema that rely on an active scorecard session, though no explicit FK is documented to this registry.
• ICX_SESSIONS — The parent session table in the ICX framework, relevant when tracing the full session chain from BSC to the EBS application session.

Because the metadata classifies the table as standalone with a single FK, integrators should not assume additional documented dependencies; any further joins are application-level rather than schema-enforced.