Results for “check_time”

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

Overview

The ALR_PERIODIC_ALERTS_VIEW is a seeded Oracle E-Business Suite database view owned by the APPS schema and validated as VALID in both EBS 12.1.1 and 12.2.2. It belongs to the ALR – Alert product, the Oracle Alert component of EBS that lets administrators define event-driven and periodic alerts. Where the base alert tables store the definitional attributes of every alert regardless of status or frequency type, this view narrows that population to enabled periodic alerts and additionally computes the next scheduled check date/time for each one.

Its practical role is twofold. First, it supports operational monitoring: administrators and DBAs can inspect exactly which periodic alerts are active and precisely when the Alert Checker/Alert Manager concurrent program is next expected to evaluate them. Second, it functions as a reporting and integration surface — the view is conveniently exposed so that custom reports, dashboards, or downstream extracts can determine the next run date for each alert without re-implementing the complex scheduling arithmetic that the alert engine applies internally. Correct interpretation of the "next check" column is essential when reconciling Alert Checker job history against alert definitions, or when tuning alert frequencies to control concurrent request load.

Underlying Base Objects

According to the documented ETRM metadata for 12.2.2, ALR_PERIODIC_ALERTS_VIEW is defined over the following objects:

• ALR_ALERTS (referenced via a synonym) — the master alert definition table supplying application, alert identity, name, status, frequency type, check interval, and last-checked date.
• ALR_PERIODIC_SETS (referenced via a synonym) — holds periodic-set scheduling attributes, including the days-between-checks value and the monthly check day number.
• FND_GLOBAL (package) — provides the runtime session context (application identifier and similar values) used during evaluation.
• FND_LOOKUPS (view) — supplies lookup codes and meanings; the view text references it (aliased as FNDLK) to translate the weekly check-day lookup code into a day name for NEXT_DAY computations.

The view is effectively a scheduling projection over the alert definition tables rather than a store of runtime state; the only persisted scheduling fact it consumes is DATE_LAST_CHECKED, from which the next eligible check is derived.

Key Columns

• APPLICATION_ID — owning application of the alert; the standard partitioning key for multiorg and application-scoped queries.
• ALERT_ID — primary identifier of the alert definition in ALR_ALERTS.
• ALERT_NAME — user-visible alert name.
• FREQUENCY_TYPE — the scheduling paradigm, with documented decode branches: 'C' every N calendar days, 'W' weekly, 'M' monthly, and 'B' every N business days.
• DAYS_BETWEEN_CHECKS — interval count applied to calendar-day and business-day frequencies.
• MONTHLY_CHECK_DAY_NUM — day-of-month anchor for monthly alerts.
• DATE_LAST_CHECKED — timestamp of the most recent check; the reference point from which the next check is projected.
• Next check (derived expression) — the view's central computed output. Per the view text, when the computed date equals LEAST(TRUNC(SYSDATE), ...) the literal 'T' (today) is returned; otherwise the next check date is returned as a formatted character string (TO_CHAR). Note that the column is therefore character-typed rather than a native DATE.

Common Use Cases and Queries

The most frequent scenario is answering "which periodic alerts are enabled, and when is each next checked?" — for example when investigating why an alert did not fire, or when balancing Alert Checker load across the day:

• Inventory enabled periodic alerts by application and frequency type.
• Identify alerts whose next check is 'T', i.e. scheduled for today.
• Reconcile alert definitions against concurrent request history for the Alert Checker program.

Sample query:

SELECT application_id,
       alert_id,
       alert_name,
       frequency_type,
       days_between_checks,
       date_last_checked,
       next_check
FROM   apps.alr_periodic_alerts_view
WHERE  frequency_type IN ('C','W','M','B')
ORDER  BY application_id, alert_name;

Because the next-check value is a character string (with the sentinel 'T' indicating "due today"), comparisons should generally be performed against the formatted string TO_CHAR(SYSDATE,'DD-MON-RR') rather than against SYSDATE directly. Queries joining the view to ALR_ALERTS on (APPLICATION_ID, ALERT_ID) retrieve additional definitional columns such as alert status and input/output attributes.