Search Results igw_business_rule_lines




Overview
Explore in AI Chat

Overview

IGW_BUSINESS_RULE_LINES is a child table within the IGW (Grants Proposal) module of Oracle E-Business Suite, documented as part of the ETRM schema reference for releases 12.1.1 and 12.2.2. The table stores business rule expressions — the individual expression lines that together compose a configurable business rule. Each row represents one expression fragment, such as a bracketed condition, an operator, or a comparison between a left-hand value and a right-hand value, and the complete rule is reconstructed by ordering these fragments by sequence number.

The object is flagged as obsolete in the ETRM metadata, and the documentation records "Not implemented in this database." Organizations running current EBS releases should therefore treat this as a historical schema artifact rather than an active configuration surface. Under a heuristic Data Vault classification derived from its foreign key structure, the table is satellite-leaning: it carries descriptive, attribute-rich detail (expression components) that hangs off a parent key rather than serving as an independent hub or an association between two hubs.

Key Information Stored

The documented primary key, IGW_BUS_RULE_LINES_PK, is a composite surrogate over RULE_ID and EXPRESSION_ID. A unique index, IGW_BUS_RULE_LINES_U1, also covers RULE_ID and EXPRESSION_ID, making this pair the effective business-key candidate for the table. Of the 16 documented columns, the most significant are:

  • RULE_ID — foreign key to IGW_BUSINESS_RULES_ALL, identifying the parent business rule to which the expression line belongs.
  • EXPRESSION_ID — the second component of the primary key, uniquely identifying each expression line within its parent rule.
  • EXPRESSION_SEQUENCE_NUMBER — ordering of the expression fragments, which governs how the rule is reconstructed and evaluated.
  • EXPRESSION_TYPE — classifies the nature of the expression fragment.
  • LBRACKETS / RBRACKETS — left and right bracket characters that preserve grouping and precedence in the rule expression.
  • LVALUE / RVALUE — the left-hand and right-hand operands of the comparison.
  • OPERATOR — the comparison operator applied between the left and right values.
  • LOGICAL_OPERATOR — the boolean connective (for example AND or OR) joining this line to the next.
  • RVALUE_ID — an optional identifier resolving the right-hand value to a referenced entity.
  • Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN capture who created and last modified each expression line.

Common Use Cases and Queries

The principal use case is reconstructing and auditing business rule logic for grants proposal processing. A typical query orders expression lines by sequence number within a rule:

SELECT rule_id, expression_id, expression_sequence_number, lvalue, operator, rvalue, logical_operator FROM igw_business_rule_lines WHERE rule_id = :p_rule_id ORDER BY expression_sequence_number;

Reporting scenarios include extracting all rules that reference a specific value or operator, generating rule documentation for compliance review, and cross-checking orphaned expression lines where the parent RULE_ID no longer exists. Because the table is documented as obsolete, migration and upgrade analysis — identifying leftover rows before conversion — is another common exercise.

Related Objects

The most significant relationship is the foreign key from IGW_BUSINESS_RULE_LINES.RULE_ID to IGW_BUSINESS_RULES_ALL.RULE_ID, which establishes IGW_BUSINESS_RULES_ALL as the parent and principal join target. Any query joining the two should use RULE_ID as the join column:

SELECT r.rule_id, l.expression_sequence_number, l.lvalue, l.operator, l.rvalue FROM igw_business_rules_all r JOIN igw_business_rule_lines l ON l.rule_id = r.rule_id;

Beyond this FK, the metadata documents no further dependent tables or APIs, consistent with the module's obsolete status. Related IGW objects — including the Grants Proposal business rule header definition and its expression evaluation logic — should be treated as a legacy family, with current functionality typically delivered through successor modules.