Search Results bne_async_upload_h_uk1

Overview

BNE.BNE_ASYNC_UPLOAD_JOBS_H is a transactional history table in the Oracle E-Business Suite 12.1.1 / 12.2.2 environment, owned by the BNE (Business Intelligence/Applications Technology) schema. It provides storage of upload jobs, with the documentation noting that the base object BNE_ASYNC_UPLOAD_JOBS holds one row per job, while this "_H" variant acts as the history (or audit) companion—capturing the sequential state changes applied to a job as recorded by ACTION_NUM, the line number of the history row. This table therefore sits at the intersection of the EBS concurrent processing model and the BNE upload framework, allowing administrators and developers to trace each lifecycle transition (such as initiation, validation outcome, and completion or failure) of an asynchronous upload job.

From a data-modeling perspective, the metadata's heuristic Data Vault classification is satellite-leaning. The composite primary key BNE_ASYNC_UPLOAD_JOBS_H_PK (JOB_ID, ACTION_NUM), the presence of a foreign key from JOB_ID to BNE_ASYNC_UPLOAD_JOBS, and the dense set of standard WHO audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) are characteristic of a satellite attached to a job-level hub. Modelers may treat this table as a historical satellite where each ACTION_NUM represents a distinct change event.

Key Information Stored

The surrogate/business key is the composite of JOB_ID and ACTION_NUM. JOB_ID is the asynchronous job identifier, linking back to the parent job record; ACTION_NUM is the line number of the history row, giving the sequence of history entries for a given job. Both form the primary key, and the unique index BNE_ASYNC_UPLOAD_H_UK1 (JOB_ID, ACTION_NUM) confirms this as the business-key candidate.

Among the remaining columns, the most operationally significant are:

• OBJECT_VERSION_NUMBER – optimistic locking/versioning counter used by the framework to detect concurrent updates.
• ACTION_CODE – the type of action the history row records; the documentation states it "will determine the contents of other fields."
• UPLOAD_STATE – the current upload state of the job at the point the history row was written.
• TRANSACTION_REFERENCE1 – a transaction reference pointing to a transaction used for failure support.
• TRANSACTION_REFERENCE2 – the transaction start date used for failure support.
• CREATED_BY, CREATION_DATE – WHO columns identifying the user (foreign key to FND_USER.USER_ID) and time the row was created.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – WHO columns capturing the user, timestamp, and operating-system login (foreign key to FND_LOGINS.LOGIN_ID) of the most recent update to the row.

These twelve columns together provide both the identity of the job event and the accountability metadata necessary for audit and diagnostic reporting.

Common Use Cases and Queries

The primary use case is reviewing the history of an asynchronous upload job to determine how it progressed and, where failures occurred, from which transaction reference the failure was raised. A straightforward query lists all history rows for a given job in sequence:

• SELECT JOB_ID, ACTION_NUM, ACTION_CODE, UPLOAD_STATE, TRANSACTION_REFERENCE1, TRANSACTION_REFERENCE2 FROM BNE.BNE_ASYNC_UPLOAD_JOBS_H WHERE JOB_ID = :job_id ORDER BY ACTION_NUM;

This pattern reveals the ordered progression of actions and states. A second common scenario is filtering for jobs that ended in a failed or unexpected state, joining to the parent BNE_ASYNC_UPLOAD_JOBS to retrieve descriptive attributes of the job while restricting to the latest history row using a subquery or analytic function such as ROW_NUMBER() OVER (PARTITION BY JOB_ID ORDER BY ACTION_NUM DESC). A third use case is failure-triage reporting, grouping transactions by TRANSACTION_REFERENCE1 to identify recurring failure points across many jobs, ordered by CREATION_DATE for trend analysis. Because the WHO columns are present, these queries can also be filtered by user (CREATED_BY) or by reporting window (CREATION_DATE / LAST_UPDATE_DATE) to satisfy audit or operational review requirements.

Related Objects

The most significant related objects are derived from the documented foreign-key relationships. The JOB_ID column references BNE.BNE_ASYNC_UPLOAD_JOBS, the parent job-header table holding one row per job; this is the principal join. The standard WHO columns imply additional references to FND_USER (via CREATED_BY and LAST_UPDATED_BY, joined on USER_ID) and to FND_LOGINS (via LAST_UPDATE_LOGIN, joined on LOGIN_ID). Related views and procedural APIs in the BNE upload framework typically expose or manipulate this history table, and the unique index BNE_ASYNC_UPLOAD_H_UK1 is itself a critical supporting object. When writing queries, joins to BNE_ASYNC_UPLOAD_JOBS on JOB_ID, and to the FND user and login tables on their respective keys, provide the complete picture of who changed what and when, while retaining the historical sequence recorded in ACTION_NUM.