Search Results ece_rule_list




Overview
Explore in AI Chat

Overview

The ECE_RULE_LIST table resides in the EC (e-Commerce Gateway) schema and is documented as VALID in Oracle E-Business Suite 12.1.1 and 12.2.2. Its stated purpose is to store column list rule information — the metadata that governs how column-level transformation rules are grouped and applied when e-Commerce Gateway processes inbound and outbound transaction data. In practice, ECE_RULE_LIST acts as the rule grouping header: each row pairs a list rule with an underlying column rule, providing the reference structure that the gateway's translation engine consults when mapping interface columns to their targets.

From a Data Vault modeling perspective, the mined FK structure classifies this object as hub-leaning. This is a heuristic suggestion rather than a physical property: the table carries a surrogate primary key, a unique business key candidate, and a foreign key to another rule-defining entity. Modelers should treat it as a business-key-bearing reference entity that anchors dependent detail rows, rather than as a pure transactional satellite.

Key Information Stored

The documented physical schema for ETRM 12.2.2 lists 12 columns. The most significant are:

The overlap between the primary key and the unique index on LIST_RULE_ID confirms that LIST_RULE_ID is the single business identifier for a list rule definition; downstream code can safely join on it without ambiguity.

Common Use Cases and Queries

Typical usage centers on validation and impact analysis before running e-Commerce Gateway transactions. A common query resolves a list rule to its underlying column rule:

  • SELECT r.list_rule_id, r.column_rule_id, r.comparison_code, c.* FROM ece_rule_list r, ece_column_rules c WHERE r.column_rule_id = c.column_rule_id;
  • Audit reporting on rule maintenance: filter on LAST_UPDATE_DATE and LAST_UPDATED_BY to identify rules changed during a release window.
  • Concurrent program tracing: join REQUEST_ID to FND_CONCURRENT_REQUESTS to determine which program introduced or modified a given rule.
  • Detail expansion: join to ECE_RULE_LIST_DETAILS on LIST_RULE_ID to enumerate the individual entries belonging to each list rule.
  • Orphan detection: outer-join COLUMN_RULE_ID to ECE_COLUMN_RULES to find list rules referencing missing or inactive column rules.

Because the table is a configuration entity rather than a high-volume fact, queries are usually low-cost, but they should be run against a reporting copy when performed during active gateway processing.

Related Objects

The documented FK relationships identify the following significant dependencies:

  • ECE_COLUMN_RULES — Referenced through ECE_RULE_LIST.COLUMN_RULE_ID. Defines the column-level rule that each list rule points to.
  • ECE_RULE_LIST_DETAILS — References ECE_RULE_LIST via LIST_RULE_ID. The child table holding the detailed entries for each list rule.
  • FND_CONCURRENT_REQUESTS — Joined through REQUEST_ID to trace the concurrent program context of rule creation and updates.
  • FND_APPLICATION — Resolves PROGRAM_APPLICATION_ID to the owning application of the generating program.
  • FND_USER — Resolves CREATED_BY and LAST_UPDATED_BY to user names for audit reporting.

Together these objects form the rule-definition cluster within the e-Commerce Gateway schema, with ECE_RULE_LIST serving as the connective layer between column rules and their list-level detail rows.