Search Results gr_xml_properties_map




Overview
Explore in AI Chat

Overview

The GR_XML_PROPERTIES_MAP table is a configuration and mapping repository within the Oracle E-Business Suite Process Manufacturing Regulatory Management module (GR). It exists in both EBS 12.1.1 and 12.2.2 and is owned by the GR schema. Its documented purpose is to serve as a GR XML mapping table, providing the correspondence between internal field identifiers and the XML element names used when regulatory data is rendered into or parsed from XML documents. In practical terms, the table acts as a translation dictionary: given a logical field (identified by FIELD_NAME_CODE) and a target property context (PROPERTY_ID), it supplies the exact XML_ELEMENT token that must appear in the generated or consumed XML payload.

The ETRM metadata classifies the object as standalone under a heuristic Data Vault assessment, meaning no foreign-key relationships to other tables were mined. As a modeling suggestion, this would be treated as an independent reference or lookup structure rather than a hub, link, or satellite, since it holds descriptive mapping metadata rather than business event or relationship data. This standalone status also implies that referential integrity for the mapping values is enforced by application logic and lookups rather than by database constraints.

Key Information Stored

The documented physical schema contains three columns, all of which are significant:

  • FIELD_NAME_CODE — Identifies the logical field or attribute being mapped. Part of both the primary key and the unique index.
  • PROPERTY_ID — Identifies the property context or XML property set to which the field belongs. Also part of the primary key and unique index.
  • XML_ELEMENT — The XML element name (tag) that corresponds to the field/property combination; this is the actual mapping value consumed during serialization.

The primary key is GR_XML_PROPERTIES_MAP_PK, defined on the composite of FIELD_NAME_CODE and PROPERTY_ID. A unique index, GR_XML_PROPERTIES_MAP_U1, is documented on the same two columns, confirming the business key: the combination of a field and a property must be unique. Because the primary key and the business-key candidate are identical here, FIELD_NAME_CODE and PROPERTY_ID together form the natural key, and no separate surrogate key column is documented. The remaining column, XML_ELEMENT, is the descriptive payload of the mapping.

Common Use Cases and Queries

The primary use case is resolving an XML element name during generation or ingestion of regulatory submissions and reports. Integration developers and regulatory analysts query this table to confirm which tag will be emitted for a given field, or to reverse-map an incoming XML element back to its internal field code.

  • Forward mapping lookup: SELECT XML_ELEMENT FROM GR.GR_XML_PROPERTIES_MAP WHERE FIELD_NAME_CODE = :field AND PROPERTY_ID = :prop;
  • Reverse mapping: SELECT FIELD_NAME_CODE, PROPERTY_ID FROM GR.GR_XML_PROPERTIES_MAP WHERE XML_ELEMENT = :tag;
  • Inventory of all elements for a property set: SELECT FIELD_NAME_CODE, XML_ELEMENT FROM GR.GR_XML_PROPERTIES_MAP WHERE PROPERTY_ID = :prop ORDER BY FIELD_NAME_CODE;
  • Duplicate detection and data quality: a group-by on XML_ELEMENT identifies tags reused across multiple field/property pairs.

Given the identical primary key and unique index, queries filtering on both key columns are fully indexed. Reporting use cases include documenting the XML interface specification and validating configuration before a regulatory submission cycle.

Related Objects

The ETRM metadata records no foreign-key relationships for this table, so it is treated as a standalone reference structure. Consequently, related objects are identified by functional proximity rather than by declared constraints:

  • GR_XML_PROPERTIES_MAP_PK / GR_XML_PROPERTIES_MAP_U1 — the primary key constraint and unique index that enforce uniqueness on (FIELD_NAME_CODE, PROPERTY_ID).
  • Other GR XML mapping tables in the same schema that share the property or field code domains; join candidates would be FIELD_NAME_CODE or PROPERTY_ID where corresponding columns exist.
  • GR regulatory reporting and submission programs that consume the mapping to build XML output.
  • GR lookup/reference tables holding valid FIELD_NAME_CODE or PROPERTY_ID values, which supply allowable values used by the application.

Because no FK constraints are documented, joins to these objects rely on shared value domains and must be validated against the application's own referential rules.