Search Results validate_floating_revision

Overview

APPS.ENG_RELATED_ENTITY_PKG is an Oracle Engineering (ENG) module PL/SQL package that supports the management of related-entity relationships and floating revision validation within Oracle E-Business Suite. It is declared with AUTHID CURRENT_USER, meaning that its SQL statements execute with the privileges of the invoking user rather than the package owner, which is consistent with the Oracle Applications "APPS" schema convention for packages that are invoked directly from client-side forms or concurrent programs. The package header bears the source control identifier ENGRENTS.pls 120.2, dated 2006, indicating a long-standing component of the Engineering foundation. Its responsibilities fall into two areas: (1) a general-purpose debugging utility set that allows callers to open a session, write messages, and close the session against a server-side file, and (2) business APIs that implement relationship changes for a given engineering change and validate floating revisions. The package is classified as API type OTHER in the ETRM metadata and is not referenced by any other documented package, so it is a leaf-level utility used principally by Engineering forms, concurrent programs, or custom extensions.

Key Procedures and Functions

• OPEN_DEBUG_SESSION — Initializes a debug session, optionally accepting an output directory and file name. Callers invoke it before writing debug messages so that a target log file is established.
• CLOSE_DEBUG_SESSION — Terminates the debug session and releases the associated file handle. It is the counterpart to OPEN_DEBUG_SESSION.
• WRITE_DEBUG — Writes a caller-supplied debug message to the active debug session output. It is intended for diagnostic logging during API execution.
• IMPLEMENT_RELATIONSHIP_CHANGES — The principal business API. It applies relationship changes associated with a specified change identifier and entity identifier. Its signature follows the Oracle Applications API standard, including API version, initialization of the message list, commit control, validation level, and debug flags (output directory and debug file name, defaulting to ENGRENTB.Implement_Relationship_Changes.log), returning the standard x_return_status, x_msg_count, and x_msg_data outputs.
• VALIDATE_FLOATING_REVISION — Validates a floating revision, taking an API version, change identifier, and an optional revision item sequence identifier, and returning the standard status and message outputs.

Tables Accessed

The ETRM metadata records two referenced objects, both exposed through APPS synonyms and both related to the package's debug infrastructure rather than to its business logic. UTL_FILE is the Oracle-supplied PL/SQL file I/O package used by OPEN_DEBUG_SESSION, WRITE_DEBUG, and CLOSE_DEBUG_SESSION to read and write server-side log files. V$PARAMETER is a dynamic performance view typically consulted to obtain the value of the utl_file_dir initialization parameter (or equivalent), so that the debug routines can resolve a valid output directory. No engineering base tables are documented as directly referenced, which suggests that the relationship-change and revision-validation logic is delegated to underlying APIs or to SQL executed dynamically, and that the documented table list captures only the utility dependencies.

Usage Notes

Because this package is classified as API type OTHER and is not referenced by other packages, it is normally invoked from Engineering-related forms, concurrent programs, or custom code rather than in a chained package call. The debug subprograms are designed to be used in a three-step sequence: OPEN_DEBUG_SESSION, one or more WRITE_DEBUG calls, and CLOSE_DEBUG_SESSION. They depend on a writable server directory configured for UTL_FILE via the database initialization parameter, and should therefore be reserved for controlled diagnostic scenarios. IMPLEMENT_RELATIONSHIP_CHANGES should be called with an appropriate API version and with p_commit set according to the caller's transaction strategy; when p_commit is FALSE, the caller retains control of the commit boundary. Callers should always inspect x_return_status and drain the message list using x_msg_count and x_msg_data before proceeding. VALIDATE_FLOATING_REVISION offers a non-destructive check that can be invoked before or independently of the implementation call.