Search Results jtf_header_dtd




Overview
Explore in AI Chat

Overview

JTF_HEADER_DTD is a table in the JTF schema (CRM Foundation product family) that stores Document Type Definition (DTD) content used by the Oracle E-Business Suite CRM infrastructure. DTDs define the permissible structure of XML documents exchanged within the CRM Foundation messaging and integration layer. Each row in this table corresponds to a single named DTD whose full textual definition is persisted in a CLOB column (HEADER_DTD), allowing runtime processes to validate or render XML payloads against a registered document type. The table is present and VALID in both Oracle EBS 12.1.1 and 12.2.2; the documented physical schema under ETRM 12.2.2 includes 15 columns owned by JTF.

From a data-modeling perspective, the metadata classifies JTF_HEADER_DTD as standalone, meaning it participates in no foreign-key relationships to other tables. Under a heuristic Data Vault interpretation, this object is best modeled as a hub candidate: it holds a single natural business key (DTD_NAME) plus descriptive attributes, with no link or satellite dependencies declared. This classification is a modeling suggestion only, reflecting the absence of documented FK constraints rather than a formal Data Vault design.

Key Information Stored

The primary key of the table is JTF_HEADER_DTD_PK, defined on the surrogate column HEADER_DTD_ID. This surrogate key uniquely identifies each DTD record internally and is the column referenced by downstream consumers. The business-key candidate is DTD_NAME, a descriptive name that provides a human-readable identifier for the document type definition. No unique index is documented beyond a system LOB index (SYS_IL0000084358C00003$$), which supports the CLOB storage of the HEADER_DTD column.

The functional payload of the table resides in the following columns:

  • HEADER_DTD_ID — surrogate primary key, generated per record.
  • DTD_NAME — business name of the DTD; used by applications to look up a specific document type.
  • HEADER_DTD — the actual DTD text (CLOB) defining the XML document structure.
  • ACTIVE_FLAG — controls whether the DTD is currently enabled for use.
  • CREATED_BY, CREATION_DATE — standard audit columns recording record creation.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE — standard audit columns recording the most recent modification.
  • LAST_UPDATE_LOGIN — login identifier associated with the last update.
  • ATTRIBUTE1 through ATTRIBUTE5 — flexible descriptive (DDF) columns available for customer-specific extensions.
  • ZD_EDITION_NAME — editioning column used by the EBS 12.2 online patching (Edition-Based Redefinition) architecture; relevant only in 12.2.2.

Common Use Cases and Queries

Typical usage centers on resolving a DTD by name or listing all active DTDs. A standard lookup query retrieves the DTD content for a given document type:

  • SELECT header_dtd_id, dtd_name, header_dtd FROM jtf.jtf_header_dtd WHERE dtd_name = :p_name AND active_flag = 'Y';
  • SELECT dtd_name, active_flag, last_update_date FROM jtf.jtf_header_dtd ORDER BY dtd_name;
  • SELECT COUNT(*) FROM jtf.jtf_header_dtd WHERE active_flag = 'Y';

Reporting scenarios include auditing which DTDs have been modified (filtering on LAST_UPDATE_DATE), verifying active versus inactive definitions before integration releases, and inspecting the length of HEADER_DTD to detect unexpectedly large or truncated definitions. Because the table is standalone and small in cardinality, queries are inexpensive and do not require joins to other JTF tables.

Related Objects

The ETRM metadata documents no foreign-key relationships for JTF_HEADER_DTD, and the heuristic classification is standalone. Consequently, no join columns to other tables are formally defined. In practice, consumers resolve DTDs through the business key DTD_NAME rather than through relational joins, and the CLOB payload is read directly by XML validation or messaging code in the CRM Foundation layer. Where cross-referencing occurs, it is typically at the application level rather than through database constraints, so integrators should treat JTF_HEADER_DTD as a self-contained reference table whose only externally used identifiers are HEADER_DTD_ID and DTD_NAME.