Search Results hr_multi_message




Overview
Explore in AI Chat

Overview

HR_MULTI_MESSAGE is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It provides a centralized, reusable mechanism for accumulating and managing multiple validation errors during a single processing cycle, rather than aborting at the first error encountered. This capability is fundamental to Oracle HRMS forms and APIs, where a user or calling program may submit a record with several simultaneous data problems that should all be reported together.

The package is state-driven. A private global Boolean, g_multi_list_disabled, defaults to TRUE, meaning the "stop at first error" behavior is the baseline. When multiple-error collection is explicitly switched on, validation routines cooperate by appending messages instead of raising immediately, and the verifying functions return a continuing TRUE so downstream checks still run. The underlying message store is the standard Oracle Application Object Library message dictionary, accessed through FND_MSG_PUB. Although the package references only a small number of objects directly, it is referenced by 2,305 other packages, indicating that it sits at the base of the HRMS validation stack and is treated as shared infrastructure rather than a feature-specific utility.

Key Procedures and Functions

  • ENABLE_MESSAGE_LIST — Turns on multiple-error detection. It first calls FND_MSG_PUB.INITIALIZE to empty any residual message list, then clears the disabled flag so that subsequent validations accumulate messages.
  • DISABLE_MESSAGE_LIST — Turns multiple-error detection off without clearing the list, because the user interface may still need to retrieve messages already collected. Once disabled, no new messages are added and verify functions revert to returning FALSE at the first failure.
  • IS_MESSAGE_LIST_ENABLED — Returns the current state of the multi-list flag, allowing calling code to branch between accumulate-and-continue and stop-at-first-error logic.
  • NO_ERROR_MESSAGE — The documented counterpart to the user's search term "no_error_message"; it expresses the condition that no error message exists for the current context, supporting guard checks before a message is raised or displayed.
  • NO_ALL_INCLUSIVE_ERROR and NO_EXCLUSIVE_ERROR — Validate whether the accumulated list contains errors of the all-inclusive or exclusive variety, distinguishing soft warnings from blocking conditions.
  • ADD and EXCEPTION_ADD — Add a message to the list; EXCEPTION_ADD specifically records a message derived from a raised exception.
  • UNEXPECTED_ERROR_ADD — Registers an unexpected or unhandled error condition, typically for diagnostic reporting.
  • END_VALIDATION_SET — Closes a validation set, finalizing the collected messages for the cycle.
  • GET_RETURN_STATUS and GET_RETURN_STATUS_DISABLE — Report the overall validation outcome and, in the latter case, disable further message collection as part of returning status.

Tables Accessed

The documented table reference is FND_APPLICATION, read to resolve application context used when generating and formatting messages. Message text and numbering are maintained through the AOL message dictionary APIs, primarily FND_MSG_PUB.INITIALIZE and the standard message-retrieval calls, which read the underlying message tables indirectly rather than through direct DML in this package. No customer or HRMS transactional tables are touched.

Usage Notes

HR_MULTI_MESSAGE is invoked from HRMS forms (particularly the Datablock validation triggers and the "verify" style library routines), from PL/SQL validation packages that must report several field-level errors in one pass, and from concurrent or batch programs that aggregate data errors before rejecting a run. A typical custom usage pattern is to call ENABLE_MESSAGE_LIST on entry, invoke the business validation routines, call END_VALIDATION_SET, and then use GET_RETURN_STATUS to decide whether to commit or roll back. Because the package is "noship" and heavily depended upon across releases 12.1.1 and 12.2.2, customizations should treat it as read-only infrastructure: call its documented procedures rather than modifying package source, and never assume the message list is automatically cleared except by ENABLE_MESSAGE_LIST.