Search Results evaluate_alerts




Overview
Explore in AI Chat

Overview

The APPS.ASP_SERVICE_ALERT_AGENT package is a PL/SQL agent component within the Oracle E-Business Suite Service (TeleService / Service Request) application. Its principal business function is to evaluate alert conditions defined against service objects and to determine the set of subscribers who should receive notification for each alert. In the EBS alerting architecture, an "agent" acts as the runtime executor that bridges an alert definition to the notification infrastructure; ASP_SERVICE_ALERT_AGENT fills that role specifically for service-related alerts dispatched through SMS and EMAIL channels.

The package is owned by APPS and is classified as OTHER in the API classification scheme, meaning it is an internal, non-public-API component rather than a formally supported extension interface. Seeded records indicate the package is not referenced by any other documented package, confirming that it is typically invoked directly by the alert engine or workflow runtime rather than being called by peer PL/SQL units. The header of the source file (aspaesas.pls, version 120.1) and the creation history (created 10-Aug-2005 by axavier) place the package's origin in the 11i-era codebase, from which it carried forward into the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The package exposes a single documented procedure, EVALUATE_ALERTS. Its documented purpose is to find all subscribers of a given alert for the SMS and EMAIL notification channels, thereby driving the delivery of alert messages to the appropriate recipients.

The documented argument set reflects the standard Oracle Workflow function activity signature used throughout the EBS alerting framework:

  • itemtype — a valid item type from the WF_ITEM_TYPES table, identifying the workflow process context in which the alert executes.
  • itemkey — a string generated from the application object's primary key, uniquely identifying the runtime instance the alert concerns.
  • actid — the function activity (instance) identifier.
  • funcmode — the function execution mode supplied by the workflow engine, set to RUN, CANCEL, or TIMEOUT.
  • resultout — the procedure's output result, documented as COMPLETE:SUCCESS or NULL.

The internal evaluation logic, subscription resolution, and channel dispatch mechanics are not exposed by the documented specification. No public constants, datatypes, or variables are documented in the package specification.

Tables Accessed

Analysis of the documented dependencies shows the package references two tables through APPS synonyms:

  • CS_INCIDENTS_ALL_B — the base table for service requests (incidents) in Oracle TeleService. The package reads this table to resolve the application object against which the alert condition is evaluated, using the primary key represented by the itemkey parameter.
  • PLITBLM — a PL/SQL index-by table type used in EBS for passing and manipulating collections of identifiers in bulk. Its presence indicates that the subscriber and condition processing is performed set-wise rather than row-by-row.

No insert, update, or delete targets are listed in the documented metadata, consistent with the procedure's stated role of evaluation and subscriber resolution rather than persistence of alert state.

Usage Notes

ASP_SERVICE_ALERT_AGENT is not intended for direct invocation by application users or custom extensions. Because its procedure conforms to the workflow function activity signature, it is most commonly wired into an Oracle Workflow process as a function activity node, where the workflow engine supplies itemtype, itemkey, actid, and funcmode at runtime and consumes the returned resultout value to determine subsequent process transitions.

In practice, the package is triggered in one of two ways: as part of an alert definition scheduled for periodic evaluation, or as an event-driven step responding to changes in service request data. When activated, it evaluates the alert condition against the incident identified by itemkey, resolves the subscriber list for the SMS and EMAIL channels, and hands the resulting recipients to the notification infrastructure.

Customizations should treat this package as an internal component. Developers requiring alert evaluation or subscription behavior should use officially supported alerting and workflow APIs rather than calling EVALUATE_ALERTS directly, since the specification is not classified as a public API and its internals may change between releases.