Results for “tree_root_id”

2 results




Overview
Explore in AI Chat

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

Overview

Within Oracle E-Business Suite, the view APPS.CSP_NAV_NODE_TYPES belongs to the Spares Management (CSP) product family and carries a documented status of VALID. Its stated purpose is to expose metadata for the Navigator tree. In practice, the view is a thin projection over the underlying Navigator configuration view JTF_NAV_NODE_TYPES_V, re-publishing the same column set under the CSP schema namespace so that Spares Management functionality, personalizations, and dependent reports can reference node-type metadata through a CSP-branded object rather than the shared JTF object directly.

The Navigator tree in EBS is the hierarchical menu structure that determines how functions, forms, and HTML flows are presented to users. CSP_NAV_NODE_TYPES describes the individual node types that populate that tree — their identity, the flow or form that a node launches, the parameters passed to it, and the iconography used to render it. Because the object is a view, it is read-only by definition; it holds no data of its own and reflects the state of its base object at query time.

Underlying Base Objects

ETRM documentation records exactly one referenced base object: JTF_NAV_NODE_TYPES_V, itself a view. The CSP view is therefore a layered projection with no independent storage. The view text selects the full column list from that single source without joins, filters, aggregation, or a WHERE clause:

Because it is a straight pass-through, any change to the underlying JTF definition — or to the base tables beneath it — is immediately visible through CSP_NAV_NODE_TYPES. No CSP-specific filtering is applied, so consumers receive the entire node-type population maintained for the Navigator, not merely those nodes used by Spares Management.

Key Columns

The columns divide into several logical groups:

  • Identity and hierarchy: TREE_ROOT_ID ties a node type to a specific Navigator tree root, while NODE_TYPE_ID, ROOT_KEY, and NODE_TYPE identify the node and its classification.
  • Flow and page routing: AK_FLOW_NAME, AK_PARENT_PAGE_NAME, and AK_PK_NAME drive Oracle Application Framework (OAF) navigation, indicating the flow invoked, the parent page context, and the primary key attribute used to resolve the target entity.
  • Data restriction: AK_WHERE_CLAUSE and AK_WHERE_BINDS supply the predicate and bind variables applied when the node is opened, enabling context-sensitive queries keyed to the selected record.
  • Presentation: ICON_NAME controls the displayed icon; FORM_NAME and FORM_PARAM_LIST identify a Forms-based destination and the parameter string passed to it; STATIC_CHILD_FLAG indicates whether children are statically defined.
  • Audit columns: CREATED_BY, CREATION_DATE, LAST_UPDATE_LOGIN, LAST_UPDATE_DATE, and LAST_UPDATED_BY follow standard EBS WHO-column conventions.

Common Use Cases and Queries

Typical uses include diagnosing why a Navigator node fails to launch, auditing which flow or form a node targets, and extracting node configuration for documentation or migration comparison. The following returns all node types for a given tree root:

  • SELECT node_type_id, node_type, ak_flow_name, form_name, icon_name FROM apps.csp_nav_node_types WHERE tree_root_id = :root_id ORDER BY node_type_id;

To locate nodes referencing a specific form or flow:

  • SELECT tree_root_id, node_type, form_name, form_param_list FROM apps.csp_nav_node_types WHERE form_name = :form_name;

Because the object is a read-only view over shared Navigator metadata, it should be used exclusively for query and reporting purposes; adjustments to node definitions must be made through the corresponding maintenance interface, not through DML against this view.