Results for “fnd_concurrent_processes_u1”

12 results




AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

FND_CONCURRENT_PROCESSES is an Application Object Library (FND) table owned by the APPLSYS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the operating system and Oracle database process identifiers associated with concurrent managers and their worker processes. In practical terms, it is the runtime registry of concurrent processing activity: every time a concurrent manager starts, spawns a worker, or services a request, a corresponding row is created or updated in this table to record the underlying OS process and database session identity. It is therefore central to diagnosing concurrent manager behavior, troubleshooting hung or orphaned processes, and correlating EBS concurrent activity with database sessions and server-level processes.

The documented column count is 33, with the surrogate primary key exposed through FND_CONCURRENT_PROCESSES_PK on CONCURRENT_PROCESS_ID, and a unique index FND_CONCURRENT_PROCESSES_U1 on the same column. From a Data Vault modeling perspective, the mined classification is satellite-leaning: the table holds descriptive, volatile attributes about a process instance rather than serving as a pure hub or link, and the surrogate key CONCURRENT_PROCESS_ID is the anchor for those attributes.

Key Information Stored

Not every one of the 33 columns carries equal diagnostic weight. The most significant documented columns include:

The distinction between the surrogate key (CONCURRENT_PROCESS_ID) and the business-key candidate (the same column surfaced via FND_CONCURRENT_PROCESSES_U1) matters for integration design: downstream tables reference the surrogate identifier, most notably FND_CONCURRENT_REQUESTS.CONTROLLING_MANAGER.

Common Use Cases and Queries

Typical scenarios include locating the OS-level process behind a hung concurrent request, verifying which node is running a manager, and reconciling EBS processes against V$SESSION or operating-system process listings. A useful pattern joins the process registry to its queue and node context:

  • Query processes currently active by status: SELECT CONCURRENT_PROCESS_ID, OS_PROCESS_ID, ORACLE_PROCESS_ID, NODE_NAME FROM FND_CONCURRENT_PROCESSES WHERE PROCESS_STATUS_CODE = 'RUNNING';
  • Join to the queue to name the manager: SELECT p.CONCURRENT_PROCESS_ID, q.USER_CONCURRENT_QUEUE_NAME, p.PROCESS_STATUS_CODE FROM FND_CONCURRENT_PROCESSES p, FND_CONCURRENT_QUEUES q WHERE p.CONCURRENT_QUEUE_ID = q.CONCURRENT_QUEUE_ID AND p.QUEUE_APPLICATION_ID = q.APPLICATION_ID;
  • Correlate to requests to see which manager controls a given request, using FND_CONCURRENT_REQUESTS.CONTROLLING_MANAGER.
  • Report process durations from PROCESS_START_DATE, or detect stalls using LAST_TXN_START and LAST_TXN_END.

These queries support concurrent manager monitoring, capacity reporting, and incident triage.

Related Objects

The following objects are most significant based on the documented foreign-key relationships and reverse references:

  • FND_CONCURRENT_QUEUES — referenced via QUEUE_APPLICATION_ID and CONCURRENT_QUEUE_ID; provides manager and queue definitions.
  • FND_SESSIONS — referenced via SESSION_ID; links processes to database sessions.
  • FND_NODES — referenced via NODE_NAME; identifies the application tier node.
  • FND_CONCURRENT_REQUESTS — references this table through CONTROLLING_MANAGER, tying each concurrent request to its controlling manager process.

Together these relationships position FND_CONCURRENT_PROCESSES as the operational bridge between concurrent requests, manager definitions, database sessions, and physical server nodes.