Search Results aso_wfnotification_s2

Overview

ASO_WFNOTIFICATION_PVT is a private (PVT classification) PL/SQL package body owned by the APPS schema in Oracle E-Business Suite. It belongs to the Oracle Order Capture / Sales Order Notification component (ASO) and provides the internal implementation layer for workflow-based notifications. In the Oracle EBS architecture, a "PVT" package is the private counterpart to a public API package; it is not intended for direct invocation by external applications but instead supplies the worker procedures consumed by the package specification and by other ASO modules.

The package's business role is to generate and dispatch Oracle Workflow notifications in response to sales order and quote events, such as notifying a user or sending an email when an order lifecycle event requires attention. It does so by composing notification content and delegating delivery to the Oracle Workflow engine (WF_ENGINE, WF_CORE, WF_DIRECTORY). The ETRM metadata lists the object as VALID in both 12.1.1 and 12.2.2, and records that it is not referenced by any database object — a typical signature of a private implementation package whose entry points are called indirectly.

Key Procedures and Functions

The ETRM documentation records two procedures within this package body:

• NOTIFY_USER — Constructs and submits a workflow notification directed at a specific recipient. It resolves the recipient through the Workflow directory services and hands the notification to the Workflow engine for queuing and delivery. This is the general-purpose entry point for user-directed alerting from the ASO notification framework.
• SEND_EMAIL — Generates an email-style notification and dispatches it through the Workflow mailer infrastructure. It is used when the notification channel is email rather than an in-application Workflow notification, and typically relies on the same directory and engine dependencies as NOTIFY_USER.

Both procedures depend on ASO_DEBUG_PUB for diagnostic message logging, FND_API for the standard EBS API error-handling and message conventions, and the Workflow packages for message construction and dispatch. Parameter signatures are not reproduced in the ETRM excerpt and should be confirmed against the live package specification before any direct use.

Tables Accessed

The documented table references are resolved through APPS synonyms:

• ASO_WFNOTIFICATION_S1 — A sequence used to generate unique identifiers for notification records or notification payloads. Its presence implies that the package creates identifiable notification instances rather than issuing fully transient messages.
• ASO_WFNOTIFICATION_S2 — A second sequence, used in parallel with S1, most likely for a distinct key column or a separate notification entity within the same functional area. Because both sequences appear in the dependency list, the package evidently supports more than one notification key.
• DUAL — Used for singleton SELECT expressions, typically to fetch sequence NEXTVAL values or to evaluate expressions without touching a base table.

The absence of base tables in the documented dependency set indicates that persistent storage of notification content is handled elsewhere; this package is primarily a construction and dispatch layer.

Usage Notes

ASO_WFNOTIFICATION_PVT is not a public API and should not be called directly from custom code. It is invoked internally by the ASO notification framework and, per the ETRM dependency information, it references itself (recursive or overloaded internal calls) and the ASO_WFNOTIFICATION_PVT specification. The metadata states it is not referenced by any database object, so callers are PL/SQL-level rather than schema-level dependencies.

In practice, notifications are triggered when Business Events or Order Management workflow processes raise an alert condition. Developers extending this area should call the public wrapper package rather than this private body, and should reproduce its behavior only when a supported extension point is unavailable. Because both the Workflow directory and engine are dependencies, any custom invocation must run in a session with a valid Workflow item type, item key, and role context, otherwise notification addressing will fail. All calls should also honor the standard FND_API message and error conventions used throughout the package.