Search Results bis_dim_level_value_pub




Overview
Explore in AI Chat

Overview

APPS.BIS_DIM_LEVEL_VALUE_PUB is a public PL/SQL package body in the Oracle E-Business Suite Applications (APPS) schema. It belongs to the Oracle Business Intelligence System (BIS) family of database objects, which provides the foundational dimensional and analytical infrastructure used by EBS Business Intelligence products and by the Dimensional Database / Daily Business Intelligence (DBI) reporting stack. The package encapsulates logic for resolving and returning dimension level values — that is, the member values associated with a given level of a business intelligence dimension — together with a specialised variant for responsibility-scoped dimension level values. Because the object is classified as a PUB (public) API, it is intended to be called from outside its own package body, most notably by the other BIS packages that depend on it. The body is documented as VALID in the ETRM metadata for both Oracle EBS 12.1.1 and 12.2.2, and the reference information records that it is referenced by eighteen other packages while itself depending only on the APPS schema and the package specification of the same name.

Key Procedures and Functions

The documented public interface exposes two program units:

  • RETRIEVE_DIM_LEVEL_VALUES — Returns the set of values belonging to a dimension level. In the BIS dimensional model, each dimension (for example, a time, organisation, or product dimension) is composed of hierarchical levels, and consumers such as DBI dashboards and analytic pages require the list of valid members at a chosen level in order to populate prompts, filters, and report parameters. This procedure performs that lookup and returns the matching level values to the caller.
  • RETRIEVE_RESP_DIM_LEVEL_VALUES — A responsibility-aware counterpart to the first procedure. It returns dimension level values that are restricted according to the responsibility under which the request is executed, thereby supporting row-level security and data-access filtering in BI reporting contexts. This is the variant used when the caller must honour the access privileges and dimension assignments associated with a specific EBS responsibility rather than returning the full, unrestricted member list.

The metadata documents these two program units by name and classification only; parameter signatures are not published in the extracted record and should be confirmed against the deployed package specification.

Tables Accessed

The documented table reference for this package is BIS_LEVELS_TL, accessed through an APPS synonym. This is the translatable (_TL) table that stores level definitions and their language-specific descriptions for the BIS dimensional model. The package reads this table to resolve the level being queried and to obtain the corresponding level rows from which values are derived or validated. Because the table is a translation table, level names returned in reporting are presented in the session’s language, which is consistent with the multilingual requirements of EBS 12.1.1 and 12.2.2 deployments.

Usage Notes

BIS_DIM_LEVEL_VALUE_PUB is an internal infrastructure API rather than an end-user entry point. It is typically invoked indirectly: the metadata confirms eighteen dependent packages call into it, and these callers in turn drive DBI regions, folder-based analytics, and OBIEE/EBS integrated reporting. The RESP variant is the appropriate choice whenever the calling context has an active responsibility and the returned values must respect that responsibility’s data restrictions; the unrestricted variant is used where the full level member set is required. Custom code should invoke the package through its APPS synonym, never by direct schema reference, and should treat the API as a read-only retrieval service. Form-based and concurrent-program callers are therefore expected to pass the dimension and level identifying information supplied by the reporting layer rather than constructing level lists independently. Given that the object is a package body, no direct calls are made to it as a body; only the specification procedures are callable. Because the documented metadata does not include parameter lists, developers integrating with this API should inspect the deployed specification in the target instance before coding calls.