Search Results att_seq

Overview

JDR_ATTRIBUTES is a table owned by the APPLSYS schema and documented under the FND — Application Object Library product within Oracle E-Business Suite 12.1.1 and 12.2.2. It is part of the Oracle EBS "JDR" (Java Development Runtime / Developer Runtime) family of objects that support the metadata-driven, repository-style configuration used by the Oracle Application Framework (OAF) and related extensibility infrastructure. In practical terms, JDR_ATTRIBUTES holds the set of named attribute name/value pairs that are attached to a parent component definition, allowing properties and settings to be stored in a flexible, row-per-attribute manner rather than as fixed columns.

The table carries a heuristic Data Vault classification of standalone, meaning the FK/PK mining did not identify inbound or outbound foreign-key dependencies linking it into a broader hub-link-satellite graph. From a modeling perspective, this suggests JDR_ATTRIBUTES is best treated as a self-contained satellite-style structure keyed to a parent component, rather than as a hub or a link that joins multiple business entities.

Key Information Stored

The documented physical schema for JDR_ATTRIBUTES in ETRM 12.2.2 contains six columns. The most significant are:

• ATT_COMP_DOCID — Identifier of the parent component document to which the attribute belongs. This is the first component of the primary key and of the unique business-key index.
• ATT_COMP_SEQ — Sequence number of the component within the parent document, providing the second part of the composite key.
• ATT_SEQ — Sequence number of the individual attribute row, completing the three-part primary key. Together, ATT_COMP_DOCID, ATT_COMP_SEQ, and ATT_SEQ form the primary key JDR_ATTRIBUTES_PK.
• ATT_NAME — The name of the attribute, i.e., the property or setting key.
• ATT_VALUE — The value assigned to the corresponding attribute name.
• ZD_EDITION_NAME — Editioning column used to support Oracle EBS Online Patching (Edition-Based Redefinition) in 12.2.x. It participates in the unique index JDR_ATTRIBUTES_U1.

The surrogate/composite primary key is JDR_ATTRIBUTES_PK (ATT_COMP_DOCID, ATT_COMP_SEQ, ATT_SEQ). The business-key candidate is captured by the unique index JDR_ATTRIBUTES_U1 (ATT_COMP_DOCID, ATT_COMP_SEQ, ATT_SEQ, ZD_EDITION_NAME), which extends the primary key with the editioning column so that multiple patched editions can be distinguished simultaneously.

Common Use Cases and Queries

JDR_ATTRIBUTES is typically queried when diagnosing or reporting the metadata-driven configuration of an OAF component. A common pattern is to retrieve all attributes for a given parent component:

• SELECT att_name, att_value FROM applsys.jdr_attributes WHERE att_comp_docid = :docid AND att_comp_seq = :seq ORDER BY att_seq;
• SELECT * FROM applsys.jdr_attributes WHERE att_name = '.xx_custom_attr'; — to find where a specific attribute name is used across components.
• Edition-aware lookups join or filter on ZD_EDITION_NAME to scope results to the currently active edition during online patching.

Reporting use cases include auditing custom attributes applied to seeded components, extracting configuration differences between environments, and supporting upgrade analysis where attribute rows must be validated against expected definitions.

Related Objects

The metadata classifies JDR_ATTRIBUTES as standalone, and no FK dependencies were mined. Its logical dependencies are therefore inferred from the JDR naming family and the parent component reference held in ATT_COMP_DOCID/ATT_COMP_SEQ:

• JDR_COMPONENTS — the parent component table, joined on the component document identifier and sequence.
• JDR_DOCUMENTS — the owning document record referenced by the parent component.
• JDR_PATHS — repository path definitions for JDR documents.
• JDR_ATTRIBUTES variants and related JDR metadata tables (e.g., component-attribute listings) that share the same key structure.
• FND_LOOKUP / AOL configuration views — reporting joins that resolve attribute values into human-readable descriptions.

Because the object is standalone, cross-table integrity is enforced by application logic rather than by database foreign keys, and joins to the parent component must always be validated against ATT_COMP_DOCID and ATT_COMP_SEQ.