Results for “fnd_request_temp”

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

Overview

FND_REQUEST_TEMP is a table owned by the APPLSYS schema in Oracle E-Business Suite, defined within the FND — Application Object Library product. In the ETRM documentation for 12.2.2, the object carries the short description "Retrofitted," indicating it is a supporting repository rather than a principal transactional or configuration table. It is documented with a three-column physical schema and is verified as VALID.

Functionally, FND_REQUEST_TEMP serves as a temporary or staging store associated with the concurrent request infrastructure. Records are organized by REQUEST_ID and FILE_TYPE, which together form the composite primary key FND_REQUEST_TEMP_PK. This construct allows an individual concurrent request to hold multiple cached or generated file artifacts, each distinguished by a type classification.

The heuristic Data Vault classification mined from the foreign-key structure is standalone. From a modeling perspective, this is best treated as an isolated hub/satellite-like construct: the composite key (REQUEST_ID, FILE_TYPE) behaves as a business key within its own domain, while FILE_NAME supplies the descriptive attribute. No explicit foreign-key dependencies to other documented objects were identified.

Key Information Stored

All three documented columns are central to the table's purpose:

• REQUEST_ID — The identifier of the concurrent request to which the temporary entry belongs. It is the first component of the FND_REQUEST_TEMP_PK composite primary key and is the principal business-key candidate, aligning the row with a request in the concurrent manager ecosystem.
• FILE_TYPE — A classification value for the stored artifact, distinguishing one kind of temporary file from another under the same request. It is the second component of the composite primary key.
• FILENAME — The name or path of the temporary file associated with the (REQUEST_ID, FILE_TYPE) combination. This is the primary descriptive attribute rather than a key component.

Because the surrogate is itself composite, there is no separate single-column surrogate key; REQUEST_ID and FILE_TYPE together act as the unique business identifier, while FILENAME carries the payload.

Common Use Cases and Queries

The table is typically used to trace which temporary file artifacts exist for a given concurrent request, and to verify that a manager-held file type has been registered before a subscriber reads or processes it.

• Enumerating the file types held by a specific request:

  SELECT request_id, file_type, filename
  FROM   applsys.fnd_request_temp
  WHERE  request_id = :p_request_id;

• Locating a request by file type:

  SELECT request_id, filename
  FROM   applsys.fnd_request_temp
  WHERE  file_type = :p_file_type;

• Joining to the concurrent request header for context (for example, FND_CONCURRENT_REQUESTS on REQUEST_ID) to correlate temporary files with request status, phase, and completion time.

Related Objects

The strongest logical relationship is to the concurrent request header, joined through REQUEST_ID. The most significant associated objects include:

• FND_CONCURRENT_REQUESTS — joined on REQUEST_ID, the parent request record.
• FND_CONCURRENT_PROGRAMS — defines the program run by the request, reached via the request header.
• FND_REQUEST_HISTORY — historical request activity correlated by REQUEST_ID.
• FND_CONCURRENT_PROGRAMS and the request API family (FND_REQUEST.SUBMIT_REQUEST) provide the runtime context that generates the temporary file entries.

Given the standalone classification and the absence of documented foreign keys, these associations are logical rather than enforced, and any child objects should be validated against the actual 12.1.1 or 12.2.2 instance before reliance.