Search Results delete_application_measure




Overview
Explore in AI Chat

Overview

APPS.BIS_APPLICATION_MEASURE_PVT is the private implementation package for the Application Measures public API in Oracle E-Business Suite. Application Measures represent the configured measurements assigned to indicators within the Balanced Scorecard and performance management framework (the BIS schema). The package encapsulates the data manipulation logic that creates, retrieves, updates, and deletes rows in the BIS_APPLICATION_MEASURES table, enforcing business rules such as the constraint that only one Application Measure record may exist per indicator (documented in the 08-JUL-2003 history note, bug 3008385).

The header comment block identifies the file as BISVAPMB.pls (version 120.0) and describes the object as the "Public API for creating and managing Application Measures." Although classified as a PVT package, its procedures are invoked by the public API layer and by other BIS packages — the ETRM metadata records that it is referenced by one other package.

Key Procedures and Functions

  • CREATE_APPLICATION_MEASURE — Inserts a new Application Measure row. It follows the standard EBS API pattern of accepting p_api_version, a p_commit flag defaulted to FND_API.G_FALSE, and an Application_Measure_Rec_Type record, returning x_return_status and an error table (BIS_UTILITIES_PUB.Error_Tbl_Type). The history log shows the create/update paths were modified in July 2004 to use BIS_UTILITIES_PUB.Get_Owner_Id to derive the user_id, and in September 2004 to populate WHO columns.
  • RETRIEVE_APPLICATION_MEASURES — Returns Application Measure data for a given indicator or key. The 26-JUN-2003 fix (bug 3004651) ensured this API populates dataset_id on output.
  • UPDATE_APPLICATION_MEASURE — Modifies an existing Application Measure, applying the same owner-id and WHO-column logic as the create path.
  • DELETE_APPLICATION_MEASURE — Removes an Application Measure record. The 08-JUL-2003 change added support for handling bad or orphaned data during deletion.
  • VALIDATE_APPLICATION_MEASURE — Performs pre-write validation of the incoming record, such as confirming the indicator exists and uniqueness constraints are satisfied.
  • VALUE_ID_CONVERSION — Converts a measure value identifier, supporting the translation between internal IDs and externally supplied values.
  • RETRIEVE_LAST_UPDATE_DATE — Returns the last update timestamp for an Application Measure. This is the object the user searched for. It is typically used to support optimistic locking or change-detection when synchronizing external or cached copies of measure definitions.
  • LOCK_RECORD — Acquires a row-level lock on the Application Measure record (SELECT ... FOR UPDATE), used to serialize concurrent updates before a subsequent retrieve or update call.

Tables Accessed

  • BIS_APPLICATION_MEASURES — The primary table this package reads and writes. All CRUD procedures target it, including the last-update-date lookup and the row lock.
  • BIS_INDICATORS — Referenced to validate and resolve the indicator to which a measure is assigned, since measure definitions are owned by indicators.
  • PLITBLM — The standard EBS temporary/varchar index table (used by FND-style APIs for ID lists and query helpers); referenced via the APPS synonym during retrieval logic.

Usage Notes

This package is not called directly from an end-user interface. It is invoked by the public BIS Application Measure API layer, by concurrent programs that load or synchronize indicator and measure metadata, and by custom code that must programmatically maintain Application Measures. Callers are expected to observe the standard EBS API contract: supply a valid API version, pass FND_API.G_FALSE for p_commit when they intend to manage their own transaction boundaries, inspect x_return_status, and process x_error_tbl on failure.

When retrieving the last update date, invoke RETRIEVE_LAST_UPDATE_DATE rather than querying BIS_APPLICATION_MEASURES directly, so that the package's internal conversion and validation logic is respected. Prior to an update, callers should invoke LOCK_RECORD to prevent lost updates under concurrency.