Search Results umx_reg_requests




Overview
Explore in AI Chat

Overview

The UMX_REG_REQUESTS table is a core data object within the Oracle E-Business Suite (EBS) Application Object Library (FND) module. Owned by the APPLSYS schema, this table serves as the central repository for storing information related to user registration requests. Its primary role is to support the User Management (UMX) functionality, which governs the processes for requesting, approving, and provisioning user accounts and access within the EBS ecosystem. The table tracks the lifecycle of a registration request, from its initiation to its final status, and is integral to the self-service and administrative workflows for user management in both EBS 12.1.1 and 12.2.2.

Key Information Stored

The table's structure is designed to capture the essential details of a registration transaction. Its primary key is the REG_REQUEST_ID, which uniquely identifies each request. Critical foreign key relationships define the parties and services involved. The REQUESTED_BY_USER_ID and REQUESTED_FOR_USER_ID columns link to FND_USER, identifying the requester and the intended user account, respectively. For external registrations, the REQUESTED_FOR_PARTY_ID links to HZ_PARTIES in the Trading Community Architecture (TCA) to associate the request with a person or organization record. The REG_SERVICE_CODE links to UMX_REG_SERVICES_B, defining the specific type of registration service (e.g., new user, role request) being invoked. Additional columns typically track the request's current status, creation date, last update date, and relevant justification or comments.

Common Use Cases and Queries

This table is central to administrative reporting and auditing of user registration activities. Common scenarios include monitoring pending approvals, analyzing registration volumes, and troubleshooting failed requests. A typical query might join with FND_USER and HZ_PARTIES to generate a comprehensive registration audit report.

  • Sample Query for Pending Requests:
    SELECT req.reg_request_id,
          req.creation_date,
          by_user.user_name requested_by,
          for_user.user_name requested_for,
          party.party_name
    FROM apps.umx_reg_requests req,
          apps.fnd_user by_user,
          apps.fnd_user for_user,
          apps.hz_parties party
    WHERE req.requested_by_user_id = by_user.user_id
      AND req.requested_for_user_id = for_user.user_id(+)
      AND req.requested_for_party_id = party.party_id(+)
      AND req.request_status = 'PENDING';
  • Integration Point: The data in this table is primarily manipulated through the official UMX and FND public APIs. Direct DML operations are strongly discouraged.

Related Objects

As indicated by its foreign keys, UMX_REG_REQUESTS has strong dependencies on several fundamental EBS tables. The FND_USER table is referenced twice, for both the requester and recipient of the access. Integration with the Trading Community Architecture is established via the HZ_PARTIES table. The definition of the registration workflow itself is tied to the UMX_REG_SERVICES_B table. Furthermore, this table is likely referenced by various User Management (UMX) views, seed data tables for services, and the underlying PL/SQL packages that implement the registration business logic, forming a cohesive data model for user provisioning.