Search Results xdp_dqer_registration




Overview
Explore in AI Chat

Overview

The XDP_DQER_REGISTRATION table is an internal repository within the XDP (Provisioning) product module of Oracle E-Business Suite. As its description states, it is used for registering the processes responsible for dequeuing messages from internal queues. In practical terms, the table acts as a configuration and control registry: each row identifies a dequeuer process, associates it with an internal queue and a module, and thereby tells the provisioning infrastructure which background process is authorized to consume and act upon messages placed on a given internal queue.

The object resides in the XDP schema and holds a VALID status in both Oracle EBS 12.1.1 and 12.2.2. It is documented as a standalone table in the Data Vault sense. The heuristic Data Vault classification supplied in the metadata indicates no downstream dependent tables reference it through foreign keys, though it does itself reference FND_SECURITY_GROUPS. As a modeling suggestion, this object is best treated as a satellite-style reference or lookup table anchored on its natural business key (the dequeuer name) rather than as a hub or link, because it stores descriptive attributes about configured processes rather than relationships between multiple business entities.

Key Information Stored

The table contains 10 documented columns. The most significant of these, and their roles, are as follows:

  • DQER_NAME — The natural business key and the column on which the primary key XDP_DQER_REGISTRATION_PK is defined. It is also the sole column of the unique index XDP_DQER_REGISTRATION_U1, confirming it as the business-key candidate. It carries the logical name of the dequeuer registration.
  • DQER_PROCESS_ID — Identifies the registered dequeuer process, linking the registration record to the runnable process responsible for consuming messages.
  • INTERNAL_Q_NAME — The name of the internal queue from which the registered process dequeues messages. This is the core routing attribute of the record.
  • MODULE_NAME — The module to which the dequeuer and queue belong, enabling module-scoped registration and lookup.
  • SECURITY_GROUP_ID — The foreign-key column referencing FND_SECURITY_GROUPS, supporting multi-org and security-group partitioning of registration data.
  • CREATION_DATE and LAST_UPDATE_DATE — Audit timestamps recording when the registration was created and most recently changed.
  • CREATED_BY, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN — The standard EBS WHO columns capturing the user and login responsible for creation and the latest modification.

The surrogate primary key is XDP_DQER_REGISTRATION_PK, defined over DQER_NAME. Because the unique index XDP_DQER_REGISTRATION_U1 covers the same column, the business key and the primary key coincide, making DQER_NAME the definitive identifier for any given registration.

Common Use Cases and Queries

Typical usage centres on diagnosing and verifying which process handles a given internal queue, and on reporting the configured dequeuer landscape. A common query resolves a registration by its queue name:

  • SELECT dqer_name, dqer_process_id, module_name, security_group_id FROM xdp.xdp_dqer_registration WHERE internal_q_name = :queue_name; — identifies the registered dequeuer for a specific queue.
  • SELECT dqer_name, internal_q_name, module_name FROM xdp.xdp_dqer_registration WHERE module_name = :module ORDER BY dqer_name; — produces a module-scoped inventory of dequeuers.
  • SELECT * FROM xdp.xdp_dqer_registration WHERE dqer_name = :dqer_name; — retrieves the full registration record using the primary key.

Reporting use cases include auditing which queues have an active dequeuer registered (to detect unserviced queues), tracing a message-handling problem back to the responsible process via DQER_PROCESS_ID, and reconciling registrations against module ownership. Because the table is internally maintained, queries are read-only in practice; changes are made by XDP provisioning logic rather than by direct DML.

Related Objects

The documented relationship data identifies the following significant dependencies and joins:

  • FND_SECURITY_GROUPS — referenced through XDP_DQER_REGISTRATION.SECURITY_GROUP_ID → FND_SECURITY_GROUPS, used to resolve the security group or operating unit context of a registration.
  • XDP_DQER_REGISTRATION_PK — the primary key constraint on DQER_NAME, enforcing uniqueness of each dequeuer registration.
  • XDP_DQER_REGISTRATION_U1 — the unique index on DQER_NAME, acting as the business-key candidate and supporting direct lookups by name.
  • XDP_DQER_REGISTRATION itself, in the XDP schema, is the subject object; related XDP queue and provisioning tables derive their process routing from the INTERNAL_Q_NAME and DQER_PROCESS_ID attributes defined here.

No downstream tables reference this object through foreign keys, confirming its standalone classification. Its principal integration point is therefore the FND security-group model, supplemented at runtime by XDP provisioning components that read the queue and process identifiers recorded in each row.