Search Results bis_pmv_parameters_pvt




Overview
Explore in AI Chat

Overview

The APPS.BISVIEWER package is a core PL/SQL component of the Oracle E-Business Suite Business Intelligence System (BIS), the technology stack that underpins the Daily Business Intelligence (DBI) and Balanced Scorecard (BSC) product families. Its principal business function is to render and present BIS/DBI report content to end users within the Oracle EBS framework, including standard reports, XML-based reports, and drill-down navigations. Rather than computing performance metrics or aggregating transactional data, BISVIEWER serves as the presentation and dispatch layer through which the many BIS "*_PVT" packages deliver their output. In Oracle EBS 12.1.1 and 12.2.2, the object resides in the APPS schema with a status of VALID and is classified generically as OTHER under the ETRM API classification scheme, indicating that it is an internal utility package rather than a formally published public API. Its broad dependency footprint — referenced by twelve other packages across the DBI, PMV, and BSC schemas — confirms its role as shared runtime infrastructure for the BIS reporting tier.

Key Procedures and Functions

The ETRM metadata documents six procedures and functions within BISVIEWER:

  • SHOWREPORT — Renders and displays a standard BIS report for the invoking user, acting as the primary entry point for report presentation.
  • SHOWXMLREPORT — Renders report output sourced from XML, supporting the XML Publisher / BI Publisher style delivery used by later BIS releases.
  • DRILLDOWN — Handles navigation from a summary or aggregate display to the underlying detail, enabling the multi-level drill behavior characteristic of DBI dashboards.
  • GET_NOTIFY_RPT_URL — Returns a URL used for report notification delivery, allowing reports to be referenced or linked in notification and alert workflows.
  • DISPLAYERRORMESSAGE — Presents a formatted error message to the user interface when report generation fails.
  • DISPLAYERROR — Provides the lower-level error presentation routine used by the package to surface exceptions.

No parameter signatures are documented in ETRM; consultants should inspect the package specification with DESC APPS.BISVIEWER or query ALL_ARGUMENTS before invoking these routines from custom code.

Tables Accessed

BISVIEWER accesses three documented tables, principally through APPS synonyms:

  • FND_FORM_FUNCTIONS — The Oracle Application Object Library table of form functions, consulted to resolve the function and responsibility context under which a report is invoked and to enforce access control.
  • FND_RESPONSIBILITY — The AOL responsibility definition table, used to determine the current user's responsibility and associated menu/function security when rendering reports.
  • BIS_SCHEDULER — The BIS scheduling metadata table, referenced when report rendering interacts with scheduled or notification-driven report execution.

The HTP (HTML Toolkit) package is also referenced, reflecting the generation of HTML output during report display. These accesses align with the package's role as a presentation dispatcher rather than a data-processing engine.

Usage Notes

BISVIEWER is not intended for direct invocation by end users or typical customizations. It is invoked indirectly by the DBI/PMV subsystem whenever a user opens a BIS report or dashboard page from the Oracle EBS navigator, and by the scheduling and notification framework when a report is delivered through workflow or the BIS scheduler. The ETRM dependency metadata shows it is referenced by twelve packages, including BIS_PMV_PARAMETERS_PVT (the context of the user's search), BIS_PMV_QUERY_PVT, BIS_PMV_DRILL_PVT, BIS_PMV_REGION_ITEMS_PVT, BIS_PMV_PORTAL_UTIL_PVT, BIS_PMV_UTIL, BIS_COMPUTED_ACTUAL_PVT, BIS_INTERMEDIATE_LOV_PVT, BSC_BIS_KPI_CRUD_PUB, and BSC_MIGRATION. This means that when a user searches for or troubleshoots procedures such as those in BIS_PMV_PARAMETERS_PVT, BISVIEWER is a common downstream dependency in the report rendering call stack. Customizations should avoid direct modification; any extension should call the documented procedures only and rely on the AOL responsibility model for security. Upgrades between 12.1.1 and 12.2.2 may alter internal implementation while preserving the documented entry points.