Results for “alr_alert_inputs”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The ALR.ALR_ALERT_INPUTS table stores the definition of the input parameters that drive an Oracle Alert. Each row describes a single prompt or input value that an alert definition expects at runtime — its name, its data type, its default value, and the window during which it is active. Alert inputs are the mechanism by which a generic alert definition is parameterized; the Oracle Alert engine evaluates an input against the period defined by START_DATE_ACTIVE and END_DATE_ACTIVE and supplies the resolved value to the alert's SQL or PL/SQL action.

The object resides in the ALR schema, which is owned by the Alert product (ALR) and is shipped with Oracle E-Business Suite 12.1.1 and 12.2.2. It is a standard, VALID table in the EBS data dictionary and is exposed through the Applications DBA and Alert setup forms. Under the heuristic Data Vault classification mined from its foreign key structure, this table is best regarded as satellite-leaning: it carries descriptive, date-effective attributes (TITLE, DATA_TYPE, DEFAULT_VALUE, ENABLED_FLAG, START_DATE_ACTIVE, END_DATE_ACTIVE) that qualify the parent alert definition rather than representing an independent business entity or an associative relationship.

Key Information Stored

The table is defined with 16 documented columns. The most significant are:

• APPLICATION_ID and ALERT_ID — together with NAME, the composite surrogate key ALR_ALERT_INPUTS_PK. ALERT_ID ties the input to its parent alert in ALR_ALERTS; APPLICATION_ID scopes it to an EBS application.
• NAME — the internal identifier of the input, used as the token referenced in the alert's SQL statement or action.
• TITLE — the user-facing prompt label shown when the alert requests input.
• DATA_TYPE — the data type of the input value (character, number, date), governing validation and binding.
• DEFAULT_VALUE — the value applied when the user does not supply one.
• ENABLED_FLAG — indicates whether the input is currently active.
• START_DATE_ACTIVE / END_DATE_ACTIVE — the date-effective window during which the input applies.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, supporting multi-org / data-security partitioning.
• Standard WHO audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN.
• ZD_EDITION_NAME — the editioning column present in 12.2.x, which participates in the unique index ALR_ALERT_INPUTS_U1 (APPLICATION_ID, ALERT_ID, NAME, ZD_EDITION_NAME). This index, rather than the primary key alone, is the business-key candidate that preserves uniqueness under online patching / edition-based redefinition.

Common Use Cases and Queries

Typical usage centers on inspecting, documenting, and auditing alert definitions. A common query lists all inputs for a given alert:

• Catalog an alert's inputs: SELECT name, title, data_type, default_value, enabled_flag FROM alr.alr_alert_inputs WHERE alert_id = :alert_id ORDER BY name;
• Join to the alert header to report alert name and application: join ALR_ALERTS on APPLICATION_ID and ALERT_ID.
• Find active inputs by date window: filter where SYSDATE BETWEEN START_DATE_ACTIVE AND END_DATE_ACTIVE and ENABLED_FLAG = 'Y'.
• Audit recently modified inputs: order by LAST_UPDATE_DATE and constrain by LAST_UPDATED_BY.
• Migration and configuration review: compare input definitions across environments to detect drift, or to understand why an alert behaves differently.

Related Objects

• ALR_ALERTS — parent alert definition; joined on ALR_ALERT_INPUTS.APPLICATION_ID = ALR_ALERTS.APPLICATION_ID and ALR_ALERT_INPUTS.ALERT_ID = ALR_ALERTS.ALERT_ID (enforced foreign key).
• FND_SECURITY_GROUPS — referenced by ALR_ALERT_INPUTS.SECURITY_GROUP_ID for data-security scoping.
• The Oracle Alert definition DDL and the Alert periodic/event processing engine consume these rows to resolve runtime input values.