Search Results xnc_nav_node_types_v




Overview
Explore in AI Chat

Overview

XNC_NAV_NODE_TYPES_V is a reporting and integration view within the Oracle E-Business Suite Release 12.1.1 and 12.2.2 environment. It belongs to the XNC product family, Sales for Communications, which is flagged in the ETRM metadata as obsolete. The view does not store data of its own; it is a thin, pass-through definition built directly on the JTF_NAV_NODE_TYPES_V view, itself part of the JTTF/CRM navigation infrastructure.

The object serves a specific and narrow architectural purpose. According to the documented description, it is "used as start point of all flows used in Sales for Communications." In other words, it describes the atomic navigation node types that the Sales for Communications application flows begin from, exposing metadata about node types rather than transactional business data. Because the product module is obsolete, the view is primarily relevant to environments that still carry legacy XNC customizations, historical data migrations, or audit/inventory reviews of obsolete objects. The ETRM 12.2.2 implementation notes state that the view is "not implemented in this database," indicating that in the documented release the object may not exist or may be created only conditionally by the XNC schema installation.

Underlying Base Objects

The view is defined over a single referenced object: JTF_NAV_NODE_TYPES_V, aliased in the view text as JNT. No other documented base objects are associated with it, and ETRM records no additional referenced base objects beyond this dependency. The definition is a direct column projection with no joins, filters, or transformations:

SELECT TREE_ROOT_ID, NODE_TYPE_ID, ROOT_KEY, NODE_TYPE, AK_FLOW_NAME, AK_PARENT_PAGE_NAME, AK_PK_NAME, AK_WHERE_CLAUSE, AK_WHERE_BINDS, ICON_NAME, FORM_NAME, FORM_PARAM_LIST, STATIC_CHILD_FLAG, CREATED_BY, CREATION_DATE, LAST_UPDATE_LOGIN, LAST_UPDATE_DATE, LAST_UPDATED_BY FROM JTF_NAV_NODE_TYPES_V JNT

Because it is a straight projection, the row set of XNC_NAV_NODE_TYPES_V is identical to that of JTF_NAV_NODE_TYPES_V, and any change to the underlying view propagates directly. The object carries standard Oracle EBS audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN), reflecting the underlying table structure rather than any logic added in this view.

Key Columns

The columns exposed by the view describe navigation tree structure and Oracle Application Framework (AK/ OAF) flow metadata:

  • TREE_ROOT_ID / NODE_TYPE_ID / ROOT_KEY — Identifiers linking each node type to its navigation tree root and its unique node type key.
  • NODE_TYPE — The classification of the navigation node.
  • AK_FLOW_NAME / AK_PARENT_PAGE_NAME — The OAF flow and parent page used to launch the node's target function.
  • AK_PK_NAME / AK_WHERE_CLAUSE / AK_WHERE_BINDS — The primary key name, query predicate, and bind variables used to resolve the target entity for the node.
  • ICON_NAME / FORM_NAME / FORM_PARAM_LIST — Presentation attributes: the icon, the Oracle Forms executable, and the form parameter list.
  • STATIC_CHILD_FLAG — Indicates whether child nodes are statically defined rather than dynamically resolved.
  • Audit columns — Standard who/when columns inherited from the base object.

Common Use Cases and Queries

Because the view is a direct projection, typical use is investigative or diagnostic rather than operational reporting. Common scenarios include identifying which navigation node types drive Sales for Communications flows, tracing OAF flow names and forms behind a node, and auditing obsolete XNC objects prior to decommissioning or upgrades from 12.1.1 to 12.2.2.

Sample queries include:

  • SELECT NODE_TYPE_ID, NODE_TYPE, AK_FLOW_NAME, FORM_NAME FROM XNC_NAV_NODE_TYPES_V ORDER BY NODE_TYPE_ID;
  • SELECT ROOT_KEY, AK_PARENT_PAGE_NAME, AK_WHERE_CLAUSE FROM XNC_NAV_NODE_TYPES_V WHERE STATIC_CHILD_FLAG = 'Y';
  • SELECT TREE_ROOT_ID, COUNT(*) FROM XNC_NAV_NODE_TYPES_V GROUP BY TREE_ROOT_ID;

Given the obsolete status of XNC, administrators confirming object existence should first verify its presence in DBA_VIEWS, since the ETRM metadata records it as not implemented in the documented database.