Search Results alr_alert_checks




Overview
Explore in AI Chat

Overview

The ALR_ALERT_CHECKS table is a core data object within the Oracle E-Business Suite Alert module (ALR). It serves as the central repository for storing detailed information about each execution instance, or "check," of a defined alert. When a periodic alert is submitted as a concurrent request, this table logs the specific run, capturing its status, timing, and key identifiers. This enables the Alert Manager to track execution history, manage dependencies, and facilitate the subsequent action processing defined within the alert's action sets. Its role is integral to the operational audit trail and functional workflow of the Oracle Alert system.

Key Information Stored

While the full column list is not detailed in the provided metadata, the primary and foreign key structure reveals critical data points. The table uniquely identifies each check using a composite primary key of APPLICATION_ID and ALERT_CHECK_ID. It stores the foreign key relationship to the parent alert definition via APPLICATION_ID and ALERT_ID, linking the check to a specific alert in the ALR_ALERTS table. Furthermore, it maintains a link to the concurrent manager infrastructure through the REQUEST_ID column, which references FND_CONCURRENT_REQUESTS. This allows the alert check to be managed and monitored like any other concurrent program. Typical data would include timestamps for the check's start and end, its completion status (e.g., success, error, warning), and potentially summary information about the data fetched during execution.

Common Use Cases and Queries

Primary use cases involve monitoring alert performance, troubleshooting failures, and generating execution reports. Database administrators and functional consultants often query this table to analyze alert run history. A common query retrieves recent checks for a specific alert, joining to the concurrent requests table for status details:

  • SELECT ac.alert_id, ac.alert_check_id, cr.request_id, cr.request_date, cr.phase_code, cr.status_code FROM alr_alert_checks ac, fnd_concurrent_requests cr WHERE ac.request_id = cr.request_id AND ac.application_id = :app_id AND ac.alert_id = :alert_id ORDER BY cr.request_date DESC;

Another frequent scenario is identifying alerts that have failed their checks, which may require reviewing the associated action set outputs or log files. Queries against this table are foundational for auditing alert activity and ensuring the reliability of automated business notifications and workflows.

Related Objects

The ALR_ALERT_CHECKS table maintains documented foreign key relationships with several key EBS objects, as per the provided metadata:

  • ALR_ALERTS: The master definition table for alerts. Joined via (APPLICATION_ID, ALERT_ID). This is the parent relationship.
  • FND_CONCURRENT_REQUESTS: The core table for concurrent program executions. Joined via REQUEST_ID. This links the alert check to its concurrent request record.
  • ALR_ACTION_SET_CHECKS: This table holds the action sets associated with a specific alert check. It has a foreign key referencing (APPLICATION_ID, ALERT_CHECK_ID) in ALR_ALERT_CHECKS, establishing a one-to-many relationship where a single check can trigger multiple action sets.