Search Results jg_zz_vat_box_allocs

Overview

FND_CONCURRENT_REQUESTS is the central operational table of the Oracle E-Business Suite Concurrent Processing architecture, owned by the APPLSYS schema and belonging to the FND — Application Object Library product. Every concurrent program submission in Oracle EBS 12.1.1 and 12.2.2 — whether a report, a PL/SQL batch, a request set, or a spawned sub-request — is recorded as a row in this table. The table captures the full lifecycle of a submission: the requesting user and responsibility, the program and its arguments, scheduling and priority attributes, runtime phase and status codes, log and output file locations, and resource consumption statistics. It is therefore both a transactional ledger and a system-of-record for the concurrent manager (FND_CONCURRENT_PROCESSES) and the standard "View Requests" and "Concurrent Requests" diagnostic screens.

Under the heuristic Data Vault classification supplied in the metadata, FND_CONCURRENT_REQUESTS is described as hub-leaning. In a Data Vault model this suggests treating REQUEST_ID as the hub business key, with descriptive and volatile attributes — status, phase, timing, and resource counters — modeled as satellites, and the extensive foreign key set modeled as links.

Key Information Stored

The documented primary key is FND_CONCURRENT_REQUESTS_PK on REQUEST_ID, which is the surrogate identifier used by every dependent table. A unique index, FND_CONCURRENT_REQUESTS_U1, also exists on REQUEST_ID; EBS does not expose a natural business key for a concurrent request beyond this internally assigned number. Among the 132 documented columns, the most operationally significant are:

• PHASE_CODE and STATUS_CODE — the two ordinal fields that drive all request monitoring. Phase values include PENDING, RUNNING, COMPLETE, and INACTIVE; status values include Normal, Warning, Error, Terminated, Cancelled, and Disabled.
• REQUEST_DATE, REQUESTED_START_DATE, ACTUAL_START_DATE, ACTUAL_COMPLETION_DATE, and STALE_DATE — submission, desired, actual, and staleness timestamps.
• CONCURRENT_PROGRAM_ID and PROGRAM_APPLICATION_ID — the executed concurrent program, joining to FND_CONCURRENT_PROGRAMS.
• REQUESTED_BY, RESPONSIBILITY_ID, and RESPONSIBILITY_APPLICATION_ID — the requesting user and the responsibility (application context) under which the request ran.
• PARENT_REQUEST_ID and PRIORITY_REQUEST_ID — self-referencing keys that identify request-set parents, child submissions, and priority-linked requests.
• ARGUMENT1 through ARGUMENT25 and ARGUMENT_TEXT — the run-time parameters passed to the program.
• LOGFILE_NAME, OUTFILE_NAME, and the associated LOGFILE_NODE_NAME / OUTFILE_NODE_NAME — paths and tier nodes where log and output files were written.
• COMPLETION_TEXT, COMPLETION_CODE, and OUTCOME_CODE — diagnostic text emitted at completion, essential for error triage.
• CONTROLLING_MANAGER, ORACLE_ID, ORACLE_PROCESS_ID, and OS_PROCESS_ID — the manager and OS/DB process identity that serviced the request.
• CPU_SECONDS, LOGICAL_IOS, PHYSICAL_IOS, and OFILE_SIZE / LFILE_SIZE — performance metrics used in tuning reports.
• NODE_NAME1 / NODE_NAME2, PRINTER, and PRINT_STYLE — manager-tier and printing attributes.
• SECURITY_GROUP_ID, ORG_ID, and EDITION_NAME — multi-org, security-group, and edition-based redefinition context.

Common Use Cases and Queries

Development and DBA teams rely on this table for monitoring long-running programs, diagnosing failures, and reclaiming orphaned rows. A typical query identifies currently active requests:

• SELECT request_id, concurrent_program_id, requested_by, phase_code, status_code FROM fnd_concurrent_requests WHERE phase_code IN ('R','P') ORDER BY request_date;
• Locating the log path for a failed request:
  SELECT request_id, logfile_name, logfile_node_name, completion_text FROM fnd_concurrent_requests WHERE request_id = :request_id;
• Grouping request-set children to their parent:
  SELECT request_id, parent_request_id, phase_code, status_code FROM fnd_concurrent_requests WHERE parent_request_id = :parent;
• Performance trending of a program over a date range using CPU_SECONDS and ACTUAL_COMPLETION_DATE.
• Finding requests submitted by a specific user or responsibility in support of an audit or a "who ran this?" investigation.

Because of its high transaction volume and frequent updates, queries against this table should be scoped by REQUEST_DATE or REQUEST_ID; unbounded scans on PHASE_CODE alone can perform poorly on busy instances.

Related Objects

The foreign key structure documents this table as a hub linking many dependent objects. The most significant relationships are:

• FND_CONCURRENT_PROGRAMS — joined on CONCURRENT_PROGRAM_ID and PROGRAM_APPLICATION_ID; defines the program metadata for each request.
• FND_USER — joined on REQUESTED_BY; identifies the submitting user.
• FND_RESPONSIBILITY — joined on RESPONSIBILITY_ID and RESPONSIBILITY_APPLICATION_ID.
• FND_CONCURRENT_REQUESTS (self-join) — via PARENT_REQUEST_ID and PRIORITY_REQUEST_ID for request-set hierarchies.
• FND_CONCURRENT_PROCESSES — joined on CONTROLLING_MANAGER; identifies the concurrent manager that ran the request.
• FND_NODES — referenced by LOGFILE_NODE_NAME, OUTFILE_NODE_NAME, NODE_NAME1, and NODE_NAME2; locates files across the application tier.
• FND_CONC_REQUEST_ARGUMENTS and FND_RUN_REQUESTS — dependent detail tables keyed by REQUEST_ID and PARENT_REQUEST_ID.
• FND_ATTACHED_DOCUMENTS and FND_DOCUMENTS — attach output artifacts to a request via REQUEST_ID.
• Operational data tables such as GL_INTERFACE, GL_JE_BATCHES, AP_INVOICES_ALL, FA_MASS_ADDITIONS, and AR_CONC_PROCESS_REQUESTS — these carry a REQUEST_ID (or equivalent) pointing back to the originating concurrent request, enabling traceability from a business record to the batch process that created it.