Search Results jtf_fm_request_history_all




Overview
Explore in AI Chat

Overview

JTF_FM_REQUEST_HISTORY_ALL is a transactional table owned by the JTF schema within the CRM Foundation (JTF) product family of Oracle E-Business Suite, documented as VALID in both 12.1.1 and 12.2.2. Its documented purpose is to store request history information. In practical terms, the table functions as a historical log of "FM" (Foundation Manager / concurrent-style request) submissions, capturing each request instance, its submission timestamp, processing outcome, and the object or order context against which it was executed. Because the name ends in _ALL, the table is expected to participate in the standard EBS multi-organization or security-group filtering model, and the presence of ORG_ID and SECURITY_GROUP_ID confirms that organization-level and group-level row filtering is enforced through the usual _ALL semantics.

The ETRM metadata supplies a heuristic Data Vault classification of hub-leaning. This should be read as a modeling suggestion rather than a physical constraint: the table carries a stable business identifier (HIST_REQ_ID plus SUBMIT_DT_TM) that behaves like a hub key, while the surrounding descriptive and status attributes (outcome, priority, counts, dates) resemble satellite payload attached to that key. Functional implementers should not reorganize the physical model, but data-warehouse architects extracting from EBS can reasonably treat the composite key as a hub and the remaining 35 columns as a satellite.

Key Information Stored

The physical schema exposes 35 columns. The most operationally significant are summarized below.

Common Use Cases and Queries

Typical scenarios include auditing request throughput, diagnosing failed or stalled requests, and reconstructing the lifecycle of a request tied to an order or TCA object. A representative query joining the parent request row to its content history is shown below.

  • Request throughput by type and outcome over a date range, filtering on ORG_ID to respect multi-org access.
  • Failure analysis using OUTCOME_CODE / OUTCOME_DESC and STALL_COUNT to identify recurring problem requests.
  • Resubmission tracking via PARENT_REQ_ID and RESUBMIT_COUNT to measure retry volume.
  • Purge or archival reporting through PURGE_FLAG and F_DELETEDFLAG.

Sample SQL:

  • SELECT h.hist_req_id, h.submit_dt_tm, h.request_type, h.outcome_code, h.stall_count, c.content_id FROM jtf.jtf_fm_request_history_all h JOIN jtf.jtf_fm_content_history c ON c.hist_req_id = h.hist_req_id AND c.submit_dt_tm = h.submit_dt_tm WHERE h.org_id = :p_org_id AND h.submit_dt_tm >= :p_from_date ORDER BY h.submit_dt_tm DESC;

Related Objects

  • JTF_FM_CONTENT_HISTORY — the primary dependent table, linked on HIST_REQ_ID and SUBMIT_DT_TM; it stores the content payload associated with each request history row.
  • FND_SECURITY_GROUPS — referenced through SECURITY_GROUP_ID, providing the security-group context used for row-level filtering.
  • JTF_FM_REQUEST_HISTORY_ALL_U1 — the unique index that enforces the business key (HIST_REQ_ID, SUBMIT_DT_TM).
  • FND_ORG_SECURITY / ORG access views — through ORG_ID, alongside the standard _ALL multi-organization access pattern applied by EBS reporting.
  • Order and TCA object references — resolved dynamically through OBJECT_TYPE / OBJECT_ID and ORDER_ID rather than through static foreign keys.

The table is best treated as the historical anchor for FM request processing within CRM Foundation, with JTF_FM_CONTENT_HISTORY as its principal dependent child.