Search Results get_psn_addrss




Overview

HR_VIEW_ALERT_UTILITIES is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM metadata as an "OTHER" API type rather than a formal public API. Its source header (pervautl.pkb) and the naming conventions of its routines indicate that it forms part of the Oracle HRMS alerting and notification infrastructure, specifically the components that render person-related information for display within the Oracle Applications alert framework. The package acts as a thin wrapper layer: rather than implementing business logic itself, each of its functions delegates directly to a corresponding routine in HR_BPL_ALERT_ADDRESS, the underlying business logic package that performs the actual data retrieval. This design pattern isolates the alert presentation layer from the core HR business logic, allowing the underlying address and contact retrieval routines to evolve without affecting the alert utilities interface. Given the package header revision date (2003) and its survival into EBS 12.1.1 and 12.2.2, it is a long-standing, stable component used to populate the text bodies or variable tokens of HR-related alerts.

Key Procedures and Functions

The ETRM metadata documents two functions in this package body:

  • GET_PSN_ADDRSS — Returns a single concatenated string containing the formatted address of a person. This is the routine surfaced when users search for the term "get_psn_addrss". It accepts a person identifier and returns a VARCHAR2 result. Internally, the body simply returns the value produced by HR_BPL_ALERT_ADDRESS.get_psn_addrss, passing the person identifier through unchanged. The function is intended to collapse a person's multi-line address into one display-ready string suitable for an alert message.
  • GET_PSN_EMRG_CONTACTS — Returns a single string containing the emergency contacts associated with a person. Like the address function, it is a pass-through wrapper that returns the result of HR_BPL_ALERT_ADDRESS.get_psn_emrg_contacts for the supplied person identifier. It provides alert authors with a convenient way to embed emergency contact details in notification text.

Both functions share the same input convention (a person identifier) and the same return convention (a single VARCHAR2 string), reflecting their common purpose of producing flat, alert-ready text from HR person data.

Tables Accessed

The documented metadata for HR_VIEW_ALERT_UTILITIES lists no tables referenced directly through APPS synonyms. This is consistent with the package's wrapper design: all SQL and table access is encapsulated within HR_BPL_ALERT_ADDRESS and its own dependencies, which retrieve person address and emergency contact information from the underlying HR person and address entities. Consequently, HR_VIEW_ALERT_UTILITIES itself performs no direct reads or writes, and any performance or data-visibility considerations belong to the delegated business logic package.

Usage Notes

The ETRM metadata records no other packages referencing HR_VIEW_ALERT_UTILITIES, indicating that it is invoked from outside the PL/SQL package dependency graph — most likely from the Oracle Alert definition framework, where alert message text can incorporate PL/SQL function calls, or from Oracle HRMS self-service and view-based flows that render alert content. Typical invocation scenarios include:

  • Oracle Alert message bodies that need the current address or emergency contacts of a person as a text token.
  • HRMS notification and viewing components that assemble person summary text for display.
  • Custom code that needs a stable, alert-oriented interface to person address and contact strings without calling HR_BPL_ALERT_ADDRESS directly.

Because the routines are pass-through wrappers, behavior is entirely determined by HR_BPL_ALERT_ADDRESS; callers should consult that package for validation rules, error handling, and handling of persons with no address or contacts on file. The package should be treated as read-only and internal to the alerting infrastructure rather than as a general-purpose HR API.