Search Results is_measure_type

Overview

APPS.BIS_AK_REGION_PUB is a public PL/SQL package body in Oracle E-Business Suite that acts as the integration layer between Oracle Business Intelligence System (BIS) and the Oracle Application Framework (AK) metadata repository. Its primary business function is to insert, update, and delete region and region-item definitions held in the AK tables, which underpin the Oracle EBS Personalization and Page Definer functionality. The package is documented in ETRM as an API classified "PUB," meaning it is intended to be called from outside its own schema unit rather than exclusively from internal code. The header comment confirms it is a "private package that calls the AK packages to insert/update/delete records in the AK tables," while its public API name and PUB classification expose those capabilities to dependent modules.

The package evolved through several functional integrations, including Page Definer, Portlet Builder, and BSC/PMV integration, and its change history records distinct enhancement and bug-fix entries between 2001 and 2007. It is referenced by eight other packages in the EBS codebase, which reinforces its role as a reusable foundation for region metadata maintenance rather than a leaf-level utility.

Key Procedures and Functions

The documented API surface contains 34 procedures and functions, several of which are overloaded to support differing functional and messaging requirements introduced by the Page Definer and BSC/PMV integrations. Core region maintenance is handled by INSERT_REGION_ROW, UPDATE_REGION_ROW, and DELETE_REGION_ROW, which manage the region header records themselves. Region-item level maintenance is handled by INSERT_REGION_ITEM_ROW, UPDATE_REGION_ITEM_ROW, DELETE_REGION_ITEM_ROW, and UPDATE_REGION_ITEM_ATTR, with the latter overloaded for measure and compare attribute validation. Bulk removal is provided by DELETE_REGION_ITEMS, DELETE_EXT_REGION_ITEMS, and DELETE_REGION_AND_REGION_ITEMS.

Validation functions include VALID_DATABASE_OBJECT, which the 07/22/04 change note (Enh#3786101) states was modified to "consider Materialized view as a valid database object," AK_OBJECT_EXISTS, and AK_DATA_SET. Insertion of AK object metadata is performed by INSERT_AK_OBJECT. Retrieval of an existing region item is served by GET_REGION_ITEM_REC, and concurrency protection is provided by LOCK_REGION_ROW, which the 08/04/04 bug fix (Bug#3823878) added and which performs a rollback within the locking procedure. Type and content validation is supported by IS_MEASURE_TYPE, IS_COMPARE_TYPE, VALIDATE_MEASURE, and VALIDATE_COMPARE. Exception handling was extended on 05/22/04 to propagate errors to the user interface, and on 09/24/04 (Bug#3893663) to return SQLERRM for all unexpected errors.

Tables Accessed

The package reads and writes the principal AK region definitions through the APPS synonyms AK_REGIONS and its translation table AK_REGIONS_TL, the child AK_REGION_ITEMS table, and AK_ATTRIBUTES for item attributes. The BIS_AK_REGION_ITEM_EXTENSION table stores BIS-specific extensions to region items beyond the base AK model. AK_OBJECTS holds the metadata definitions inserted by INSERT_AK_OBJECT and checked by AK_OBJECT_EXISTS. The dictionary view USER_OBJECTS is queried by VALID_DATABASE_OBJECT to determine whether a nominated object—including, after Enh#3786101, materialized views—constitutes a valid database object.

Usage Notes

BIS_AK_REGION_PUB is intended for programmatic region administration: invoked from EBS forms such as the Page Definer and Portlet Builder, from concurrent programs that synchronize region metadata, and from custom code that needs to create or maintain AK regions without directly manipulating the underlying tables. Callers should invoke the public procedures rather than writing to AK_REGIONS or AK_REGION_ITEMS directly, because the package encapsulates validation, exception propagation, and locking. When concurrent access is possible, LOCK_REGION_ROW should be used before update or delete operations. Error handling is designed to surface messages to the UI, so callers should preserve and display returned exceptions rather than suppressing them. The presence of overloaded procedures requires that callers supply parameters matching the intended overload; no parameter lists are reproduced here and the ETRM metadata should be consulted for exact signatures.