Search Results ame_engine




Overview
Explore in AI Chat

Overview

APPS.AME_ENGINE is the core runtime engine of the Oracle Approvals Management (AME) module in Oracle E-Business Suite 12.1.1 and 12.2.2. AME provides a rules-based framework for determining approvers, approval chains, and approval actions for any transaction that requires authorization — such as requisitions, purchase orders, invoices, and expense reports. While the AME setup tables and administrative forms define the rules, approver types, conditions, and action types, the AME_ENGINE package body is the executable component that reads that configuration and applies it to a live transaction to produce an approval list and a sequence of actions.

The package is classified as an OTHER API in the ETRM metadata and holds a VALID status in the APPS schema. It is heavily dependency-laden, referencing more than thirty AME tables and packages, and is itself referenced by 29 other packages. The engine is therefore not an island: it orchestrates calls into AME_API, AME_RULE_PKG, AME_ACTION_PKG, AME_APPROVAL_GROUP_PKG, AME_APPROVER_TYPE_PKG, AME_ATTRIBUTE_PKG, and AME_ADMIN_PKG, and it logs activity through FND_LOG and depends on Workflow roles (WF_ROLES) for approver resolution.

Key Procedures and Functions

The documented package exposes 120 procedures and functions. The principal entry points and their purposes are:

  • PROCESSPRODUCTIONRULES — Evaluates the AME rules configured for an item class against the transaction attributes to determine which rules fire.
  • PROCESSPRODUCTIONACTIONS — Executes the actions associated with the rules that fired, building or modifying the approver list.
  • PROCESSPRIORITIES — Applies priority ordering across rules and actions to resolve conflicts and determine execution sequence.
  • EVALPRIORITIESPERITEM — Evaluates priorities for each item class in the transaction.
  • APPROVERSMATCH — Determines whether candidate approvers satisfy the configured approver conditions.
  • CHECKATTRIBUTEVARIANT — Validates that an attribute value matches the variant expected by a rule or condition.
  • INSERTIONEXISTS — Checks for the presence of a pending insertion in the temporary transaction tables.
  • ISLOCALTRANSACTION / ISTESTTRANSACTION — Identify whether the transaction under evaluation is local or a test transaction, which affects processing behavior.
  • ISSTATICATTUSAGE — Determines whether an attribute usage is static, allowing cached rather than recomputed values.
  • GETAMEAPPLICATIONID / GETAPPROVALPROCESSCOMPLETEYN / GETATTRIBUTENAME — Utility accessors returning application identifier, completion status, and attribute names.
  • GETACTIONTYPE* family — GETACTIONTYPEID, GETACTIONTYPENAME, GETACTIONTYPEPACKAGENAME, GETACTIONTYPEUSAGE, GETACTIONTYPEVOTINGREGIME, GETACTIONTYPEORDERNUMBER, and GETACTIONTYPECHAINORDERMODE retrieve metadata describing configured action types.

Tables Accessed

The engine reads and writes a broad set of AME configuration and transactional tables, including AME_ACTIONS, AME_ACTION_TYPES, AME_ACTION_TYPE_CONFIG, AME_ACTION_TYPE_USAGES, and AME_ACTION_USAGES (action type configuration and usage); AME_APPROVAL_GROUPS, AME_APPROVAL_GROUP_CONFIG, and AME_APPROVAL_GROUP_MEMBERS (approval group definitions); AME_APPROVER_TYPES and AME_APPROVER_TYPE_PKG (approver source definitions); AME_ATTRIBUTES and AME_ATTRIBUTE_USAGES (transaction attribute metadata); AME_CONDITIONS and AME_CONDITION_USAGES (rule conditions); AME_CALLING_APPS (registered calling applications); and the AME_TEMP_* tables used to stage in-flight transactions and approver lists. Together these tables provide the rule, action, and approver metadata that the engine transforms into a runtime approval hierarchy.

Usage Notes

AME_ENGINE is invoked indirectly by calling applications rather than being called directly by end users. When a transaction is submitted for approval — typically through the AME_API or the calling application's workflow — the engine is triggered to evaluate rules, resolve approvers, and return the approval list. It is also exercised by the AME test transaction facility, which simulates approval processing without committing production data (hence ISTESTTRANSACTION). Customizations should use AME_API rather than calling AME_ENGINE procedures directly, since the internal procedures assume a fully staged transaction context. Because the package is referenced by 29 other database objects, changes to its interface carry significant regression risk and must be handled through supported Oracle patching.