Search Results ece_mappings




Overview
Explore in AI Chat

Overview

ECE_MAPPINGS is a configuration table owned by the EC schema within the Oracle E-Business Suite e-Commerce Gateway module (EC). It stores the mapping definitions used to translate transaction data between Oracle EBS internal structures and the flat-file or EDI message formats exchanged with external trading partners. Each row represents a named map that governs how a specific transaction type is constructed, parsed, or transformed during inbound and outbound gateway processing. Because the mappings drive field-level correspondence between source columns and target file elements, ECE_MAPPINGS acts as a central reference point for the extraction and load logic executed by the e-Commerce Gateway concurrent programs.

From a dimensional modeling perspective, the mined relationship data classifies this object as standalone. Applying a heuristic Data Vault classification, ECE_MAPPINGS most closely resembles a hub-style reference entity: it holds a stable set of uniquely identified business keys (MAP_CODE) with descriptive attributes attached directly, and it does not participate in any documented foreign-key links to other tables. The absence of outgoing foreign keys suggests the mapping definitions are referenced logically by gateway processing code rather than by enforced relational constraints.

Key Information Stored

The ETRM 12.2.2 physical schema documents seven columns for EC.ECE_MAPPINGS:

  • MAP_ID — The surrogate primary key, enforced through the ECE_MAPPINGS_PK constraint. This numeric identifier uniquely distinguishes each mapping definition and is the value internal programs use to retrieve a specific map.
  • MAP_CODE — The business-key candidate, protected by the unique index ECE_MAPPINGS_U1. This is the human-readable code by which a mapping is identified in configuration and processing logic.
  • DESCRIPTION — Free-text explanation of the mapping's purpose, aiding administrators who maintain large mapping catalogues.
  • MAP_TYPE — Categorizes the nature of the mapping, distinguishing among the transformation styles the gateway supports.
  • TRANSACTION_TYPE — Associates the map with a specific gateway transaction, such as purchase orders, invoices, or shipping notices, identifying which interface the map serves.
  • ROOT_ELEMENT — Names the top-level element or record structure from which mapping begins, anchoring the mapping hierarchy to the correct segment of the message.
  • ENABLED — A status flag that determines whether the mapping is active and therefore eligible for use during gateway runs; disabled maps remain defined but are bypassed.

The distinction between MAP_ID and MAP_CODE is significant: MAP_ID provides referential stability for internal processing, while MAP_CODE provides the externally meaningful identifier that administrators and interface definitions reference. The unique index on MAP_CODE guarantees that no two mappings share a business name.

Common Use Cases and Queries

Typical scenarios include auditing which mappings are active for a given transaction type, diagnosing why an outbound interface produced unexpected output, and reviewing mapping coverage before enabling a new trading partner interface. A common query lists all enabled mappings for a particular transaction:

  • SELECT map_id, map_code, description, map_type, root_element FROM ec.ece_mappings WHERE transaction_type = :p_type AND enabled = 'Y' ORDER BY map_code;
  • SELECT map_code, description FROM ec.ece_mappings WHERE map_id = :p_map_id; — resolves a surrogate key to its business code during troubleshooting.
  • SELECT transaction_type, COUNT(*) FROM ec.ece_mappings WHERE enabled = 'Y' GROUP BY transaction_type; — provides coverage counts per interface for reporting.

Reporting use cases center on configuration inventories, change tracking across environments, and pre-upgrade validation that required mappings remain enabled and correctly typed.

Related Objects

The mined relationship data documents no foreign keys from ECE_MAPPINGS, consistent with its standalone classification; therefore no join columns are asserted from that source. In practice, the table is consumed alongside the broader e-Commerce Gateway configuration and processing objects that share the EC schema, including transaction-definition and interface-setup tables, the gateway concurrent programs that read mapping definitions at runtime, and the interface data staging tables populated when a mapping is applied. Because the mapping is selected by MAP_CODE or MAP_ID within processing logic rather than through declarative constraints, integrators should verify relationships against their specific implementation rather than relying on enforced referential integrity. Administrators maintaining this table should treat MAP_CODE and ENABLED as the primary levers, since they control both identification and runtime availability of each mapping.