Search Results fa_mass_retirements




The FND_CONCURRENT_REQUESTS table is a fundamental repository within Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2, serving as the central tracking mechanism for concurrent program execution. This table stores metadata, statuses, and execution details of all submitted concurrent requests, playing a critical role in job scheduling, monitoring, and historical analysis. Below is a detailed technical breakdown of its structure and significance.

Key Attributes and Columns

  • REQUEST_ID: Primary key uniquely identifying each concurrent request.
  • PROGRAM: References FND_CONCURRENT_PROGRAMS to identify the executable (stored in FND_EXECUTABLES).
  • STATUS_CODE: Indicates request state (e.g., 'P' for Pending, 'R' for Running, 'C' for Completed).
  • PHASE_CODE: Tracks lifecycle phase ('P' for Pending, 'R' for Running, 'C' for Completed).
  • ACTUAL_START_DATE/ACTUAL_COMPLETION_DATE: Timestamps for execution timelines.
  • ARGUMENT_TEXT: Stores runtime parameters passed to the program.
  • OUTFILE_NAME/LOGFILE_NAME: Paths to output and log files generated.
  • ORACLE_PROCESS_ID: OS-level process identifier for active requests.

Functional Role in EBS

The table integrates with core EBS components:
  1. Concurrent Processing: The Concurrent Manager polls this table to identify pending requests (STATUS_CODE='P') and spawns processes accordingly.
  2. Request Monitoring: Users query FND_CONCURRENT_REQUESTS via screens like "View Concurrent Requests" (Navigator > Concurrent > Requests).
  3. Dependency Management: Columns like HOLD_FLAG and PRIORITY control execution order and resource allocation.
  4. Historical Analysis: Retention of completed requests enables performance tuning and auditing.

Technical Considerations

  • Indexing: Heavily indexed on REQUEST_ID, STATUS_CODE, and ORACLE_SESSION_ID for performance.
  • Partitioning (12.2.2+): Optional partitioning by ACTUAL_START_DATE improves query performance in large deployments.
  • Purge Mechanisms: FND_CONCURRENT_REQUESTS is purged via the "Purge Concurrent Request and/or Manager Data" program to manage table growth.
  • APIs: FND_CONCURRENT PL/SQL package provides programmatic access to submit/cancel requests.

Version-Specific Notes

  • 12.1.1: Limited to basic status tracking; lacks advanced features like granular phase tracking.
  • 12.2.2: Introduces columns like CLONE_ID for multi-node concurrent processing in clustered environments.

Common Query Examples

-- Active requests
SELECT request_id, program, status_code 
FROM fnd_concurrent_requests 
WHERE status_code = 'R';

-- Failed jobs (past 24 hours)
SELECT request_id, argument_text, actual_completion_date
FROM fnd_concurrent_requests
WHERE status_code = 'E' 
AND actual_completion_date > SYSDATE-1;

Conclusion

The FND_CONCURRENT_REQUESTS table is indispensable for EBS operations, providing end-to-end visibility into concurrent processing. Its schema design balances real-time monitoring needs with historical data retention, while integration with Concurrent Managers ensures reliable job execution. Administrators must optimize its maintenance (e.g., purging) to sustain system performance.