Search Results ps_node_type_connector

Overview

APPS.CZ_TYPES is a configuration-oriented PL/SQL package body belonging to the Oracle EBS Configure-to-Order (CTO) module, and specifically to the Oracle Configurator / Configurator Developer component identified by the CZ_ prefix. In Oracle EBS 12.1.1 and 12.2.2 it acts as a metadata resolution utility layer that translates raw configuration model rows into the semantic information the Configurator runtime and the Configurator Developer UI need in order to render and validate a model. Its responsibilities include determining whether a model node participates in a mutually exclusive (mutex) selection group, identifying the persisted identity of a node, resolving signature identifiers for UI and rule elements, and classifying node and property availability. Because these answers are required by many different configurator surfaces, the package is intentionally narrow in scope but very widely referenced; the documented metadata shows it is referenced by 24 other packages, confirming its role as a shared, low-level service rather than an end-user API. The source header dates the current body revision to 2007, indicating the package has been stable across the 12.1.1 and 12.2.2 releases, with no functional change required by the 12.2 online patching and editioning model beyond the standard APPS synonym and editioning treatment.

Key Procedures and Functions

• IS_MUTEX — The dominant routine in the package, provided in multiple overloaded forms (function and procedure variants). It determines whether a node is part of a mutex selection group. The implementation logic documented in the source considers the node's maximum_selected attribute and the number and required-flag status of its child nodes in CZ_PS_NODES, returning a flag indicating whether the group behaves as mutually exclusive.
• GET_PS_NODE_TYPE — Returns the type classification of a given PS (product structure) node, allowing callers to branch behaviour based on node semantics.
• NODE_TYPE_AVAILABLE — Indicates whether a particular node type is available or applicable in the current model context; used as a guard before a node type is offered or processed.
• NODE_USER_PROPS_AVAILABLE — Determines whether user-defined properties exist for a node, so that UI code can decide whether to expose user property sections.
• NODE_CAPTION_PROPS_AVAILABLE — Determines whether caption properties exist for a node, controlling the display of caption-related attributes.
• GET_PERSISTENT_NODE_ID — Resolves the persistent (stored) identifier for a node, distinguishing the durable identity from any transient runtime identifier.
• GET_UI_SIGNATURE_ID and GET_RULE_SIGNATURE_ID — Return the signature identifiers associated with UI elements and with rule elements respectively; these signatures are used to detect change and to key cached metadata.
• IS_IT_REGION — Classifies whether a given element represents an "it" region, supporting layout and containment decisions in the Configurator UI.

The overloaded IS_MUTEX forms are the only routines whose parameter structure is documented in the supplied excerpt; no parameter lists are asserted here for the remaining routines.

Tables Accessed

The package operates against a small, tightly defined set of tables, all reached through APPS synonyms. CZ_PS_NODES is the primary table; it holds the product structure nodes that make up a configuration model, and it supplies the maximum_selected, parent_id, bom_required_flag and deleted_flag values on which the mutex determination depends. Queries consistently filter on deleted_flag = '0', so logically deleted nodes are excluded from all activation and availability calculations. CZ_DEVL_PROJECTS provides the Configurator Developer project context, tying nodes and signatures back to the model version under development. DUAL is used for expression evaluation and constant returns. The package is read-oriented in the documented excerpt; the metadata does not evidence direct inserts or updates to these tables.

Usage Notes

CZ_TYPES is a server-side internal API rather than a user-facing entry point. It is invoked from Oracle Configurator runtime code, from Configurator Developer UI logic, and from the numerous dependent packages and forms that need authoritative answers about node types, mutex behaviour, and signature identity. Because the mutex functions are deterministic for a given node and model state, they are commonly called repeatedly during UI rendering and validation; this makes the rownum-bounded child count in the IS_MUTEX logic a deliberate performance measure. Customizations should call the packaged functions rather than reading CZ_PS_NODES directly, so that deleted-flag filtering and the maximum_selected rules remain consistent. Any extension work should treat the IS_MUTEX overload family as the reference implementation of mutex semantics, since downstream configurator behaviour — including which options may be selected together — depends on its output.