Search Results fnd_run_requests

Overview

The FND_RUN_REQUESTS table is a core Application Object Library (FND) table in Oracle E-Business Suite (EBS) that stores the runtime configuration and execution details for individual programs within a report set, also known as a request set. Its primary role is to manage the execution chain when a user submits a request set. The table acts as a child-level execution plan, linking the parent request set submission to each specific concurrent program that must be run as part of the set. It is a critical component for the Concurrent Processing architecture, enabling the definition of dependencies, execution sequences, and program-specific parameters for each step in a multi-step request set.

Key Information Stored

The table holds the setup information that dictates how and when each program in a set runs. Its composite primary key uniquely identifies a specific program's execution instance within a parent request set submission. Key columns include:

• PARENT_REQUEST_ID: The request ID of the master request set submission from FND_CONCURRENT_REQUESTS.
• REQUEST_SET_ID and SET_APPLICATION_ID: Identify the request set definition.
• REQUEST_SET_PROGRAM_ID: A foreign key to FND_REQUEST_SET_PROGRAMS, identifying the specific program step within the set's definition.
• REQUEST_ID: The request ID of the individual concurrent request spawned for this program step, linked to FND_CONCURRENT_REQUESTS.
• APPLICATION_ID and CONCURRENT_PROGRAM_ID: Identify the actual concurrent program to be executed, linked to FND_CONCURRENT_PROGRAMS.
• Additional columns store execution instructions like PRINTER, PRINT_STYLE, runtime arguments, and control flags for the step.

Common Use Cases and Queries

This table is essential for auditing, troubleshooting, and reporting on request set executions. A common use case is tracing the detailed execution flow of a request set. For example, to find all individual program steps spawned by a specific parent request set submission (e.g., PARENT_REQUEST_ID = 12345678), a developer or administrator would query:

SELECT rrs.request_id, rrs.concurrent_program_id, cp.user_concurrent_program_name, cr.phase_code, cr.status_code
FROM apps.fnd_run_requests rrs,
apps.fnd_concurrent_programs_tl cp,
apps.fnd_concurrent_requests cr
WHERE rrs.parent_request_id = 12345678
AND rrs.concurrent_program_id = cp.concurrent_program_id
AND rrs.application_id = cp.application_id
AND cp.language = USERENV('LANG')
AND rrs.request_id = cr.request_id
ORDER BY rrs.request_set_program_id;

Another critical scenario involves diagnosing issues where a specific program step (REQUEST_SET_PROGRAM_ID) fails repeatedly within different set runs, requiring analysis of historical execution data stored in this table joined with FND_CONCURRENT_REQUESTS.

Related Objects

FND_RUN_REQUESTS maintains integral foreign key relationships with several fundamental Concurrent Processing tables, as documented in the ETRM metadata:

• FND_CONCURRENT_REQUESTS: Joined via PARENT_REQUEST_ID to the master set request and via REQUEST_ID to each child program request.
• FND_REQUEST_SET_PROGRAMS: Joined via the composite key (SET_APPLICATION_ID, REQUEST_SET_ID, REQUEST_SET_PROGRAM_ID) to the definition of the program step.
• FND_CONCURRENT_PROGRAMS: Joined via APPLICATION_ID and CONCURRENT_PROGRAM_ID to the executable program's master definition.
• FND_PRINTER and FND_PRINTER_STYLES: Joined via the PRINTER and PRINT_STYLE columns for output device information.