Search Results ame_util




Overview

AME_UTIL is the shared utility package body within the Oracle Approvals Management (AME) module of Oracle E-Business Suite, delivered under the APPS schema. It is classified in the ETRM metadata as a UTIL (utility) API, meaning it provides reusable helper routines rather than a transactional business API. Its role is to centralize the low-level operations that the rest of the AME engine depends on: currency conversion and formatting, canonical number-to-display string conversion, date and day string handling, HTML input/output filtering, configuration variable retrieval, approver and administrative name lookups, session and responsibility resolution, and standardized exception logging.

Because AME evaluates approval rules, generates approver lists, and processes transactions across a wide range of calling applications, AME_UTIL exists to keep formatting, security, and diagnostic behavior consistent across every AME component. The ETRM metadata records 114 documented procedures and functions and shows that the package is referenced by 241 other packages, confirming its position as a foundational dependency for the AME code base in both 12.1.1 and 12.2.2. The header version recorded in the source excerpt (ameoutil.pkb 120.8, dated 2011/05/17) reflects the lineage of the file across releases.

Key Procedures and Functions

The documented routines cover several functional groupings:

  • Number and currency handling: CANONNUMSTRINGTODISPLAYSTRING converts an internal canonical number string into a display string, optionally applying currency-specific formatting; CONVERTCURRENCY performs currency conversion using a conversion type, amount, and effective date, delegating the actual conversion through GL currency APIs.
  • Date and text formatting: DATESTRINGSTOSTRING, GETDAYSTRING, GETCARRIAGERETURN, FIELDDELIMITER, and ESCAPESPACECHARS provide consistent date, day-name, delimiter, and character-escaping behavior for AME output.
  • Security and rendering: FILTERHTMLUPONINPUT and FILTERHTMLUPONRENDERING sanitize user-supplied and rendered HTML, protecting AME pages from cross-site scripting and malformed markup.
  • Configuration and lookup helpers: GETCONFIGDESC, GETCONFIGVAR, GETCOLUMNLENGTH, GETLABEL, GETCURRENCYNAME, and GETCURRENTSTRIPESETID retrieve AME configuration metadata, labels, currency names, and the current stripe set.
  • Identity and responsibility resolution: GETCURRENTUSERID, GETADMINNAME, GETBUSGROUPNAME, GETCONTACTADMINSTRING, and GETHIGHESTRESPONSIBILITY resolve the effective user and the most authoritative responsibility for approval processing.

Two private logging routines, autonomousLog and nonautonomousLog, underpin the package's diagnostics, and canonNumStringToDisplayString routes errors through a runtimeException handler. Exact parameter lists are intentionally not reproduced here; consult the package specification for signatures.

Tables Accessed

AME_UTIL reads and writes a defined set of AME and EBS tables through APPS synonyms. AME_EXCEPTIONS_LOG and AME_EXCEPTIONS_LOG_S capture runtime exceptions raised during AME processing, which is why logging is embedded directly in utility routines. AME_CONFIG_VARS supplies configuration variable values returned by the GETCONFIGVAR family. AME_ATTRIBUTES, AME_ATTRIBUTE_USAGES, and AME_ITEM_CLASSES provide the metadata needed to interpret AME rule attributes and item classes. AME_TEMP_INSERTIONS, AME_TEMP_OLD_APPROVER_LISTS, and AME_TEMP_TRANSACTIONS support temporary staging used during approver-list generation and transaction processing. FND_USER and PER_ALL_PEOPLE_F resolve user and person identity for name and administrator lookups, while AK_WEB_USER_SEC_ATTR_VALUES supports web user security attribute retrieval. Native dependencies include DBMS_SQL and OWA_UTIL.

Usage Notes

AME_UTIL is not intended to be called directly by end users. It is invoked internally by the AME engine, by AME-related Oracle Forms, and by concurrent programs that generate or validate approval lists and process transactions. Because 241 packages reference it, customizations should avoid modifying it; extensions should be placed in separate custom packages that call the documented routines. The presence of autonomous and non-autonomous logging variants means errors can be persisted even when the calling transaction rolls back. In 12.1.1 and 12.2.2 the package behaves identically at the API level; differences are limited to underlying file versioning. Any custom code invoking AME_UTIL should treat it as a stable, read-mostly utility layer.