Search Results fnd_concurrent_requests

Overview

The FND_CONCURRENT_REQUESTS table is the central repository for all concurrent processing activity within Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2. Owned by the APPLSYS schema and part of the Application Object Library (FND) module, it stores the complete lifecycle and execution details of every concurrent request submitted to the system. This table is fundamental to the Concurrent Manager architecture, tracking requests from submission through completion, and is essential for monitoring, reporting, and troubleshooting batch operations. Its integrity is maintained by a primary key on REQUEST_ID and a complex network of foreign keys linking it to critical master data across the application.

Key Information Stored

The table's columns capture the full state and context of a request. The primary identifier, REQUEST_ID, is a unique system-generated sequence. Key descriptive columns include CONCURRENT_PROGRAM_ID and PROGRAM_APPLICATION_ID, which identify the specific program executed. Status and phase are tracked via STATUS_CODE and PHASE_CODE, indicating if a request is pending, running, completed, or errored. Execution context is stored in REQUESTED_BY (user), RESPONSIBILITY_ID, and ORACLE_ID (database account). Performance and output are recorded through ACTUAL_START_DATE, ACTUAL_COMPLETION_DATE, and pointers to log/output files via LOGFILE_NODE_NAME and OUTFILE_NODE_NAME. The table also manages processing rules through PRIORITY, PARENT_REQUEST_ID for child requests, and CONTROLLING_MANAGER to link to the managing concurrent process.

Common Use Cases and Queries

This table is most frequently queried for operational monitoring and historical analysis. Common scenarios include checking the status of recent requests, identifying long-running processes, and analyzing completion trends. A typical status query for a user's requests would join with FND_CONCURRENT_PROGRAMS_TL for the program name:

• SELECT cr.request_id, cpt.user_concurrent_program_name, cr.argument_text, cr.status_code, cr.phase_code FROM fnd_concurrent_requests cr, fnd_concurrent_programs_tl cpt WHERE cr.concurrent_program_id = cpt.concurrent_program_id AND cr.program_application_id = cpt.application_id AND cpt.language = USERENV('LANG') AND cr.requested_by = :user_id ORDER BY cr.request_id DESC;

For performance reporting, aggregations on ACTUAL_START_DATE and ACTUAL_COMPLETION_DATE are used. Developers also query it to diagnose issues by examining the output file locations or to find dependent child requests using the PARENT_REQUEST_ID relationship.

Related Objects

As indicated by the extensive foreign key relationships, FND_CONCURRENT_REQUESTS is a hub table with dependencies across the EBS foundation. Key documented relationships include:

• FND_CONCURRENT_PROGRAMS: Joins on (PROGRAM_APPLICATION_ID, CONCURRENT_PROGRAM_ID) to define the program run.
• FND_USER: Joins on REQUESTED_BY to identify the submitting user.
• FND_CONCURRENT_PROCESSES: Joins on CONTROLLING_MANAGER to link to the specific manager process instance.
• FND_RESPONSIBILITY: Joins on (RESPONSIBILITY_APPLICATION_ID, RESPONSIBILITY_ID) for the submission context.
• FND_NODES: Multiple joins for execution node (NODE_NAME1), failover node (NODE_NAME2), and file server nodes (LOGFILE_NODE_NAME, OUTFILE_NODE_NAME).
• FND_CONCURRENT_REQUESTS (Self-Referential): Joins on PARENT_REQUEST_ID and PRIORITY_REQUEST_ID to manage request hierarchies and dependencies.
• Dependent Tables: The table is referenced by numerous application tables, such as ALR_ALERT_CHECKS and AP_CARDS_ALL, which store the REQUEST_ID to track the originating batch job.