Search Results sys_il0000194331c00007




Overview

FTE.FTE_BULKLOAD_DATA is an interface table in the Oracle E-Business Suite FTE (Fulfillment / Transportation Execution) schema, deployed in both EBS 12.1.1 and 12.2.2. Its documented purpose is to store data related to download and upload for Bulkload processing. In practical terms, the table acts as a staging and persistence layer for file-based payloads — typically flat files or structured extracts — that are transferred into or out of the EBS application during bulk operations. Each row represents one file participating in a bulkload run, together with its binary content and identifying attributes.

The table resides in the APPS_TS_INTERFACE tablespace, with PCTFREE 10, reflecting its role as a transient-to-semi-permanent interface store rather than a core transactional entity. The primary key is FTE_BULKLOAD_DATA_PK, defined on LOAD_ID. The documented unique index SYS_IL0000194331C00007$$ is a LOB index associated with the CONTENT (BLOB) column, not a business-key uniqueness constraint on user data. Based on the mined foreign-key structure, the object is classified as standalone. Under a Data Vault heuristic, this suggests modeling it as an independent hub or standalone satellite keyed by LOAD_ID, since no inbound or outbound referential dependencies were documented.

Key Information Stored

The table comprises twelve documented columns. The most operationally significant are:

  • LOAD_ID (NUMBER) — Surrogate primary key and the load identifier. It is the sole documented primary key column and the principal join and lookup key.
  • LOAD_TYPE (VARCHAR2(20)) — Classifies the nature of the bulkload processing being performed (for example, direction or processing category).
  • FILE_TYPE (VARCHAR2(10)) — Identifies the type of file subject to upload or download.
  • FILE_NAME (VARCHAR2(200)) — The name of the file being uploaded or downloaded; the primary human-readable business identifier for the payload.
  • FILE_SIZE (NUMBER) — Recorded size of the file, useful for validation and reconciliation of transfers.
  • REQUEST_ID (NUMBER) — The concurrent request identifier, linking the row to the concurrent manager request that created or consumed the file.
  • CONTENT (BLOB, length indicator 4000) — The binary content of the file itself, stored as a LOB. This is the storage-heavy column and the basis of the unique LOB index.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard WHO columns supplying audit and accountability metadata.

No separate business-key unique index (beyond the LOB index) is documented, so LOAD_ID remains the definitive unique identifier; combinations such as (REQUEST_ID, FILE_NAME) may be practically unique within a run but are not enforced by the schema.

Common Use Cases and Queries

Typical uses include auditing bulkload activity, tracing a concurrent request to its associated files, reconciling file sizes to detect truncated transfers, and retrieving payload content for reprocessing or debugging.

List all files for a given concurrent request:

SELECT LOAD_ID, LOAD_TYPE, FILE_TYPE, FILE_NAME, FILE_SIZE
FROM   FTE.FTE_BULKLOAD_DATA
WHERE  REQUEST_ID = :p_request_id;

Trace the most recent bulkload activity within a date range:

SELECT LOAD_ID, FILE_NAME, CREATED_BY, CREATION_DATE
FROM   FTE.FTE_BULKLOAD_DATA
WHERE  CREATION_DATE >= SYSDATE - 7
ORDER  BY CREATION_DATE DESC;

Branch on LOB content only when required, since selecting CONTENT is expensive:

SELECT DBMS_LOB.GETLENGTH(CONTENT) file_bytes
FROM   FTE.FTE_BULKLOAD_DATA
WHERE  LOAD_ID = :p_load_id;

Reporting use cases include daily bulkload volume summaries by LOAD_TYPE and FILE_TYPE, failure investigation where files are present but downstream processing did not occur, and purge management — since the table resides in an interface tablespace, stale rows with large BLOBs are a common housekeeping target.

Related Objects

The documented dependency metadata states that FTE.FTE_BULKLOAD_DATA does not reference any database object, and that it is referenced only by the APPS synonym FTE_BULKLOAD_DATA. Consequently, no foreign-key joins are formally documented. The most significant related objects to consider when querying or maintaining this table are:

  • APPS.FTE_BULKLOAD_DATA — The synonym through which application code and SQL typically access the table.
  • FND_CONCURRENT_REQUESTS — Joined on REQUEST_ID to resolve the concurrent program, run dates, and completion status.
  • FND_USER — Joined on CREATED_BY and LAST_UPDATED_BY to resolve user names for audit reporting.
  • FTE_BULKLOAD_DATA_PK — The primary key constraint on LOAD_ID, used for direct row retrieval and referential integrity within the FTE schema.
  • SYS_IL0000194331C00007$$ — The unique LOB index supporting CONTENT access; relevant to tablespace and storage administration for the BLOB segment.

Because the object is classified as standalone, join paths beyond REQUEST_ID and the WHO columns must be inferred from application logic rather than enforced constraints.