Search Results iby_process_conc_requests




Overview
Explore in AI Chat

Overview

IBY_PROCESS_CONC_REQUESTS is an Oracle Payments (IBY) table that stores concurrent requests associated with payment processing activities. Its documented description is simply "Concurrent requests," and it functions as the linkage between a Payment object — identified by an OBJECT_ID and OBJECT_TYPE pair — and the Oracle EBS concurrent program request that performs work against that object. In this role it supports the Payments module's process scheduling, status tracking, and reconciliation of asynchronous jobs such as payment process requests, payment instruction creation, settlement, and transmission activities that run through the Oracle Concurrent Manager.

The ETRM metadata classifies the object's Data Vault relationship as "standalone" based on mined foreign key structure. As a modeling suggestion, this indicates the table has no dependent tables imposing referential constraints on it and can be treated as an independent structure rather than a strict hub, link, or satellite. Modeling it as a hub with satellites keyed to its composite primary key, or as a persistent mapping between a business object and a concurrent request, are both defensible interpretations given the documentation.

Key Information Stored

The table is documented with ten columns in Oracle EBS 12.2.2. The most significant are:

  • OBJECT_ID — the surrogate identifier of the payment-process object (for example a payment process request or payment instruction) that the concurrent request relates to.
  • OBJECT_TYPE — a discriminator indicating the type of object referenced by OBJECT_ID, allowing the same table to associate different payment entities with requests.
  • REQUEST_ID — the concurrent request identifier that links to the Oracle Concurrent Manager request table FND_CONCURRENT_REQUESTS.
  • COMPLETED_FLAG — a status indicator recording whether the associated concurrent request has finished, supporting polling and reconciliation logic.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — standard EBS audit columns capturing who created or last modified the row and when.
  • LAST_UPDATE_LOGIN — the login identifier of the session responsible for the most recent update.
  • OBJECT_VERSION_NUMBER — the optimistic locking column used by the Oracle Application Framework to detect concurrent updates.

The primary key IBY_PROCESS_CONC_REQUESTS_PK is the composite (OBJECT_ID, OBJECT_TYPE, REQUEST_ID). This composite defines the uniqueness rule for the table; the surrogate key element is OBJECT_ID combined with OBJECT_TYPE and REQUEST_ID, while the natural business keys are effectively the object reference (OBJECT_ID plus OBJECT_TYPE) and the concurrent request reference (REQUEST_ID).

Common Use Cases and Queries

Typical reporting scenarios include finding all concurrent requests submitted for a given payment object, identifying requests that have not completed, and analyzing request activity over time. Representative SQL patterns follow.

  • Locate all requests for a specific object: SELECT request_id, completed_flag FROM iby_process_conc_requests WHERE object_id = :id AND object_type = :type;
  • Find outstanding (uncompleted) jobs: SELECT object_id, object_type, request_id FROM iby_process_conc_requests WHERE completed_flag = 'N';
  • Join to the Concurrent Manager for phase and status: SELECT p.object_id, r.phase_code, r.status_code FROM iby_process_conc_requests p, fnd_concurrent_requests r WHERE p.request_id = r.request_id;
  • Audit recent activity: SELECT object_id, request_id, creation_date FROM iby_process_conc_requests WHERE creation_date > SYSDATE - 7;

These queries support operational dashboards, troubleshooting of stalled payment jobs, and reconciliation of payment objects to their execution history.

Related Objects

The most significant related objects include FND_CONCURRENT_REQUESTS (joined on REQUEST_ID), which holds the concurrent request definition, phase, and status; IBY_PAYMENT_PROCESS_REQUESTS and IBY_PAYMENTS, which may be referenced through OBJECT_ID and OBJECT_TYPE; FND_CONCURRENT_PROGRAMS and FND_CONCURRENT_PROGRAM_RUN_AS, which describe the program executed; IBY_PAYMENT_INSTRUCTIONS and IBY_SETTLEMENTS, which represent settlement-stage objects; and the Oracle Payments public APIs and the Payment Process Request program that create rows in this table when submitting concurrent work. Joins are consistently established through REQUEST_ID against the Concurrent Manager and through OBJECT_ID plus OBJECT_TYPE against the relevant payment entity.