Search Results insert_custom_registry




Overview
Explore in AI Chat

Overview

BIS_CUSTOMIZATION is a small Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified in the ETRM repository as an OTHER object rather than a formal public API. Its declared purpose, reflected in the package name and in the two procedures it exposes, is to support the customization layer of the Oracle Business Intelligence System (BIS) / EBS Analytics framework. That framework relies on the AK (Application Kit) registry metadata model, in which customer-defined regions and region items are recorded so that the reporting and analytics UI can be extended without modifying Oracle-seeded definitions. BIS_CUSTOMIZATION provides the programmatic entry points used to seed and clean up that registry data.

The package is declared AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking session rather than the definer. This is significant in an APPS-owned utility: any caller must itself hold the necessary DML privileges on the underlying AK tables. The header comment identifies the file as BISVCSTS.pls, version 120.1, last modified in February 2006, and marked noship — that is, a non-shipping or internal utility not intended for general customer invocation.

Key Procedures and Functions

Two procedures are documented for this package. No function overloads or private helpers are exposed in the specification.

  • INSERT_CUSTOM_REGISTRY — The procedure associated with the user's search term. Its purpose is to insert customization entries into the AK registry metadata so that a customer-specific region or region configuration is recognized by the BIS framework. It operates on the registry tables described below and is the mechanism by which custom analytics content is registered into the metadata repository.
  • DELETE_REGION_ITEM — Removes a region item definition from the registry. This is the complementary cleanup routine, used when a customized region item is retired or when an installation is being rolled back to Oracle-seeded definitions.

Because the ETRM entry records only the specification, parameter lists are not documented here and should not be assumed; the procedures are described by purpose only. The source header lists no package-level variables or constants, indicating a thin procedural wrapper over DML against the AK tables.

Tables Accessed

Three tables are referenced through APPS synonyms:

  • AK_CUSTOM_REGISTRY — The primary target of INSERT_CUSTOM_REGISTRY. It stores customer-defined registry records that layer on top of Oracle-delivered analytics definitions.
  • AK_REGION_ITEMS — The base region item definition table. DELETE_REGION_ITEM removes rows here (or marks them for deletion) when a customized region item is no longer required.
  • AK_REGION_ITEMS_TL — The translation (TL) table holding language-specific attribute values for region items. Any deletion of a region item must be paired with cleanup in the TL table to avoid orphaned translated rows, which is consistent with DELETE_REGION_ITEM touching both.

Usage Notes

ETRM records zero packages referencing BIS_CUSTOMIZATION, which confirms that it is not part of an inter-package dependency chain and is instead invoked directly — typically from a setup form, a one-off concurrent program, or manual custom code executed by a consultant during an analytics customization engagement. Because it is marked noship and classified as OTHER, it is not a supported public API and carries no compatibility guarantee across releases; the 12.1.1 and 12.2.2 file systems retain the same specification.

Practitioners using INSERT_CUSTOM_REGISTRY should treat it as a metadata seeding utility: invoke it in a controlled environment, verify the resulting rows in AK_CUSTOM_REGISTRY, and use DELETE_REGION_ITEM to reverse the operation. Direct DML against the AK tables is the alternative, but risks inconsistency between AK_REGION_ITEMS and AK_REGION_ITEMS_TL — precisely the gap these procedures exist to close. Testing on a clone before production execution is advisable given the absence of documented error handling in the specification.