Search Results igs_ru_named_rule_pkg




Overview
Explore in AI Chat

Overview

IGS_RU_NAMED_RULE_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the Rules Engine of the Oracle Student System (formerly Oracle iLearning / Student Information Systems) product family, specifically the "RU" (Rules) component. In the IGS naming convention, the RU prefix designates rule-processing objects. This package encapsulates the persistence logic for the IGS_RU_NAMED_RULE entity — the association that binds a specific named rule record to the underlying rule, group, and description definitions used during rules evaluation.

The package is classified as an "OTHER" API under ETRM documentation, meaning it is not a public, business-facing PL/SQL API but rather a generated or internal data-access layer. Its primary business purpose is to provide the row-level insert, update, delete, locking, foreign-key retrieval, and DML-constraint validation services for the IGS_RU_NAMED_RULE table, allowing higher-level rule construction and evaluation packages to maintain the named-rule metadata safely and consistently.

Key Procedures and Functions

The documented package exposes eleven callable units. They fall into standard generated-table-handler patterns:

  • INSERT_ROW — Inserts a new row into the named-rule table, populating the object's columns for a new named-rule association.
  • LOCK_ROW — Obtains a row-level lock on an existing named-rule record, preventing concurrent modification during validation or update sequences.
  • UPDATE_ROW — Modifies an existing named-rule row, persisting changes to the stored attributes.
  • ADD_ROW — Combines insert semantics (typically insert plus primary-key derivation) to add a new named-rule entry to the repository.
  • DELETE_ROW — Removes a named-rule record from the table, allowing cleanup of obsolete rule associations.
  • GET_PK_FOR_VALIDATION — Retrieves the primary-key value required to validate a named-rule row prior to DML, supporting referential and uniqueness checks.
  • CHECK_CONSTRAINTS — Enforces the table's business and data constraints, ensuring that any insert or update satisfies the defined validation rules.
  • BEFORE_DML — The pre-DML trigger logic that orchestrates validation, key derivation, and constraint checking before a row is inserted or updated.
  • GET_FK_IGS_RU_DESCRIPTION — Returns the foreign-key reference to the IGS_RU_DESCRIPTION table, linking the named rule to its descriptive definition.
  • GET_FK_IGS_RU_GROUP — Returns the foreign-key reference to the IGS_RU_GROUP table, linking the named rule to its parent grouping.
  • GET_FK_IGS_RU_RULE — Returns the foreign-key reference to the IGS_RU_RULE table, linking the named rule to its underlying rule definition.

Tables Accessed

The package accesses the IGS_RU_NAMED_RULE table through its APPS synonym as the sole documented base table. This table stores the named-rule records themselves. The three GET_FK_* functions indicate that IGS_RU_NAMED_RULE also carries foreign-key columns pointing to IGS_RU_DESCRIPTION, IGS_RU_GROUP, and IGS_RU_RULE; the package resolves these references but the metadata lists only IGS_RU_NAMED_RULE as directly accessed. No other table is documented as read or written.

Usage Notes

IGS_RU_NAMED_RULE_PKG is referenced by eight other packages, including IGS_RU_CALL_PKG, IGS_RU_CALL_RULE_PKG, IGS_RU_DESCRIPTION_PKG, IGS_RU_GEN_002, IGS_RU_GEN_005, IGS_RU_GEN_006, IGS_RU_GROUP_PKG, and IGS_RU_ITEM_PKG, as well as itself (recursive reference). This confirms it is an internal dependency invoked by the Rules Engine's set-up and evaluation flows rather than called directly from forms or concurrent programs.

Typical invocation occurs during rule maintenance — creating or amending named rules that attach descriptions, groups, and rule definitions — and during rules runtime processing when named rules are resolved and validated. Because the package includes both BEFORE_DML and CHECK_CONSTRAINTS, it functions as the central gatekeeper for data integrity on named-rule rows. In EBS 12.1.1 and 12.2.2, direct custom calls are discouraged; integrations and extensions should employ the higher-level RU packages that already orchestrate this handler. Oracle's ETRM documentation confirms the object as VALID in the APPS schema; because the source body and SQL statements are not exposed, parameter signatures should be verified against the deployed database rather than assumed.