Search Results ame_exceptions_log_fk1

Overview

HR.AME_EXCEPTIONS_LOG is a diagnostic interface table within the Oracle E-Business Suite Approvals Management Engine (AME) subsystem. AME is the rules framework that governs approval routing, approval authority limits, and approver list generation for transactions such as purchase orders, requisitions, expense reports, and human resource actions. When AME processes a transaction through its rules engine, runtime errors may occur — a missing approver, an unresolvable substitution, a malformed rule condition, or an internal PL/SQL failure. HR.AME_EXCEPTIONS_LOG captures the details of those exceptions so that administrators and developers can diagnose and remediate approval workflow failures.

The table resides in the APPS_TS_INTERFACE tablespace, consistent with its role as a transient diagnostic rather than transactional or master data. It is owned by the HR schema and registered in FND Design Data as PER.AME_EXCEPTIONS_LOG.

From a Data Vault modeling perspective, the heuristic classification is standalone. No incoming foreign keys from dependent child tables are documented beyond the optional SECURITY_GROUP_ID reference, and the table does not act as a parent for downstream references. It is best understood as a raw event or log capture rather than a hub, link, or satellite in a dimensional sense.

Key Information Stored

Each row records a single exception event raised during AME transaction processing. The most significant columns are:

• LOG_ID — Surrogate primary key. Enforced by the unique index AME_EXCEPTIONS_LOG_PK. This is the only documented unique business-key candidate; it is a system-assigned identifier, not a natural key.
• PACKAGE_NAME — The AME PL/SQL package that raised the error (for example, an internal AME rules or transaction processing package).
• ROUTINE_NAME — The specific procedure or function within the package where the exception originated.
• TRANSACTION_ID — The identifier of the AME transaction being processed when the exception occurred. This is the primary correlation point for tracing an error back to a specific approval transaction.
• APPLICATION_ID — The AME internal application identifier that indicates the transaction type. This column is indexed by the non-unique index AME_EXCEPTIONS_LOG_FK1 and is the most common filter for narrowing exceptions by transaction category.
• EXCEPTION_NUMBER — The Oracle error number associated with the exception.
• EXCEPTION_STRING — The exception message text, up to 4000 characters. This holds the actual error detail and is the primary content for diagnosis.
• SECURITY_GROUP_ID — Documented as "Not used." It references FND_SECURITY_GROUPS but carries no functional meaning in current releases.

Common Use Cases and Queries

The table is queried primarily during troubleshooting of AME approval failures. A typical diagnostic pattern retrieves the most recent exceptions for a specific transaction:

• SELECT LOG_ID, PACKAGE_NAME, ROUTINE_NAME, EXCEPTION_NUMBER, EXCEPTION_STRING FROM HR.AME_EXCEPTIONS_LOG WHERE TRANSACTION_ID = :transaction_id ORDER BY LOG_ID DESC;
• Filtering by APPLICATION_ID to isolate exceptions for a particular transaction type, leveraging AME_EXCEPTIONS_LOG_FK1 for performance.
• Scanning EXCEPTION_STRING with a LIKE predicate to identify recurring error signatures across a period.
• Joining to approval history and AME transaction tables to correlate logged exceptions with the approval action that failed.

Because the table grows continuously in active environments, reporting queries should be time-bounded or filtered by TRANSACTION_ID rather than scanned in full.

Related Objects

The documented dependency footprint is narrow. HR.AME_EXCEPTIONS_LOG references FND_SECURITY_GROUPS through SECURITY_GROUP_ID, a legacy column that is marked as not used. It does not reference any other database object directly, and it is referenced only by its own synonym AME_EXCEPTIONS_LOG#.

In practice, administrators relate this log to the broader AME table family — AME_TRANSACTIONS, AME_APPROVAL_GROUPS, AME_RULES, and the AME approval history tables — by joining on TRANSACTION_ID and APPLICATION_ID rather than through enforced foreign keys. Functional integration is realized through the AME PL/SQL APIs, which write to this table when errors are trapped during transaction processing.