Search Results igs_as_item_assessor_pkg




Overview

The APPS.IGS_AS_ITEM_ASSESSOR_PKG package is a component of the Oracle E-Business Suite Student Systems (iGS) module, specifically within the Assessment (AS) subsystem. Its principal business function is to manage the association between assessment items and assessors — that is, the individuals or organizational entities responsible for evaluating a given assessment item within an academic or institutional context. In EBS release 12.1.1 and 12.2.2 this package is classified under the API classification "OTHER" and holds a VALID status in the APPS schema.

Functionally, the package operates as a table-handler (a "TAPI"-style wrapper) around the IGS_AS_ITEM_ASSESSOR entity. It encapsulates the referential integrity and constraint validation logic required to safely insert, update, and delete rows in the underlying base table while preserving foreign key relationships to assessment items, assessor types, locations, persons, and unit modes.

Key Procedures and Functions

The ETRM documentation records 13 procedures and functions within the package. These may be grouped by purpose:

  • INSERT_ROW — Inserts a new item-assessor association record into the base table, populating the mandatory columns and defaulting derived attributes.
  • ADD_ROW — Provides an alternative insert path, typically used where a distinct set of defaults or business rules applies relative to INSERT_ROW.
  • UPDATE_ROW — Modifies existing item-assessor records, applying the applicable validation rules before committing changes.
  • DELETE_ROW — Removes an item-assessor association record, subject to any applicable constraint checks.
  • LOCK_ROW — Acquires a row-level lock to serialize concurrent DML and prevent lost updates, commonly invoked before an UPDATE_ROW or DELETE_ROW.
  • CHECK_CONSTRAINTS — Validates the business and referential constraints of the row prior to committing a DML operation.
  • BEFORE_DML — A trigger-support procedure that executes preliminary validation and defaulting logic before the DML operation itself.
  • GET_PK_FOR_VALIDATION — Returns the primary key surrogate value used for validation within calling packages.
  • GET_FK_IGS_AS_ASSESSMNT_ITM — Retrieves the foreign key reference to the associated assessment item.
  • GET_FK_IGS_AS_ASSESSOR_TYPE — Retrieves the foreign key reference to the assessor type.
  • GET_FK_IGS_AD_LOCATION — Retrieves the foreign key reference to the address/location record.
  • GET_FK_IGS_PE_PERSON — Retrieves the foreign key reference to the person record for the assessor.
  • GET_FK_IGS_AS_UNIT_MODE — Retrieves the foreign key reference to the assessment unit mode.

The GET_FK_* functions expose lookup utilities so that calling code can resolve or validate the various foreign key dependencies without directly querying the base tables.

Tables Accessed

The ETRM metadata documents a single base table referenced through its APPS synonym:

  • IGS_AS_ITEM_ASSESSOR — The core entity storing item-to-assessor assignments. This package reads and writes rows here via all DML procedures and resolves its foreign key columns through the GET_FK_* functions.

The foreign key resolution functions imply reads against parent entities such as assessment items (IGS_AS_ASSESSMNT_ITM), assessor types, locations (IGS_AD_LOCATION), persons (IGS_PE_PERSON), and unit modes (IGS_AS_UNIT_MODE), which are validated through CHECK_CONSTRAINTS.

Usage Notes

The package is referenced by five or more sibling iGS packages, including IGS_AD_LOCATION_PKG, IGS_AS_ASSESSMNT_ITM_PKG, IGS_AS_ASSESSOR_TYPE_PKG, IGS_AS_GEN_006, and IGS_AS_UNIT_MODE_PKG. These dependencies indicate that the package is typically invoked indirectly — the assessment item, assessor type, location, and unit mode handlers call into it to validate or maintain the item-assessor relationship whenever those parent entities are created, changed, or removed. It is generally not invoked directly by end users but rather through the assessment forms and concurrent programs that drive iGS assessment configuration. Custom extensions should observe the standard table-handler protocol: call BEFORE_DML for validation, then invoke the appropriate DML procedure, and commit only within the caller's transaction boundary.