Search Results validate_condition

Overview

AME_CONDITIONS_API is a public API in the Oracle Approvals Management (AME) module of Oracle E-Business Suite. It provides the programmatic interface for the creation, maintenance, and deletion of AME condition records, which define the business rules evaluated by the AME engine when determining approval routing for a transaction. Conditions in AME link an attribute (for example, an invoice amount, a transaction type, or a cost center) to a comparison operator and a value, and the set of conditions associated with a rule determines whether that rule fires. The package body carries the standard AME seed-data header comment (amecoapi.pkb), indicating that it forms part of the seeded AME rule-authoring infrastructure rather than a customer-specific extension. It is classified in ETRM as an API, meaning its procedures are intended to be callable from external code, typically from setup migration scripts or from other AME components.

Key Procedures and Functions

• INSERT_ROW — Creates a new AME condition record. This is the primary entry point for adding condition definitions to the AME repository, including the attribute reference, the operator, and any associated condition keys.
• DELETE_ROW — Removes an existing AME condition record. This is used when a condition definition is obsolete or when condition data must be corrected during setup maintenance.
• LOAD_ROW — Performs the seed-data load operation, inserting or updating an AME condition based on its unique key. This procedure supports the AME installation and upgrade process, where seeded conditions must be loaded idempotently without producing duplicate rows.

The package body additionally contains two internal helper procedures, OWNER_TO_WHO and KEY_TO_IDS, which are not part of the documented public API. OWNER_TO_WHO converts an owner identifier into the standard WHO columns (created by, last updated by, last update login) using AME_SEED_UTILITY.OWNER_AS_INTEGER. KEY_TO_IDS resolves a logical condition/attribute key into the numeric CONDITION_ID, ATTRIBUTE_ID, and condition count, performing date-effective lookups against AME_ATTRIBUTES and validating that the attribute is seeded before proceeding. Automated extraction of a validate_condition procedure is not supported by the documented metadata; validation of condition keys is performed inside KEY_TO_IDS.

Tables Accessed

• AME_CONDITIONS — The primary table holding condition definitions. INSERT_ROW, DELETE_ROW, and LOAD_ROW all write to this table, and KEY_TO_IDS counts existing rows for a CONDITION_ID.
• AME_ATTRIBUTES — Stores the attribute definitions against which conditions are built. KEY_TO_IDS reads this table to resolve an attribute name to its ATTRIBUTE_ID, applying the START_DATE/END_DATE date-effective window, and to determine whether the attribute originated as a seed row.
• AME_CONDITION_KEYS_S — Sequence source used to generate primary keys for new condition records during insert and load operations.
• DBMS_LOCK, DUAL, V$DATABASE, V$INSTANCE — Infrastructure references used for concurrency control and instance/database identification during seed loading and locking.

Usage Notes

AME_CONDITIONS_API is invoked primarily by AME setup forms and by concurrent programs that install or upgrade AME transaction-type definitions and seeded rules. During an AME installation or patch, LOAD_ROW is called to materialize the delivered condition set, while runtime rule-authoring channels use INSERT_ROW and DELETE_ROW. Customer and partner code that migrates AME configurations between instances can call these procedures directly, but the WHO columns should be populated consistently with AME_SEED_UTILITY conventions, and the caller must respect the date-effective windows on AME_ATTRIBUTES. Because the package holds no public validation routine beyond its internal key resolution logic, callers should confirm that referenced attributes exist and are currently effective before invoking INSERT_ROW or LOAD_ROW. The package is referenced by zero other PL/SQL packages in the documented metadata, so dependencies are limited to external callers, forms, and concurrent programs.