Results for “completion_text”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

BIS_RS_STAGE_RUN_HISTORY is a table in the BIS (Applications BIS) schema of Oracle E-Business Suite, available in both 12.1.1 and 12.2.2. It stores the historical execution records for the individual stages that comprise a Request Set run. Within the concurrent processing framework, a request set is a group of concurrent programs executed together; each program corresponds to a stage, and this table captures the outcome, timing, and status of each stage as it executes.

The object is classified under a standalone Data Vault modeling pattern based on heuristic mining of its foreign key structure. This classification suggests that, from a dimensional modeling perspective, BIS_RS_STAGE_RUN_HISTORY behaves as an independent entity rather than a traditional hub, link, or satellite, because it holds only a single documented foreign key relationship (STAGE_ID referencing ECE_STAGE) and does not participate in a dense network of referential dependencies. The table is owned by the BIS schema and is marked VALID in the ETRM registry for 12.2.2.

Key Information Stored

The table contains 14 documented columns. The most significant are:

• REQUEST_ID — The identifier for the specific run-history record. It is the only documented unique business-key candidate, enforced by unique index BIS_RS_STAGE_RUN_HISTORY_U1. This column most closely functions as the surrogate identifier for a stage run record.
• REQUEST_SET_ID and SET_APP_ID — Identify the parent request set definition and its application context.
• SET_REQUEST_ID — The concurrent request identifier of the overall request set execution that produced this stage record.
• STAGE_ID — The stage definition identifier. This is the sole foreign key, referencing ECE_STAGE.
• START_DATE and COMPLETION_DATE — Timestamps marking when the stage began and finished.
• STATUS_CODE and PHASE_CODE — Standard concurrent manager codes indicating the execution state (for example, completed, error, or running) and the phase of processing.
• COMPLETION_TEXT — Descriptive text accompanying the stage completion, often containing error or diagnostic messages.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY — Standard EBS audit columns tracking who inserted and last modified the record and when.

The surrogate primary key is not separately documented beyond the unique index on REQUEST_ID; no dedicated RUN_HISTORY_ID column appears in the documented column list, so REQUEST_ID serves the identifying role.

Common Use Cases and Queries

The principal use case is auditing and troubleshooting request set executions. Administrators and support analysts query this table to determine which stage of a multi-stage request set failed and why. A typical query joins the stage history to the parent set run to isolate failed stages:

SELECT rsr.request_set_id,
       rsr.stage_id,
       rsr.status_code,
       rsr.phase_code,
       rsr.start_date,
       rsr.completion_date,
       rsr.completion_text
FROM   bis_rs_stage_run_history rsr
WHERE  rsr.set_request_id = :request_id
ORDER  BY rsr.start_date;

Reporting scenarios include measuring per-stage elapsed time (computed from START_DATE and COMPLETION_DATE) to identify performance bottlenecks, and aggregating failure frequency by STATUS_CODE. A further pattern resolves the stage definition through the foreign key to ECE_STAGE to display human-readable stage names alongside execution outcomes.

Related Objects

• ECE_STAGE — Referenced by BIS_RS_STAGE_RUN_HISTORY.STAGE_ID; provides the stage definition and descriptive metadata for each execution record.
• FND_CONCURRENT_REQUEST — Correlates SET_REQUEST_ID with the top-level concurrent request that orchestrated the request set.
• FND_REQUEST_SETS — Holds the parent request set definition referenced by REQUEST_SET_ID.
• FND_REQUEST_SET_STAGES — Defines the ordered stages belonging to a request set, providing context for stage sequencing.
• BIS_RS_RUN_HISTORY — The companion history table for request set-level runs, forming the parent context for individual stage records.
• FND_CONCURRENT_PROGRAMS — Resolves the concurrent program associated with each stage execution.

These relationships support full traceability from a single stage failure back to the request set definition and forward to the concurrent manager logs.