Search Results ame_api




Overview
Explore in AI Chat

Overview

AME_API is the primary public API package for the Oracle Approvals Management (AME) engine in Oracle E-Business Suite. AME provides the rules-based approval routing framework used across multiple EBS products, including Purchasing, iProcurement, Payables, Human Resources, and General Ledger. The package body AME_API implements the callable interface through which external modules, forms, and custom code invoke the approval engine to determine who must approve a given transaction and in what order.

The package is owned by the APPS schema and is a fully documented API, classified as an API in the ETRM metadata for release 12.2.2. It exposes 32 documented procedures and functions. AME_API depends on a broad set of AME configuration and runtime objects, including AME_ACTIONS, AME_APPROVER_TYPES, AME_APPROVAL_GROUPS, and the supporting packages AME_ENGINE, AME_UTIL, and AME_APPROVER_TYPE_PKG. It is referenced by 36 other database objects, confirming its role as a central integration point. AME_API is itself not referenced by any database object at the level captured in the dependency metadata.

Key Procedures and Functions

The documented interface covers approval resolution, rule retrieval, and list maintenance:

  • GETALLAPPROVERS and GETANDRECORDALLAPPROVERS — return the complete approver list for a transaction; the latter also persists the resolved list for subsequent processing.
  • VALIDATEAPPROVER — validates that a proposed approver satisfies AME approver-type and usage rules.
  • GETADMINAPPROVER — retrieves the administrative approver applicable to a transaction.
  • GETAPPLICABLERULES1, GETAPPLICABLERULES2, GETAPPLICABLERULES3 — return the rules applicable to a transaction, with the numbered variants supporting differing signatures or rule-set scopes.
  • GETAPPROVERSANDRULES1, GETAPPROVERSANDRULES2, GETAPPROVERSANDRULES3 — combine approver resolution and rule retrieval in a single call; the numbered variants again reflect multiple callable signatures.
  • GETRULEDESCRIPTION — returns the descriptive text associated with an AME rule.
  • DELETEAPPROVER and DELETEAPPROVERS — remove one or more approvers from the current approval list.
  • CLEARALLAPPROVALS — removes the entire approval list for the transaction.
  • CLEARDELETION, CLEARDELETIONS, CLEARINSERTION, CLEARINSERTIONS — remove staged deletion and insertion entries from the temporary approval structures.
  • GETAVAILABLEINSERTIONS and GETAVAILABLEORDERS — return candidate insertion points and available ordering positions for approver list modification.

Tables Accessed

AME_API reads and writes AME configuration and runtime tables through APPS synonyms. Configuration tables include AME_ACTIONS, AME_ACTION_TYPE_CONFIG, AME_ACTION_TYPE_USAGES, AME_ACTION_USAGES, AME_APPROVAL_GROUPS, AME_APPROVAL_GROUP_CONFIG, AME_APPROVAL_GROUP_ITEMS, AME_APPROVER_TYPES, AME_APPROVER_TYPE_USAGES, AME_ITEM_CLASS_USAGES, and AME_RULE_USAGES. These supply the rules, actions, approver types, and grouping definitions evaluated during approver resolution.

Runtime working tables include AME_TEMP_INSERTIONS and AME_TEMP_OLD_APPROVER_LISTS, which hold staged approver insertions and prior approval lists during list modification and regeneration. PLITBLM is the standard PL/SQL integer table type used for array-based parameter passing.

Usage Notes

AME_API is invoked from EBS forms and concurrent programs that require approval routing, and from custom PL/SQL that integrates with the AME engine. Typical usage involves establishing transaction context, calling a GETALLAPPROVERS or GETAPPROVERSANDRULES variant to resolve the list, then applying modifications via the deletion, insertion, and clear procedures. Because the package depends on AME_ENGINE, AME_UTIL, and related helpers, callers must ensure AME configuration is committed and the transaction attributes passed are complete. Direct DML against AME tables should be avoided; the API procedures provide the supported interface for list construction and maintenance. Custom code should call the appropriately numbered GET* variant matching the required signature and must not assume the full dependency structure of referenced private helpers.