Results for “phase_code”

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

Overview

FND_CONC_REQ_OUTPUTS_V is a validity-checked APPS-owned view in the FND — Application Object Library product of Oracle E-Business Suite. It presents the output file metadata associated with concurrent requests, reconciling two distinct sources of output within the concurrent manager architecture: the primary request-level output file stored on FND_CONCURRENT_REQUESTS, and the per-action output files recorded in FND_CONC_REQ_OUTPUTS for post-processing actions. The view's central design problem is resolving which of these two outputs is authoritative for a given request; it does so through a DECODE expression keyed on ACTION_TYPE, falling back to the action-level output when the action type equals 6 and otherwise reporting the request-level output.

For reporting and integration purposes the view provides a single, denormalized row per concurrent request, exposing the effective output node, file name, size, type, creation date, and — critically for the user's search term — the SAVE_OUTPUT_FLAG. Because the join to the action and output tables uses outer joins, requests that never executed a type-6 post-processing action are still returned, making the view safe for broad concurrent-request reporting without dropping rows.

Underlying Base Objects

The documented view text references three base objects, all resolved in the APPS schema through synonyms:

• FND_CONCURRENT_REQUESTS (R) — the driving table, supplying REQUEST_ID, PHASE_CODE, STATUS_CODE, OUTFILE_NODE_NAME, OUTFILE_NAME, OFILE_SIZE, OUTPUT_FILE_TYPE, ACTUAL_COMPLETION_DATE, and SAVE_OUTPUT_FLAG.
• FND_CONC_PP_ACTIONS (A) — the post-processing action table, joined with the outer-join operator (+) on REQUEST_ID and constrained to ACTION_TYPE = 6. It contributes the ACTION_TYPE column projected by the view.
• FND_CONC_REQ_OUTPUTS (O) — the action-level output file table, also outer-joined on CONCURRENT_REQUEST_ID and ACTION_TYPE, supplying FILE_NODE_NAME, FILE_NAME, FILE_SIZE, FILE_TYPE, and FILE_CREATION_DATE when the type-6 action path applies.

The outer-join structure ensures FND_CONCURRENT_REQUESTS remains the preserved side, with the action and output tables optionally supplying overrides.

Key Columns

• REQUEST_ID — primary identifier of the concurrent request; the join key across all three base objects.
• PHASE_CODE / STATUS_CODE — the request's lifecycle phase and completion status, used to filter to completed requests before retrieving output.
• ACTION_TYPE — the post-processing action type; only value 6 causes the view to prefer action-level output.
• FILE_NODE_NAME / FILE_NAME — the effective output location and file name, decoded between the request-level and action-level values.
• FILE_SIZE / FILE_TYPE — the effective size and output type of the resolved file.
• FILE_CREATION_DATE — derived from the action-level creation date when ACTION_TYPE = 6, otherwise from ACTUAL_COMPLETION_DATE.
• SAVE_OUTPUT_FLAG — the request-level flag indicating whether the concurrent manager retained the output file. This is the column users query when auditing output retention or locating requests whose output was purged.

Common Use Cases and Queries

Typical uses include output inventory reporting, purge auditing, and integration jobs that must locate a request's retained output file. A representative query retrieving retained output for completed requests follows:

• Audit retained output: SELECT request_id, file_name, file_node_name, file_size, save_output_flag FROM fnd_conc_req_outputs_v WHERE save_output_flag = 'Y' AND phase_code = 'C';
• Locate output for a specific request: SELECT file_name, file_node_name, file_creation_date FROM fnd_conc_req_outputs_v WHERE request_id = :req_id;
• Size trend by program run: join the view to FND_CONCURRENT_PROGRAMS via the request tables to aggregate FILE_SIZE over a date range.

Because SAVE_OUTPUT_FLAG reflects the request-level setting, it is the reliable predicate for determining whether output should still exist on the file system; the file columns then identify where that output resides.