Results for “bsc_bsc_adapter”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

BSC_BSC_ADAPTER is an Oracle EBS Applications (APPS) schema PL/SQL package that functions as a metadata and calendar adapter layer within the Oracle Balanced Scorecard (BSC) module. In Oracle EBS 12.1.1 and 12.2.2, the BSC product relies on a repository of configuration metadata describing KPIs, data tables, dimensions, periodicities, and reporting calendars. BSC_BSC_ADAPTER serves as the runtime bridge between that repository and the components that consume it, exposing metadata and calendar information through a stable procedural interface so that downstream programs do not query the underlying BSC configuration tables directly.

The package is classified under the ETRM as an OTHER API, indicating that it is an internal, non-public interface rather than a formally published open API. It is documented as VALID in the ETRM reference for release 12.1.1, and its dependency footprint confirms its position in the middle tier of the BSC package stack: it depends on BSC_IM_UTILS, BSC_UPDATE_DIM, and the BSC_VARCHAR2_TABLE_TYPE collection type, and is itself referenced by BSC_DBI_CALENDAR, BSC_MV_ADAPTER, BSC_OLAP_MAIN, and (recursively) BSC_BSC_ADAPTER.

Key Procedures and Functions

The package exposes 56 documented procedures and functions. The principal groups are as follows:

• Initialization and metadata loading: INIT_ALL, LOAD_METADATA_FOR_INDICATORS, and READ_METADATA initialize the adapter's in-memory metadata structures, typically at the start of a BSC processing run.
• KPI metadata retrieval: READ_KPI_REQUIRED and GET_KPI_PERIODICITY return information about the KPIs required for a given calculation context and the periodicity assigned to each KPI.
• Data table introspection: GET_TABLE_COLS, GET_TABLE_PERIODICITY, GET_S_SB_TABLES, and GET_TABLE_RELATIONS expose the columns, periodicities, source/staging tables, and relationships of the BSC data tables registered in the repository.
• Formula and calculation metadata: GET_DB_CALCULATION and GET_COLUMNS_IN_FORMULA return database-side calculation definitions and the columns participating in a formula.
• Calendar and periodicity services: LOAD_REPORTING_CALENDAR, LOAD_REPORTING_CALENDAR_DBI, GET_CALENDAR_DATA, GET_PERIODICITY_DATA, GET_CALENDAR_FOR_PERIODICITY, GET_SUMMARIZE_CALENDAR, and GET_PERIOD_TYPE_ID populate and query the reporting calendar definitions and their periodicities.
• Dimension and level utilities: FIND_XTD_LEVELS and GET_TIME resolve extended dimension levels and time references used in KPI evaluation.

No parameter signatures are published in the ETRM record; callers should obtain exact signatures from the package specification in the database.

Tables Accessed

The package reads and writes configuration metadata held in the following APPS synonyms: BSC_DB_CALCULATIONS and BSC_DB_TABLES (calculation and table definitions), BSC_DB_TABLES_COLS and BSC_DB_TABLES_RELS (table columns and inter-table relationships), BSC_DB_CALENDAR (database calendar definitions), BSC_KPI_DATA_TABLES, BSC_KPI_DIM_LEVELS_B, and BSC_KPI_PERIODICITIES (KPI-to-table, dimension level, and periodicity mappings), and the system-level tables BSC_SYS_CALENDARS_B, BSC_SYS_DIM_LEVELS_B, BSC_SYS_DIM_LEVEL_COLS, BSC_SYS_DIM_LEVEL_RELS, BSC_SYS_FILTERS, BSC_SYS_FILTERS_VIEWS, and BSC_SYS_PERIODICITIES. These tables together define what data the Balanced Scorecard can report on, at what granularity, and over which calendar periods.

Usage Notes

BSC_BSC_ADAPTER is invoked internally by the Balanced Scorecard engine rather than by end users directly. Its primary callers are BSC_DBI_CALENDAR, which builds the reporting calendar used by the DBI layer; BSC_MV_ADAPTER, which services materialized view generation; and BSC_OLAP_MAIN, the main OLAP processing entry point. Because these packages call the adapter during concurrent program execution, the adapter is typically exercised as part of scheduled BSC refresh and aggregation jobs, not from Oracle Forms.

Customizations should not call the adapter directly where a supported API exists. Any customer extension that does invoke it must account for the fact that the package maintains session state through INIT_ALL and READ_METADATA; calling dependent functions before initialization can return incomplete metadata. In upgrades from 12.1.1 to 12.2.2 the package remains a standard APPS object, and changes to the underlying BSC_SYS_* and BSC_DB_* tables should be made only through supported BSC setup forms to keep the adapter's cached metadata consistent.