Search Results xdp_dq_configuration_u1




Overview

XDP.XDP_DQ_CONFIGURATION is a seed data configuration table within the Oracle E-Business Suite XDP schema. It stores the runtime configuration of the application's internal dequeue (DQ) infrastructure — the set of queues used for asynchronous and background application processing. Each row in this table defines one application queue, its implementing queue table, the payload type it carries, and the number and nature of dequeue processes attached to it.

The table is populated during the installation process. Its most operationally significant columns — particularly NUM_OF_DQER — are user configurable, but the documentation is explicit that changes should be made only through the application user interface, specifically the Queue Console, rather than through direct DML. This restriction exists because the dequeue processes are attached to the queue runtime, and inconsistent configuration can stall or overload asynchronous processing.

From a dimensional modeling perspective, the heuristic Data Vault classification mined from the foreign-key structure is hub-leaning. XDP_DQ_CONFIGURATION behaves as a stable, keyed reference of queue identities rather than a transactional fact or a change-history satellite: INTERNAL_Q_NAME uniquely identifies each queue, and dependent translation data attaches to it. This suggests a hub-style treatment if the schema were re-cast into Data Vault form.

Key Information Stored

The primary key of the table is XDP_DQ_CONFIGURATION_PK, defined on INTERNAL_Q_NAME, the internal name of the queue used for application processing. The documented unique index XDP_DQ_CONFIGURATION_U1 covers INTERNAL_Q_NAME together with ZD_EDITION_NAME, which is an editioning artifact present in 12.2.x; in 12.1.1 the uniqueness is effectively on INTERNAL_Q_NAME alone. ZD_EDITION_NAME is therefore a business-key candidate in the 12.2.2 physical schema but not a true business attribute.

Common Use Cases and Queries

The principal operational use case is monitoring and tuning asynchronous processing capacity. Administrators reconcile the configured NUM_OF_DQER against actual queue depth to detect under-provisioned queues, and AWR or V$AQ views can be joined back to this table for reporting. For example:

  • SELECT internal_q_name, q_alias, state, num_of_dqer FROM xdp.xdp_dq_configuration WHERE state = 'DISABLED';
  • SELECT q_alias, queue_table_name, payload_type, exception_queue_name, max_retries FROM xdp.xdp_dq_configuration WHERE is_aq_flag = 'Y';
  • SELECT internal_q_name, display_sequence FROM xdp.xdp_dq_configuration ORDER BY display_sequence;

Because the table is seeded and UI-maintained, these queries are read-only diagnostics. Any change to NUM_OF_DQER or STATE made outside the Queue Console risks inconsistent runtime behavior and should be avoided.

Related Objects

The strongest documented relationship is the child table XDP_DQ_CONFIGURATION_TL, which references this table on INTERNAL_Q_NAME and holds translated queue metadata. Rows in the configuration table therefore act as the parent anchor for language-specific descriptions.

  • XDP_DQ_CONFIGURATION_TL — translation table; join on INTERNAL_Q_NAME.
  • FND_SECURITY_GROUPS — referenced by SECURITY_GROUP_ID; relevant in hosted environments.

Additional dependencies include the queue tables named by QUEUE_TABLE_NAME, the dequeue procedure named by DQ_PROC_NAME, and any Oracle Advanced Queuing dictionary views (V$AQ, ALL_QUEUES) that describe the runtime state of the queues configured here.