Search Results ame_api2




Overview
Explore in AI Chat

Overview

APPS.AME_API2 is the primary public API package for the Oracle Approvals Management Engine (AME) in Oracle E-Business Suite 12.1.1 and 12.2.2. AME is the rules-based engine that determines, at transaction time, who must approve a given business document (a purchase order, an expense report, a requisition, a journal, and so on) and in what order. Rather than duplicating approval logic in each calling module, applications such as Purchasing, Payables, iProcurement, and General Ledger delegate approver resolution to AME.

AME_API2 exposes that resolution logic as a set of programmatically callable entry points. Internally the package orchestrates the AME rule engine — through internal calls to AME_ENGINE, AME_UTIL, AME_UTIL2, and the approver and action type packages — and returns the resulting approver lists, item statuses, and administrative approvers to the caller. It also supports mutation of the runtime approval context (temporary insertions and deletions) and retrieval of the recorded approval history for a transaction. The package body holds the implementation logic; the package specification (AME_API2) declares the interface and is what external callers reference. The body's status is VALID, and the package is not itself referenced by any other database object, confirming its role as a top-level integration surface.

Key Procedures and Functions

The documented interface contains 28 procedures and functions organized around four functional groupings:

  • Approver resolution. GETALLAPPROVERS1 through GETALLAPPROVERS7 are progressive overloads that return the complete ordered approver list for a transaction. The variants accommodate different combinations of transaction identifiers, item classes, and calling applications. GETALLITEMAPPROVERS1 and GETALLITEMAPPROVERS2 perform the equivalent resolution for a specific approval item. GETNEXTAPPROVERS1 through GETNEXTAPPROVERS4 return only the next approver or approvers, enabling incremental, step-at-a-time approval processing. GETANDRECORDALLAPPROVERS resolves approvers and persists the resulting approval history in a single call, typically used when the calling application wants AME to finalize the approver set rather than merely preview it.
  • Status reporting. GETITEMSTATUS1, GETITEMSTATUS2, and GETITEMSTATUSES return the current AME status of one or more approval items — whether they are approved, pending, rejected, or otherwise, and which approver is currently active.
  • Administrative approver lookup. GETADMINAPPROVER returns the administrative approver configured for a transaction, used when AME cannot resolve a normal approver (for example, when a rule produces no approver or an approver is unavailable) and the transaction must be routed to an administrator.
  • Approval maintenance. VALIDATEAPPROVER verifies that a nominated approver is a valid, eligible approver for the transaction context, allowing callers to perform pre-flight validation. CLEARALLAPPROVALS removes all approval state associated with a transaction, supporting resubmission and cancellation scenarios.

Tables Accessed

AME_API2 reads and writes the core AME runtime and configuration tables. On the configuration side it consults AME_ACTION_TYPES_TL, AME_ACTION_TYPES_VL, and AME_ACTION_TYPE_USAGES to determine the permitted approval actions; AME_APPROVER_TYPES and AME_APPROVER_TYPE_USAGES to identify approver type definitions and their usages; AME_CALLING_APPS to resolve which calling application and transaction type a request belongs to; and AME_CONFIG_VARS for engine configuration parameters. On the runtime side it works with AME_TEMP_INSERTIONS and AME_TEMP_DELETIONS, which capture temporary (one-time) approver insertions and deletions applied to a single transaction, and AME_TEMP_OLD_APPROVER_LISTS, which preserves the prior approver list when the engine recomputes it. AME_TRANS_APPROVAL_HISTORY stores the finalized approval records produced by GETANDRECORDALLAPPROVERS and related calls. WF_ROLES is referenced to resolve and validate approvers as Oracle Workflow roles. PLITBLM is the standard Oracle-supplied table of PL/SQL objects used by the dependency scanner.

Usage Notes

AME_API2 is not typically invoked directly by end users. Its normal consumers are the approval-processing code paths within EBS application modules — for example the approver resolution logic in Purchasing and iProcurement, expense approval in Internet Expenses, and journal approval in General Ledger. Concurrent programs that pre-compute or re-evaluate approvers for batches of transactions also call these entry points. Customizations and extensions that need to integrate a non-standard document type or a bespoke approval flow invoke AME_API2 after registering the transaction type with AME via AME_CALLING_APPS. Typical sequencing is to call a GETALLAPPROVERS or GETALLITEMAPPROVERS variant to preview the list, optionally follow with VALIDATEAPPROVER for eligibility checks, and finish with GETANDRECORDALLAPPROVERS to persist the result. Because the package performs writes to AME_TEMP_INSERTIONS, AME_TEMP_DELETIONS, and AME_TRANS_APPROVAL_HISTORY, callers must issue explicit commits according to their transaction boundaries. The numbered overloads exist to preserve backward compatibility; new development should select the variant matching the current transaction structure and avoid relying on deprecated signatures. As with all AME interactions, the calling application is responsible for supplying the correct transaction and item identifiers so the engine can evaluate the appropriate rules.