Search Results get_names

Overview

BIS_RSG_PUB_API_PKG is a public PL/SQL API package in the Oracle E-Business Suite environment, owned by the APPS schema and classified under the OTHER API category. It serves as the programmatic interface to the Oracle iSetup / Application System Repository (RSG) metadata layer, which stores the definitions of pages, properties, linkages, and dependencies used to describe the structure of Oracle EBS applications. The package header revision shows a header of BISRSGPB.pls, version 120.3, last modified 2005/11/14.

The business purpose of the package is to allow both standard Oracle components and customer extensions to maintain the RSG repository in a controlled manner, rather than issuing direct DML against the underlying tables. It provides create, update, and delete operations for dependencies, properties, and linkages, along with utility routines for resolving page names, walking parent object hierarchies, and toggling index management. Because the repository describes how objects relate to one another, the package is central to keeping that metadata consistent across migrations, upgrades, and customizations.

Key Procedures and Functions

The documented interface exposes twenty procedures and functions, whose purposes are as follows:

• CREATE_DEPENDENCY — inserts a new dependency relationship between two repository objects.
• UPDATE_DEPENDENCY — modifies an existing dependency record.
• DELETE_DEPENDENCY — removes a single dependency.
• DELETE_PAGE_DEPENDENCIES — removes all dependencies associated with a given page object, useful when a page is retired.
• UPDATE_PROPERTY — updates an existing property definition on a repository object.
• UPDATE_PROPERTY_DIM_FLAG — sets or clears the dimension flag on a property.
• UPDATE_PROPERTY_CUSTOM_API — updates the custom API association of a property.
• DELETE_PROPERTY — removes a property record.
• CREATE_LINKAGE — establishes a new linkage between repository objects.
• UPDATE_LINKAGE — changes an existing linkage definition.
• UPDATE_LINKAGE_ENABLED_FLAG — enables or disables a linkage.
• UPDATE_LINKAGE_REFRESH_MODE — changes the refresh mode used by a linkage.
• DELETE_LINKAGE — deletes a single linkage.
• DELETE_OBJ_LINKAGES — deletes all linkages belonging to an object.
• GET_PAGE_NAME_BY_FUNC — the routine most closely associated with the "get_names" search. It resolves a function name to its repository page object name. Per the embedded source comment, the logic first attempts to find an <function>_OA page object in the RSG repository; if found it returns that name, otherwise it returns the function name unchanged. A documented limitation notes that in migrated environments where both A and A_OA exist in FND_FORM_FUNCTIONS, the routine may resolve to the wrong object. The function returns NULL for null or empty input and on any exception.
• GETPARENTOBJECTS — returns the parent objects of a given repository object, supporting hierarchy navigation.
• ENABLE_INDEX_MGMT — enables index management processing.
• DISABLE_INDEX_MGMT — disables index management processing.

Tables Accessed

The package references three base tables through APPS synonyms:

• BIS_OBJ_DEPENDENCY — stores dependency rows between repository objects; read by get_page_name_by_func and written by the create, update, and delete dependency routines.
• BIS_OBJ_PROPERTIES — stores property definitions for objects; queried during page name resolution and maintained by the property routines.
• BIS_OBJ_PROG_LINKAGES — stores linkages between objects; maintained by the create, update, and delete linkage routines.

Usage Notes

The package is invoked programmatically rather than from a standard concurrent program or form. It is referenced by five other packages within the EBS codebase, which call it to maintain repository metadata during object creation, migration, and configuration workflows. Custom code should call these public APIs instead of issuing direct DML against the BIS tables, so that index management and internal consistency checks are applied. The package derives the current user and login identifiers from FND_GLOBAL at initialization, so callers must execute it within an authenticated EBS session.