Search Results cz_ui_typedpsn_v




Overview
Explore in AI Chat

Overview

CZ_UI_TYPEDPSN_V is a Configurator (CZ) view owned by the APPS schema. It exposes the rows of CZ_PS_NODES, the persistent store of node definitions that describe the structure of a configurable model — the "PS" prefix denotes the persistent node layer produced when a Configurator model is published or instantiated. The view is used by the Oracle Configurator user interface and by downstream reporting or integration logic that needs a flat, readable projection of those node definitions without direct access to the base table.

The name CZ_UI_TYPEDPSN_V indicates its intent: it is a UI-oriented ("UI") view over typed persistent nodes ("TYPED PSN"). It is declared VALID in the EBS 12.1.1/12.2.2 data dictionary and selects from a single base object, CZ_PS_NODES, which is exposed in the APPS schema as a synonym. The documented metadata also lists CZ_TYPES (PACKAGE), reflecting the Configurator type system that governs node behavior; the view itself does not join to that package but the runtime semantics depend on it.

Underlying Base Objects

The view is defined over two documented referenced objects:

  • CZ_PS_NODES (SYNONYM) — the persistent node table; the view selects all of its columns with no join or filter.
  • CZ_TYPES (PACKAGE) — the Configurator PL/SQL type package whose definitions supply the type context for the nodes exposed by the view.

Because the view is essentially a straight column-list projection of CZ_PS_NODES, it carries no aggregation, no WHERE clause, and no derived expressions. This means row counts, data types, and value domains are identical to the underlying table for every mapped column. Any restriction applied at query time — by node type, product flag, effective date, or deleted flag — must be supplied by the caller.

Key Columns

The view exposes the full public surface of a persistent node. Principal columns include:

The user's search term parent_persistent_node_id corresponds to the parent-linking logic represented here by PARENT_ID combined with PERSISTENT_NODE_ID; a "parent persistent node" is resolved by joining a child row's PARENT_ID to the parent row's PS_NODE_ID/PERSISTENT_NODE_ID.

Common Use Cases and Queries

Typical uses include validating model structure before publishing, exporting node hierarchies for integration, and troubleshooting configuration rules. A common pattern walks the hierarchy from a root node:

  • Retrieve all active nodes for a model: SELECT PS_NODE_ID, NAME, PS_NODE_TYPE, PRODUCT_FLAG FROM CZ_UI_TYPEDPSN_V WHERE DEVL_PROJECT_ID = :project_id AND DELETED_FLAG = 'N'.
  • Find children of a node: SELECT PS_NODE_ID, NAME FROM CZ_UI_TYPEDPSN_V WHERE PARENT_ID = :parent_node_id.
  • Resolve the parent-persistent relationship: self-join CZ_UI_TYPEDPSN_V p, CZ_UI_TYPEDPSN_V c WHERE c.PARENT_ID = p.PS_NODE_ID to map each node to its parent's persistent identifier.
  • Enumerate product-bearing leaves: SELECT PS_NODE_ID, NAME, COMPONENT_ID FROM CZ_UI_TYPEDPSN_V WHERE PRODUCT_FLAG = 'Y' AND INSTANTIABLE_FLAG = 'Y'.

Because the view applies no filtering, callers should always constrain by DEVL_PROJECT_ID, DELETED_FLAG, and when relevant the effectivity columns to obtain meaningful results.