Search Results fnd_concurrent_requests_u1

Overview

APPLSYS.FND_CONCURRENT_REQUESTS is the central transactional table in Oracle E-Business Suite that stores information about individual concurrent requests. Every time a user submits a concurrent program, report, or process—whether through the Submit Requests form, the FND_REQUEST API, or programmatically via a scheduler—a row is inserted here. The table is part of the FND design data (FND.FND_CONCURRENT_REQUESTS) and is shipped as a VALID, core application object present in both Release 12.1.1 and 12.2.2.

From a Data Vault modeling perspective, the dependency structure mined from the foreign-key relationships classifies this table as hub-leaning. This is a suggestion only: REQUEST_ID behaves as a durable business identifier that many downstream transactional tables reference, rather than as a value that changes over time. In analytic or warehouse designs, it is reasonable to model REQUEST_ID as a hub key, with descriptive attributes (status, phase, dates, counts) carried in an associated satellite or, more commonly, denormalized into a request-history dimension.

Key Information Stored

The table contains 132 documented columns. The surrogate primary key is REQUEST_ID, sourced from the FND_CONCURRENT_REQUESTS_PK constraint. A separate unique index, FND_CONCURRENT_REQUESTS_U1, is defined on REQUEST_ID as well, making it the documented business-key candidate for this object.

The most significant columns fall into several functional groups:

• Identity and ownership: REQUEST_ID, REQUESTED_BY (FK to FND_USER), REQUEST_DATE, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID, ORG_ID.
• Program definition: CONCURRENT_PROGRAM_ID, PROGRAM_APPLICATION_ID (FK to FND_CONCURRENT_PROGRAMS), REQUEST_TYPE, NUMBER_OF_ARGUMENTS.
• Status and phase: PHASE_CODE, STATUS_CODE, COMPLETION_TEXT, COMPLETION_CODE, OUTCOME_CODE, OUTCOME_PRODUCT, POST_REQUEST_STATUS.
• Scheduling and execution: REQUESTED_START_DATE, ACTUAL_START_DATE, ACTUAL_COMPLETION_DATE, HOLD_FLAG, SINGLE_THREAD_FLAG, ENFORCE_SERIALITY_FLAG, QUEUE_METHOD_CODE, CONTROLLING_MANAGER (FK to FND_CONCURRENT_PROCESSES), ORACLE_PROCESS_ID, OS_PROCESS_ID.
• Hierarchy: PARENT_REQUEST_ID and ROOT_REQUEST_ID (self-referencing FKs), HAS_SUB_REQUEST, IS_SUB_REQUEST.
• Arguments and output: ARGUMENT_TEXT, ARGUMENT1 through ARGUMENT25, LOGFILE_NAME, OUTFILE_NAME, LOGFILE_NODE_NAME, OUTFILE_NODE_NAME, PRINTER, PRINT_STYLE.
• Resubmission: RESUBMITTED, RESUBMIT_INTERVAL, RESUBMIT_INTERVAL_TYPE_CODE, RESUBMIT_END_DATE, RESUB_COUNT.
• Resource metrics: CPU_SECONDS, LOGICAL_IOS, PHYSICAL_IOS, OFILE_SIZE, LFILE_SIZE.

If a concurrent program requires more than 25 arguments, arguments 26 through 100 are stored in FND_CONC_REQUEST_ARGUMENTS, keyed by REQUEST_ID.

Common Use Cases and Queries

Operations and support teams query this table constantly to monitor running and pending jobs, diagnose failures, and reconcile report output. A typical query retrieves the most recent requests for a user or program:

• Current status of active requests: filter on PHASE_CODE in ('R','P') and STATUS_CODE = 'R' to list what is actually executing.
• Failed requests: STATUS_CODE = 'E' combined with COMPLETION_TEXT to surface the error message.
• Runtime analysis: ACTUAL_COMPLETION_DATE minus ACTUAL_START_DATE, joined to CONCURRENT_PROGRAM_ID, to profile long-running jobs.
• Hierarchy reporting: walk PARENT_REQUEST_ID and ROOT_REQUEST_ID to reconstruct a request set or multi-request submission tree.
• Output retrieval: resolve LOGFILE_NAME and OUTFILE_NAME against FND_NODES to locate files on the application tier.
• Purge and archival: select rows by REQUEST_DATE older than a retention threshold, taking care to respect the numerous inbound foreign keys from subledger and GL tables.

Because of the volume of data and the breadth of inbound references, queries against this table should generally be restricted by REQUEST_DATE, REQUESTED_BY, or CONCURRENT_PROGRAM_ID, and executed outside peak concurrent processing windows.

Related Objects

The following are among the most significant objects that reference or depend on FND_CONCURRENT_REQUESTS:

• FND_CONCURRENT_PROGRAMS — joined on PROGRAM_APPLICATION_ID and CONCURRENT_PROGRAM_ID; defines the program executed by each request.
• FND_USER — joined on REQUESTED_BY; identifies the submitter.
• FND_LOGINS — joined on CONC_LOGIN_ID; ties a request to the authenticated session.
• FND_CONC_REQUEST_ARGUMENTS — joined on REQUEST_ID; stores ARGUMENT26 through ARGUMENT100.
• FND_CONCURRENT_PROCESSES — joined on CONTROLLING_MANAGER; identifies the concurrent manager that ran the request.
• FND_NODES — joined on LOGFILE_NODE_NAME, OUTFILE_NODE_NAME, NODE_NAME1, and NODE_NAME2.
• FND_RUN_REQUESTS and FND_RUN_REQ_PP_ACTIONS — joined on REQUEST_ID and PARENT_REQUEST_ID; support the concurrent request submission APIs.
• FND_CONCURRENT_REQUESTS (self-referencing) — joined on PARENT_REQUEST_ID and PRIORITY_REQUEST_ID to model sub-requests and priority chains.
• GL_JE_BATCHES, GL_INTERFACE, and GL_ALLOC_HISTORY — joined on REQUEST_ID; link General Ledger postings and imports back to the originating request.
• FA_MASS_ADDITIONS and related Asset Management tables — joined on REQUEST_ID or CREATE_BATCH_ID; capture batch processes initiated by concurrent requests.