Search Results action_num

Overview

BNE_ASYNC_UPLOAD_JOBS_H is a table in the BNE schema (Web Applications Desktop Integrator product) within Oracle E-Business Suite 12.1.1 and 12.2.2. It stores historical or action-level records for asynchronous upload jobs submitted through Web ADI (Web Applications Desktop Integrator). The documented description states that the table stores upload jobs with one row per job. However, the presence of both JOB_ID and ACTION_NUM in the primary key, along with a unique index named BNE_ASYNC_UPLOAD_H_UK1 on the same column pair, indicates the table retains one row per job action rather than a single row per job.

Because the metadata explicitly lists a foreign key from BNE_ASYNC_UPLOAD_JOBS_H.JOB_ID to BNE_ASYNC_UPLOAD_JOBS, the table functions as a dependent child of the parent jobs table. Based on the documented relationship structure, the heuristic Data Vault classification is satellite-leaning: it holds descriptive, state-tracking attributes (upload state, action code, transaction references) tied to a parent business key. This is offered as a modeling suggestion rather than a documented declaration.

Key Information Stored

The physical schema documents 12 columns. The most significant are:

• JOB_ID — part of the composite primary key (BNE_ASYNC_UPLOAD_JOBS_H_PK) and the foreign key to BNE_ASYNC_UPLOAD_JOBS. Identifies the parent upload job.
• ACTION_NUM — the second component of the composite primary key and the column you searched for. It distinguishes individual actions or retries recorded against a single job, allowing multiple state transitions per JOB_ID.
• OBJECT_VERSION_NUMBER — the standard EBS optimistic-locking column, used to detect concurrent updates.
• ACTION_CODE — the code classifying the action performed (for example, upload, validate, or similar process steps).
• UPLOAD_STATE — the current processing state of the job action, driving status reporting and error handling.
• TRANSACTION_REFERENCE1 / TRANSACTION_REFERENCE2 — reference identifiers linking the upload action to downstream transactions or source data keys.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS audit columns recording who created and last modified the row.

The surrogate primary key is BNE_ASYNC_UPLOAD_JOBS_H_PK (JOB_ID, ACTION_NUM). The unique index BNE_ASYNC_UPLOAD_H_UK1 on the same pair is documented as a business-key candidate, confirming that JOB_ID plus ACTION_NUM is the natural, business-facing identifier of each row.

Common Use Cases and Queries

Typical scenarios include diagnosing failed or stalled Web ADI uploads, tracing each action against a job, and reporting upload status by user. A representative query joining the parent jobs table:

• SELECT h.job_id, h.action_num, h.action_code, h.upload_state, h.transaction_reference1 FROM bne_async_upload_jobs_h h WHERE h.job_id = :job_id ORDER BY h.action_num;
• To find the latest action per job: filter on MAX(action_num) grouped by JOB_ID.
• To report failures: filter on UPLOAD_STATE values indicating error conditions, joined to BNE_ASYNC_UPLOAD_JOBS for job-level context.
• To audit activity: filter on CREATED_BY or CREATION_DATE ranges.

Because JOB_ID plus ACTION_NUM is unique, lookups by that pair are the most efficient access path, backed by the documented unique index.

Related Objects

The documented relationships and surrounding BNE upload infrastructure point to the following significant objects:

• BNE_ASYNC_UPLOAD_JOBS — the parent table; joined via JOB_ID (BNE_ASYNC_UPLOAD_JOBS_H.JOB_ID references BNE_ASYNC_UPLOAD_JOBS).
• BNE_ASYNC_UPLOAD_JOBS_H_PK — the composite primary key constraint over JOB_ID and ACTION_NUM.
• BNE_ASYNC_UPLOAD_H_UK1 — the unique index enforcing the JOB_ID, ACTION_NUM business key.
• BNE_ASYNC_UPLOAD_JOBS_TL / BNE upload parameter and status tables — companion BNE objects commonly queried alongside job history for full job context.
• Web ADI integrator APIs and concurrent programs — the uploader processes that write ACTION_CODE and UPLOAD_STATE values into this table.
• FND concurrent request tables (FND_CONCURRENT_REQUESTS) — often referenced indirectly when the asynchronous upload runs under a concurrent manager request.

Together these objects support end-to-end tracking of Web ADI upload activity across Oracle EBS releases 12.1.1 and 12.2.2.