Results for “type_id”

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

Overview

FND_CONCURRENT_QUEUE_CONTENT is a core Application Object Library (FND) table that stores the specialization rules governing how Oracle E-Business Suite concurrent managers select and process concurrent requests. While FND_CONCURRENT_QUEUES defines the physical and logical work shifts available to a concurrent manager, FND_CONCURRENT_QUEUE_CONTENT holds the rules that determine which requests are eligible to run within a given queue. It is owned by the APPLSYS schema and is classified as VALID across the 12.1.1 and 12.2.2 releases documented in ETRM.

From a Data Vault modeling perspective, the ETRM metadata classifies this object heuristically as a link. This reflects its role as an associative entity that resolves many-to-many relationships between concurrent queues and the various inclusion targets (programs, request classes, users, complex rules, and Oracle user IDs) that a queue may be configured to accept or reject.

Key Information Stored

The table's granularity is defined by its composite primary key FND_CONC_QUEUE_CONTENT_PK, comprising QUEUE_APPLICATION_ID, CONCURRENT_QUEUE_ID, TYPE_CODE, TYPE_APPLICATION_ID, and TYPE_ID. A parallel unique index, FND_CONCURRENT_QUEUE_CONT_U1, extends this key with ZD_EDITION_NAME, supporting the 12.2.2 online patching editioning model. There is no single surrogate sequence key; the business key is the composite itself.

• QUEUE_APPLICATION_ID / CONCURRENT_QUEUE_ID — Identify the parent concurrent queue (joined to FND_CONCURRENT_QUEUES).
• TYPE_CODE — Discriminator that determines the kind of inclusion entity referenced (for example program, request class, user, or complex rule).
• TYPE_APPLICATION_ID — Application context of the referenced type entity; resolves against FND_CONCURRENT_PROGRAMS, FND_CONCURRENT_REQUEST_CLASS, and FND_CONCURRENT_COMPLEX_RULES depending on TYPE_CODE.
• TYPE_ID — Identifier of the specific referenced entity; resolves against FND_ORACLE_USERID or FND_USER for user-based rules.
• INCLUDE_FLAG — Indicates whether the specified type is included in or excluded from the queue, enabling both positive and negative specialization.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — Standard Oracle EBS WHO columns for audit tracking.
• ZD_EDITION_NAME — Editioning column introduced in 12.2.x for online patching support.

Common Use Cases and Queries

DBAs and functional administrators use this table to audit and troubleshoot why a concurrent request was processed (or ignored) by a particular manager. Typical queries join queue content to programs and request classes to render a human-readable specialization list:

• Diagnose request routing — Determine which queues are configured to pick up a specific concurrent program by filtering on TYPE_CODE and TYPE_ID.
• Validate include/exclude logic — Inspect INCLUDE_FLAG to confirm whether a program or request class is explicitly excluded from a manager.
• Impact analysis before changes — Before disabling a user or deleting a request class, list all queues referencing it to gauge downstream effects.
• Reporting — Build a "queue specialization" report joining FND_CONCURRENT_QUEUES, this table, and FND_CONCURRENT_PROGRAMS to document manager configuration for SOX or audit purposes.

A representative pattern selects queue names and program names by joining on the composite keys, filtering by ZD_EDITION_NAME = 'ORA$BASE' in 12.2.x environments to isolate the run-edition rows.

Related Objects

The table participates in an unusually rich FK web because TYPE_ID and TYPE_APPLICATION_ID form a polymorphic reference. Significant related objects include:

• FND_CONCURRENT_QUEUES — Parent via QUEUE_APPLICATION_ID, CONCURRENT_QUEUE_ID.
• FND_CONCURRENT_PROGRAMS — Resolves program-type specialization via TYPE_APPLICATION_ID, TYPE_ID.
• FND_CONCURRENT_REQUEST_CLASS — Resolves request-class specialization.
• FND_CONCURRENT_COMPLEX_RULES — Resolves complex rule specialization.
• FND_USER — Resolves user-based specialization via TYPE_ID.
• FND_ORACLE_USERID — Resolves database user specialization via TYPE_ID.

Together these relationships allow a single queue definition to combine program, class, user, and rule-based specialization, which is the mechanism by which Oracle EBS concurrent managers achieve fine-grained workload control.