Search Results jtf_fm_partition_x_request




Overview
Explore in AI Chat

Overview

The JTF.JTF_FM_PARTITION_X_REQUEST table belongs to the JTF – CRM Foundation product family within Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to store the list of all partitions that will be pooled among FFM (Forms Functional Manager) requests. In practical terms, this is a control table that associates a partition — a horizontal slice used by the Forms Functional Manager to parallelize and distribute request processing — with a specific FFM request. By maintaining this mapping, the FFM framework knows which partitions are being worked on by which request, allowing concurrent processing of large data sets without contention.

The ETRM metadata classifies this object heuristically under the Data Vault model as standalone, which is a modeling suggestion indicating that it does not participate as a dependent child in a classic hub/link/satellite chain. This classification is consistent with its role as a small configuration and control table rather than as a transactional fact holder. The primary key, JTF_FM_PARTITION_X_REQ_PK, is defined on PARTITION_ID.

Key Information Stored

The documented physical schema in ETRM 12.2.2 contains three columns. The most important are:

  • PARTITION_ID — The surrogate primary key of the table and the column referenced by every dependent foreign key in the relationship model. It uniquely identifies each partition pool record and is the join key used throughout the FFM-related and Workflow schema objects that reference this table.
  • PARTITION_NAME — The descriptive, human-readable identifier for the partition. This is the primary business-key candidate, since administrators and reports use partition names rather than the numeric surrogate to identify a partition during FFM configuration and troubleshooting.
  • REQUEST_ID — The identifier of the FFM request to which the partition is assigned or within whose pool it participates. This links the partition record to the concurrent request infrastructure that drives Forms Functional Manager processing.

No unique index beyond the primary key is documented in the ETRM excerpts, so PARTITION_NAME should be treated as a business-key candidate rather than a confirmed unique constraint.

Common Use Cases and Queries

The table is typically queried during FFM administration, concurrent processing diagnostics, and partition-pooling analysis. A common pattern is to list the partitions pooled to a given request:

  • SELECT partition_id, partition_name, request_id FROM jtf.jtf_fm_partition_x_request WHERE request_id = :request_id; — retrieves all partitions attached to a specific FFM request.
  • SELECT request_id, COUNT(*) FROM jtf.jtf_fm_partition_x_request GROUP BY request_id; — reports how many partitions are pooled per request, useful for load-distribution review.
  • Joining to WF_DIRECTORY_PARTITIONS on PARTITION_ID resolves the partition to its directory-level metadata, supporting reconciliation between FFM pooling and Workflow directory partitions.

Because PARTITION_ID is referenced by a large set of Workflow and directory tables, this table is also used as an anchor in data-lineage and referential-integrity checks across the JTF, WF, HZ, and PER schemas.

Related Objects

The FK metadata shows that PARTITION_ID is referenced by numerous dependent tables, indicating this is a parent table for partition-scoped data. The most significant relationships include:

Together these dependencies confirm the table as a compact but central reference point for partition pooling in FFM requests and downstream Workflow, TCA, and HR directory processing.