Search Results alr_action_history




Overview
Explore in AI Chat

Overview

The ALR_ACTION_HISTORY table is a core data repository within the Oracle E-Business Suite Alert (ALR) module. It serves as the definitive audit log for the execution of alert actions. When a predefined Oracle Alert runs, either on a schedule or in response to an event, and its condition is met, it triggers a sequence of actions. This table records the historical details of each individual action execution, providing a complete audit trail. Its role is critical for troubleshooting failed alert executions, verifying that business logic was processed, and generating compliance reports on automated system activities. The data is essential for administrators to monitor the health and performance of the alert subsystem in both EBS 12.1.1 and 12.2.2.

Key Information Stored

The table's structure is designed to link each historical action entry to its parent definitions and execution context. The primary key is a composite of APPLICATION_ID and ACTION_HISTORY_ID, ensuring uniqueness across the EBS installation. Critical foreign key columns include ALERT_ID, which links to the parent alert definition in ALR_ALERTS, and ACTION_SET_ID with ACTION_SET_MEMBER_ID, linking to the specific action and its sequence within an action set defined in ALR_ACTION_SETS and ALR_ACTION_SET_MEMBERS. The CHECK_ID column references the specific verification step in ALR_ACTION_SET_CHECKS that triggered this action. Additional columns, implied by the foreign key relationships to ALR_ACTUAL_RESPONSES and ALR_ACTION_DATA, store execution handles (NODE_HANDLE, MESSAGE_HANDLE) and likely include timestamps, status codes (success/error), and outcome messages, forming a complete execution record.

Common Use Cases and Queries

The primary use case is diagnosing alert execution issues. An administrator can query this table to confirm if an alert fired, identify which specific action failed, and review related error details. A common reporting need is to list all actions executed for a specific alert within a date range. A sample query pattern would join ALR_ACTION_HISTORY (AAH) to ALR_ALERTS (AAL) on APPLICATION_ID and ALERT_ID to retrieve the alert name.

  • Diagnostic Query: SELECT aal.NAME, aah.* FROM ALR_ACTION_HISTORY aah, ALR_ALERTS aal WHERE aah.APPLICATION_ID = aal.APPLICATION_ID AND aah.ALERT_ID = aal.ALERT_ID AND aal.NAME = '<ALERT_NAME>' ORDER BY aah.ACTION_HISTORY_ID DESC;
  • Failure Analysis: Analysts often join to ALR_ACTION_DATA to retrieve detailed output or error messages stored for a failed ACTION_HISTORY_ID.
  • Compliance Audit: Generating a report of all alert actions executed over a period, grouped by alert and status, for SOX or internal controls.

Related Objects

ALR_ACTION_HISTORY is centrally connected to several key Alert tables via documented foreign key relationships, forming the core of the alert execution model.

  • ALR_ALERTS: Joined via APPLICATION_ID and ALERT_ID. This is the parent alert definition.
  • ALR_ACTION_SETS: Joined via APPLICATION_ID and ACTION_SET_ID. This defines the group of actions.
  • ALR_ACTION_SET_MEMBERS: Joined via APPLICATION_ID and ACTION_SET_MEMBER_ID. This identifies the specific action within the set.
  • ALR_ACTION_SET_CHECKS: Joined via APPLICATION_ID and CHECK_ID. This links to the verification logic that prompted the action.
  • ALR_ACTUAL_RESPONSES: Joined via NODE_HANDLE and MESSAGE_HANDLE. This connects to the response details for message actions.
  • ALR_ACTION_DATA: Has a foreign key referencing this table's APPLICATION_ID and ACTION_HISTORY_ID. This child table stores detailed output or variables from the action execution.