Search Results bis_measures_extension_vl




Overview
Explore in AI Chat

Overview

BIS_MEASURES_EXTENSION_VL is a multilingual (VL) view owned by the APPS schema in Oracle E-Business Suite. It belongs to the BIS product family, which underpins Oracle's Business Intelligence and Daily Business Intelligence (DBI) reporting infrastructure. The view exposes translated metadata for "measure extensions" — custom or seeded analytical measures that augment the standard measure definitions used by the BIS/DBI performance management framework. Its primary role is to present human-readable, language-specific names and descriptions for each measure extension alongside the base configuration attributes required for reporting, personalization, and integration.

Because it is a _VL view, it returns only the translation row matching the session's language, as determined by the USERENV('LANG') call. This makes it the preferred object for concurrent programs, OAF pages, and BI Publisher reports that must present measure names in the user's locale without requiring application code to join translation tables explicitly.

Underlying Base Objects

The view is defined over a join between two base tables:

  • BIS_MEASURES_EXTENSION (aliased MEAS_EXT) — the base table holding language-independent measure definition data, including the measure short name, functional area, and standard audit columns.
  • BIS_MEASURES_EXTENSION_TL (aliased MEAS_EXT_TL) — the translation table supplying the language-specific NAME and DESCRIPTION values.

The join predicate links the two tables on MEASURE_SHORT_NAME, and the translation row is filtered by the clause MEAS_EXT_TL.LANGUAGE = USERENV('LANG'). This structure follows the standard EBS MLS (Multi-Lingual Support) pattern, in which a _B or base table holds the master record and a _TL table stores one row per installed language.

Key Columns

  • MEASURE_SHORT_NAME — the unique identifier for the measure extension; joins to other BIS measure-related views and tables.
  • NAME — the translated display name of the measure extension, sourced from the _TL table.
  • DESCRIPTION — the translated longer description, also from the _TL table.
  • FUNCTIONAL_AREA_ID — foreign key identifying the functional area (e.g., financials, supply chain) to which the measure belongs.
  • CREATED_BY, CREATION_DATE — audit columns recording who created the record and when.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — audit columns reflecting the most recent modification and the login of the updating user.

Common Use Cases and Queries

Typical scenarios include enumerating available measure extensions for a dashboard configuration utility, validating that translated names exist in all installed languages, and feeding a reporting layer that requires locale-aware labels. A standard query resembles:

  • SELECT MEASURE_SHORT_NAME, NAME, DESCRIPTION, FUNCTIONAL_AREA_ID FROM APPS.BIS_MEASURES_EXTENSION_VL WHERE FUNCTIONAL_AREA_ID = :p_area ORDER BY NAME;
  • SELECT MEASURE_SHORT_NAME, NAME FROM APPS.BIS_MEASURES_EXTENSION_VL WHERE NAME LIKE '%Revenue%';
  • Audit-oriented joins against ALL_OBJECTS or FND audit views to reconcile creation and update history across measure definitions.

Because the view enforces the language filter internally, developers should avoid adding redundant joins to BIS_MEASURES_EXTENSION_TL; doing so risks duplicate rows and defeats the purpose of the VL abstraction. When querying for administrative or DBA purposes independent of the current language, the underlying base and _TL tables should be accessed directly instead.