Search Results validate_rich_messages

Overview

APPS.FUN_RULE_VALIDATE_PKG is a server-side PL/SQL validation package belonging to the Oracle E-Business Suite "Rules" module (FUN = the component prefix associated with the Foundation/Rules engine area). Its role is to centralize the business-rule checks applied to records created or modified through the Rules public APIs. Rather than embedding validation logic inside each entity's Public API package (FUN_RULE_OBJECTS_PUB, FUN_RULE_CRITERIA_PUB, FUN_RULE_CRIT_PARAMS_PUB, FUN_RULE_DETAILS_PUB and others), the Rules module routes validation through this single reusable package. The package is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the calling schema rather than the definer, consistent with standard APPS public API conventions. It is documented as an "OTHER" classification object, referenced by six other packages, and exposes nineteen documented procedures and functions that collectively enforce existence, mandatory, uniqueness, non-updateability, lookup, flexfield, and key-column validity for Rules entities.

Key Procedures and Functions

The package provides granular validators, most of which accept a create/update flag, an entity record, a ROWID, and an IN OUT NOCOPY return status. The principal documented routines are:

• CHECK_EXISTENCE_RULES_OBJECT — verifies that a user-customizable rule object exists for the specified rule object name and application.
• CHECK_ERR — inspects the return status, typically used to short-circuit processing when a prior validation failed.
• VALIDATE_RULE_OBJECTS — validates a rule objects record, driving the standard object-level checks.
• VALIDATE_RULE_OBJECT_INSTANCE — validates an individual rule object instance record.
• VALIDATE_RULE_CRITERIA_PARAMS — validates rule criteria parameter records against the criteria/parameter definitions.
• VALIDATE_RULE_DETAILS — validates rule detail records.
• VALIDATE_RULE_CRITERIA — validates rule criteria records.
• VALIDATE_RICH_MESSAGES — validates rich message records (declared but commented out in the header shown, retained for compatibility).
• VALIDATE_MANDATORY — enforces that required (mandatory) columns have been supplied for the entity being processed.
• VALIDATE_NONUPDATEABLE — enforces that columns designated non-updateable are not changed on an update. This is the routine most commonly targeted by the search term "validate_nonupdateable".
• VALIDATE_NONUPDATEABLE_ATALL — enforces that certain columns may never be updated on an existing record.
• VALIDATE_LOOKUP — checks that a supplied value is a valid lookup code.
• ISFLEXFIELDVALID — confirms that a flexfield value/combination is valid.
• VALIDATE_ORG_ID, VALIDATE_APPLICATION_ID, VALIDATE_FLEX_VALUE_SET_ID — key-column validators confirming the existence and validity of organization, application, and flex value set identifiers.

Tables Accessed

The package reads and, where applicable, writes through APPS synonyms to Rules and Foundation tables, including FUN_RULE_OBJECTS_B and FUN_RULE_OBJECTS_TL, FUN_RULE_CRITERIA, FUN_RULE_CRIT_PARAMS_B and FUN_RULE_CRIT_PARAMS_TL, FUN_RULE_DETAILS, FUN_RULE_OBJ_ATTRIBUTES, FUN_RICH_MESSAGES_B, plus FND_LOOKUP_VALUES and SO_LOOKUPS for lookup validation. It also references DBMS_SQL, DBMS_UTILITY, and PLITBLM (the PL/SQL table/array utility library) for dynamic SQL execution and table-driven validation.

Usage Notes

FUN_RULE_VALIDATE_PKG is not typically invoked directly by end users. It is called by the Rules module's Public API packages during insert and update processing, which in turn are invoked from the Foundation/Rules setup forms (for example, rule definition and rule object maintenance screens) and from concurrent programs that load or migrate Rules metadata. Custom code extending the Rules module should call the corresponding Public API rather than this validator, because the Public API orchestrates the calls to VALIDATE_MANDATORY, VALIDATE_NONUPDATEABLE, and the entity-level validators in the required sequence and raises the appropriate error messages. When developing custom Rules extensions, callers should pass a valid p_create_update_flag ('CREATE' or 'UPDATE') and a populated record; the validate_nonupdateable routines specifically inspect the update path to prevent modification of protected key columns.