Search Results edr_eresmanager_t




Overview
Explore in AI Chat

Overview

EDR_ERESMANAGER_T is a temporary (transient runtime) table in the EDR — E-Records module of Oracle E-Business Suite, owned by the EDR schema. Its documented purpose is to hold run-time ERES (Electronic Records and Electronic Signatures) Manager object details during the execution of an ERES-driven process. In EBS releases 12.1.1 and 12.2.2, the EDR module underpins electronic signature capture and electronic record retention, and this table functions as the in-flight state store for a single ERES Manager invocation. Rows are populated when a process begins, updated as the workflow or page progresses, and consumed by return/redirect logic when the run completes; the data is therefore short-lived and should not be treated as a permanent audit record.

The supplied metadata classifies this object heuristically as standalone within a Data Vault model. That classification is best read as a modeling suggestion: the table holds no outgoing foreign keys and behaves as an isolated runtime state holder rather than a conformed hub or link. It is referenced by one dependent object (EDR_PROCESS_ERECORDS_T), so in a dimensional or Data Vault view it is closer to a transient satellite whose driving key is the ERES process identifier.

Key Information Stored

The table is documented with nine physical columns. The most significant are:

  • ERES_PROCESS_ID — the surrogate primary key, enforced by unique index EDR_ERESMANAGER_T_P. It is the single business-key candidate and uniquely identifies one ERES Manager run. It is also the column through which child objects join back to this table.
  • OVERALL_STATUS — the aggregate status of the ERES Manager run, used by callers to determine whether a process completed, failed, or is still pending.
  • RETURN_URL — the destination the ERES Manager should redirect to when the run finishes, enabling the calling page or workflow to resume.
  • RETURN_FUNCTION — the callback or function invoked on completion, paired with RETURN_URL to drive post-processing.
  • CREATED_BY, CREATION_DATE — standard EBS WHO columns recording the user and timestamp that initiated the run.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS WHO columns capturing the most recent modification, useful for lifecycle and audit analysis.

Because the table is temporary, the surrogate key is a runtime identifier rather than a durable business key; the WHO columns remain the reliable audit anchors.

Common Use Cases and Queries

Typical usage focuses on monitoring in-flight or recently completed ERES runs rather than historical reporting. A common diagnostic query retrieves current run state:

  • Monitor active runs: SELECT eres_process_id, overall_status, return_url, return_function FROM edr.edr_eresmanager_t WHERE overall_status = :status;
  • Trace a specific run: join on the primary key, SELECT * FROM edr.edr_eresmanager_t WHERE eres_process_id = :id;
  • Reconcile with child e-records: SELECT m.eres_process_id, m.overall_status, e.* FROM edr.edr_eresmanager_t m JOIN edr.edr_process_erecords_t e ON e.eres_process_id = m.eres_process_id;
  • Identify stale runtime rows: filter on last_update_date to detect entries left behind after a failed process.

Reporting should treat results as volatile, and queries should generally be scoped by ERES_PROCESS_ID to avoid full scans on a high-churn table.

Related Objects

  • EDR_PROCESS_ERECORDS_T — the documented dependent table; it references this table via ERES_PROCESS_ID → EDR_ERESMANAGER_T.ERES_PROCESS_ID, holding the individual electronic records produced during the run.
  • EDR_ERESMANAGER_T_P — the unique index enforcing the primary key on ERES_PROCESS_ID.
  • EDR schema ERES Manager APIs — the PL/SQL entry points that populate this table at runtime and read RETURN_URL/RETURN_FUNCTION to complete the process.

These relationships make EDR_ERESMANAGER_T the parent (runtime state) record for the e-records generated by a single ERES Manager execution.