Search Results ego_col_name_value_pair_obj




Overview
Explore in AI Chat

Overview

EGO_UPLOAD_PUB is a public PL/SQL package body in the Oracle E-Business Suite EGO (Electronic Technical Catalog / Item Catalog) product family. Its business purpose is to support the programmatic uploading and synchronization of item catalog metadata — specifically catalog groups, attribute group associations, item pages, and page entries — into the EGO catalog data model. These catalog constructs underpin the item master search and browse experience in Oracle EBS, where descriptive flexfield attributes, page layouts, and category-based attribute groupings must be kept consistent across catalog structures.

The package is owned by the APPS schema and is classified as a public API (PUB), meaning it is intended for supported external invocation rather than private internal use. In Oracle EBS 12.1.1 and 12.2.2, the EGO item catalog is defined through a set of normalized tables (EGO_OBJ_AG_ASSOCS_B, EGO_PAGES_B, EGO_PAGE_ENTRIES_B, and supporting descriptive flexfield extension tables), and this package provides the entry points that seed and reconcile those tables. A recurring internal pattern visible in the source is a set of private helper procedures — get_object_id, get_catalog_group_id, get_attr_group_id, get_association_id, and get_page_id — that resolve surrogate keys from natural identifiers before performing uploads, silently returning NULL when lookups fail.

Key Procedures and Functions

  • SYNC_CATALOG_GROUP — Synchronizes catalog group definitions into the EGO catalog model, resolving the catalog group identifier and its related object/attribute group context.
  • SYNC_CAT_ATTR_GRP_ASSOC — Establishes or reconciles the association between a catalog group and an attribute group, writing to the object/attribute-group association structures.
  • SYNC_CAT_ITEM_PAGES — Synchronizes the catalog item page definitions, ensuring page records exist for the relevant object and catalog group configuration.
  • SYNC_CAT_ITEM_PAGE_ENTRIES — Synchronizes the individual entries that belong to each catalog item page, defining what attributes or content render on the page.
  • CREATEBASEATTRIBUTEPAGES — Creates the baseline attribute pages required for catalog item display, providing the foundational page layout that subsequent page entry synchronization populates.

The package also contains private helper logic (get_object_id, get_catalog_group_id, get_attr_group_id, get_association_id, get_page_id) used to resolve natural keys to internal identifiers during these synchronization routines.

Tables Accessed

  • EGO_FND_DSC_FLX_CTX_EXT — Resolves descriptive flexfield context codes to attribute group identifiers; queried against application_id 431.
  • EGO_OBJ_AG_ASSOCS_B — Stores object-to-attribute-group associations keyed by object, classification code, and attribute group.
  • EGO_PAGES_B — Holds catalog page definitions written during page synchronization.
  • EGO_PAGE_ENTRIES_B — Holds the individual page entries associated with each catalog page.
  • FND_OBJECTS — Used to resolve the internal object_id for the 'EGO_ITEM' object name.
  • MTL_ITEM_CATALOG_GROUPS_B — Referenced for catalog group master data.
  • PLITBLM — A standard Oracle tooling table accessed by the package.

Usage Notes

EGO_UPLOAD_PUB is a server-side public API invoked during catalog setup and configuration maintenance, typically from concurrent programs or from custom integration code that must programmatically seed the item catalog. It is not a form-driven UI package; callers supply natural identifiers (object name, catalog group, attribute group, page internal name) and the package performs the necessary lookups and writes. Because its private helpers swallow exceptions and return NULL on lookup failure, callers should validate required inputs and verify results explicitly rather than relying on exceptions. The package is referenced by one other EBS package, indicating it participates in a broader catalog synchronization flow. Developers extending catalog behavior should treat it as a controlled API and avoid direct DML against the underlying EGO tables.