Search Results sys_il0000396575c00003

Overview

EDR.EDR_RAW_XML_T is a staging and archival table within the Oracle E-Business Suite Electronic Data Reporting (EDR) module. It resides in the APPS_TS_INTERFACE tablespace, the standard repository for interface and intermediate data in an EBS environment, and is owned by the EDR schema. The table stores raw eXtensible Markup Language (XML) payloads keyed by a logical event identity, functioning as a durable landing zone for XML content ingested by the EDR event framework before or alongside downstream processing. In Oracle EBS 12.1.1 and 12.2.2, EDR is typically associated with regulatory and electronic reporting flows, and this table serves as the persistent store for the verbatim XML message associated with each named event instance.

From a Data Vault modeling perspective, the metadata classifies EDR_RAW_XML_T as a standalone object with no referencing foreign keys, which heuristically suggests a satellite- or hub-like role rather than a link. The composite unique index EDR_RAW_XML_T_P on (EVENT_NAME, EVENT_KEY) acts as the business key that uniquely identifies each stored XML payload, and it is the natural anchor for any historical or descriptive attributes. Because the object declares no foreign key dependencies, it behaves as a self-contained event record store rather than a relational intersection.

Key Information Stored

The table contains eight documented columns. The most significant are the composite business key and the payload itself:

• EVENT_NAME (VARCHAR2, 80) — The logical name of the EDR event or message type, distinguishing categories of ingested XML.
• EVENT_KEY (VARCHAR2, 240) — The business identifier for a specific event instance; combined with EVENT_NAME it forms the unique primary key EDR_RAW_XML_T_P.
• RAW_XML (CLOB, 4000) — The raw XML document payload. Because it is a CLOB, the documented SYS_IL0000396575C00003$$ LOB index and segment are associated with this column.
• CREATED_BY, CREATION_DATE — Standard EBS audit columns recording the creating user and timestamp.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard EBS audit columns capturing the last modifying user, login session, and timestamp.

There is no documented synthetic surrogate key; the unique index on (EVENT_NAME, EVENT_KEY) is the effective primary key. The LOB index SYS_IL0000396575C00003$$ is a system-generated index supporting the RAW_XML CLOB and carries no business meaning.

Common Use Cases and Queries

Typical usage centers on retrieving the verbatim XML for a given event, auditing what the EDR interface received, and replaying or reprocessing payloads. A common retrieval pattern filters by event identity:

• SELECT RAW_XML FROM EDR.EDR_RAW_XML_T WHERE EVENT_NAME = :name AND EVENT_KEY = :key;
• Audit queries selecting CREATED_BY, CREATION_DATE, LAST_UPDATE_DATE to trace ingestion timing and ownership.
• Correlation queries grouping by EVENT_NAME to count events and measure payload volumes over time.
• Content inspection using DBMS_LOB or XMLType conversion where the SQL dialect supports it, to extract or validate payload elements.

Note the standing Oracle warning: this object is designated Oracle Internal Use Only and is not supported for direct access except through standard Oracle Applications programs. Prefer supported EDR APIs or concurrent programs when consuming or loading this data.

Related Objects

The documented dependency metadata states that EDR_RAW_XML_T does not reference any database object and lists APPS.EDR_RAW_XML_T among objects referencing it — effectively a synonym or public alias exposed in the APPS schema for the same underlying table. Practical related objects, based on EBS convention rather than documented foreign keys, include:

• APPS.EDR_RAW_XML_T — the APPS-schema synonym/alias used by applications and reports.
• EDR event-processing packages and concurrent programs that read from and write to this table, keyed by EVENT_NAME and EVENT_KEY.
• Downstream EDR XML parsing or transformation objects that consume RAW_XML for extraction.
• Concurrent program and request tables (FND_CONCURRENT_REQUESTS) used to correlate program executions with ingested events, joined indirectly via audit timestamps rather than declared keys.

Because no formal foreign keys are declared, joins to this table should be constructed on the business key (EVENT_NAME, EVENT_KEY) or on the audit columns, not on assumed referential constraints.