Results for “cz_rp_directory_v”

24 results




AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CZ_RP_DIRECTORY_V is an informational view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the CZ – Configurator product. It exposes a consolidated, read-only directory of the Configurator Repository, presenting summary information for repository objects of every type. The view is defined as a UNION of four underlying repository sources: the CZ_RP_ENTRIES synonym and the CZ_RP_EFF_DIRECTORY_V, CZ_RP_PRJ_DIRECTORY_V, and CZ_RP_USG_DIRECTORY_V views. Because it merges entries from these distinct directories into a single uniform column projection, it functions as a unified catalog or "phone book" of Configurator repository content. In EBS 12.1.1 and 12.2.2 it carries a VALID status and is used primarily for reporting, browsing, and integration queries rather than for transactional processing. The view exposes auditor-friendly columns such as CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, and LAST_UPDATE_DATE, and it preserves the DELETED_FLAG attribute so that consumers can distinguish active objects from logically deleted ones.

Underlying Base Objects

The documented base objects referenced by CZ_RP_DIRECTORY_V are:

  • CZ_RP_ENTRIES (SYNONYM) – contributes the base repository entry rows; in this branch NOTES is aliased to SYNOPSIS.
  • CZ_RP_EFF_DIRECTORY_V (VIEW) – contributes effectivity directory rows.
  • CZ_RP_PRJ_DIRECTORY_V (VIEW) – contributes project directory rows.
  • CZ_RP_USG_DIRECTORY_V (VIEW) – contributes usage directory rows.
  • CZ_UTILS (PACKAGE) – a supporting Configurator utility package associated with the repository infrastructure.

The view text performs a UNION (not UNION ALL) across the four directory branches, so duplicate rows produced by overlapping entries are eliminated. Each branch projects the identical column list, which makes the merged result set structurally consistent. The CZ_RP_EFF_DIRECTORY_V branch already surfaces a SYNOPSIS column, whereas the CZ_RP_ENTRIES branch maps NOTES AS SYNOPSIS, normalizing the naming across sources.

Key Columns

  • OBJECT_TYPE – classifies the repository object and is the primary discriminator when filtering by object category.
  • OBJECT_ID – the unique identifier of the object within its type, used for joins and lookups.
  • ENCLOSING_FOLDER – indicates the repository folder that contains the object, supporting hierarchical navigation.
  • NAME – the object's display name.
  • SYNOPSIS – a short summary; derived from NOTES in the CZ_RP_ENTRIES branch and native in the other branches.
  • DESCRIPTION – the full descriptive text for the object.
  • DELETED_FLAG – marks logical deletion; this is the column most often referenced by users searching on "deleted_flag" to exclude retired repository objects from reports and integrations.
  • CREATED_BY / CREATION_DATE – standard WHO audit columns recording creation.
  • LAST_UPDATED_BY / LAST_UPDATE_DATE – standard WHO audit columns recording the most recent change.

Common Use Cases and Queries

The most frequent use is a filtered listing of active repository objects. Because DELETED_FLAG governs logical deletion, report authors typically constrain on it to return only live rows:

  • Query all active objects of a given type:
    SELECT object_type, object_id, name, synopsis FROM cz_rp_directory_v WHERE deleted_flag = 'N' AND object_type = :p_type ORDER BY name;
  • Audit recently changed repository content:
    SELECT object_type, object_id, name, last_updated_by, last_update_date FROM cz_rp_directory_v WHERE last_update_date >= :p_since ORDER BY last_update_date DESC;
  • Identify deleted objects retained for history or troubleshooting:
    SELECT object_type, object_id, name, deleted_flag FROM cz_rp_directory_v WHERE deleted_flag = 'Y';
  • Browse folder contents:
    SELECT enclosing_folder, name, description FROM cz_rp_directory_v WHERE enclosing_folder = :p_folder AND deleted_flag = 'N';

Because the view is a UNION over four repository sources, no DML is possible against it; it is strictly a read interface. Consumers should also account for the row deduplication implied by UNION when reconciling counts against individual directory views.