Search Results cn_hierarchy_nodes_s

Overview

CN_DIHY_TWO_API_PKG is an Oracle E-Business Suite application programming interface package body owned by the APPS schema. It belongs to the Oracle Channel Intelligence / Network (CN) product family, specifically the module responsible for managing hierarchy definitions used in trade management and channel operations. Within ETRM 12.1.1 and 12.2.2, the package is classified with an API classification of OTHER, indicating it is an internal or supporting API rather than a publicly documented interface.

The package provides the low-level procedural layer for manipulating hierarchy structures stored in the CN_HIERARCHY_NODES and CN_HIERARCHY_EDGES tables. A hierarchy in this context consists of nodes (the individual members or entities) and edges (the parent-child or directional relationships that define the structure). CN_DIHY_TWO_API_PKG encapsulates the insert and delete operations required to maintain those node and edge records consistently, shielding callers from the underlying table mechanics such as sequence-valued primary keys and denormalized relationship maintenance.

Key Procedures and Functions

The documented package exposes three procedures, all focused on write operations against the hierarchy model:

• INSERT_EDGE — Creates a new edge record that establishes a relationship between two hierarchy nodes. This procedure is the primary mechanism for building or extending a hierarchy graph, and it is responsible for populating the edge definition so that traversal and reporting logic can resolve parent-child paths correctly.
• INSERT_DIMENSION — Inserts a dimension definition associated with the hierarchy. Dimensions provide the classification axis along which hierarchy nodes are grouped, and this procedure ensures the dimension entry is persisted in the CN schema tables so that downstream hierarchy queries can filter and organize nodes by dimension.
• CASCADE_DELETE — Removes hierarchy data while propagating the deletion through dependent records. Rather than leaving orphaned edges or nodes, this procedure walks the affected structure and deletes the associated rows, preserving referential integrity across the hierarchy node and edge tables.

No parameter lists are documented in the ETRM metadata, and codified signatures should be confirmed by inspecting the package specification in the target environment.

Tables Accessed

The package operates against the following tables, all referenced through APPS synonyms:

• CN_HIERARCHY_NODES — Stores the hierarchy node definitions that anchor the structure.
• CN_HIERARCHY_NODES_S — The sequence-backed key source for hierarchy node identifiers. This is the object most closely associated with the user's search term; the package relies on it to allocate unique node keys during insert operations.
• CN_HIERARCHY_EDGES — Stores the edge relationships linking nodes, written by INSERT_EDGE and cleaned up by CASCADE_DELETE.
• CN_OBJECTS — The registry of CN objects, consulted to validate or resolve the object context to which a hierarchy belongs.
• DUAL — Used for scalar evaluations and sequence lookups within PL/SQL statements.

Usage Notes

CN_DIHY_TWO_API_PKG is an internal API. The ETRM metadata records that it is referenced by two other packages, meaning it is normally invoked indirectly from higher-level CN hierarchy processing packages rather than called directly from forms or user interfaces. Typical invocation paths include concurrent programs that bulk-load or rebuild channel hierarchies, and setup or migration routines that programmatically construct hierarchy definitions.

Because the package manipulates core CN hierarchy tables, custom code should treat it as a controlled entry point: callers must supply valid object and node context, and should invoke CASCADE_DELETE rather than issuing direct DML against CN_HIERARCHY_EDGES and CN_HIERARCHY_NODES. The package is not referenced by any database object in the reverse direction beyond the two dependent packages, confirming its role as a leaf-level utility within the CN hierarchy API stack. Always verify the package specification in the specific EBS instance, since signatures and internal behavior can vary between 12.1.1 and 12.2.2 patch levels.