Search Results get_parent

Overview

XNP_MSG_SCHEMA is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the XNP module, the messaging and integration infrastructure used by Oracle's supply chain and Advanced Planning applications to exchange XML and flat-file messages between systems. The package's central responsibility is the validation of message structures before they are used at runtime. It confirms that a given message code is internally consistent — that each declared message element is backed by a legitimate database object or data source, that parent/child relationships in the message structure are well formed, and that references into parameter pools resolve correctly. In effect, XNP_MSG_SCHEMA acts as the compiler-checking layer for the message definitions stored in the XNP repository.

Key Procedures and Functions

The documented ETRM metadata lists VALIDATE as the single externally classified procedure, although the package source exposes additional private helpers that support it. VALIDATE accepts a message code and returns an error code and error message; it is the entry point through which callers request a full consistency check of a message definition. Internally, VALIDATE drives a cursor that joins message elements to message structures and iterates over each element, applying the rules defined in the package. Supporting logic includes CHECK_SOURCE, which examines an element's source type, data source, and data reference; CHECK_EXISTS, which determines whether a database object already exists with the same name as the message code (a duplicate-object condition); CHECK_PARAMETER_POOL, which verifies that a referenced parameter exists in the appropriate pool; and CHECK_IF_PARENT. The query term "get_parent" corresponds to this parent-relationship logic: CHECK_IF_PARENT returns an indicator of whether the supplied element identifier acts as a parent within the message structure, which VALIDATE uses to decide whether an element legitimately requires a data source or may instead serve purely as a structural container. Errors are raised through the FND_MESSAGE framework using tokens such as the element name, and error codes are drawn from the XNP_ERRORS package (for example, g_duplicate_object) and the XNP message dictionary.

Tables Accessed

The package reads three documented tables, all through APPS synonyms. XNP_MSG_ELEMENTS holds the message element definitions — name, element identifier, and parameter flag — and supplies the driving rows for validation. XNP_MSG_STRUCTURES stores the structural mapping between message codes and their child elements, including data source, data source type, and data source reference; the join between these two tables forms the get_msg_data cursor that VALIDATE loops over. USER_OBJECTS is queried by CHECK_EXISTS to detect naming collisions between a message code and existing database objects. The package is predominantly read-only against these tables, performing verification rather than maintenance of message definitions.

Usage Notes

XNP_MSG_SCHEMA is not an end-user-facing API. It is invoked programmatically when message definitions are created, imported, or activated — typically from the XNP message administration forms, from concurrent programs that load message metadata, or from setup validation routines executed during implementation. The ETRM metadata records one dependent package referencing it, indicating that it functions as a shared validation utility within the XNP stack. Custom integrators working with XNP-based interfaces may call VALIDATE directly from custom PL/SQL to confirm that a newly registered message code is structurally sound before attempting to generate or consume messages. Because VALIDATE returns status through out parameters rather than raising exceptions for ordinary validation failures, callers must inspect the returned error code and message explicitly. The package is generated from the XNPMBLVB.pls source file and is maintained under the standard EBS patching mechanism; custom modifications should not be applied, as they will be overwritten by future patches.