Search Results why_wait

Overview

FND_AMP_PRIVATE is a private PL/SQL package owned by the APPS schema and classified under the Applications Management Pack (AMP) utilities in Oracle E-Business Suite. Its stated purpose, per the package header, is to provide utilities for the Applications Management Pack. The package is declared AUTHID CURRENT_USER, meaning its unqualified object references resolve against the privileges of the invoking user rather than the defining user, a design choice consistent with a utility package intended for internal consumption by other AMP components.

The package serves the Oracle Concurrent Manager / Concurrent Processing framework by centralizing the logic used to translate internal concurrent request state codes into user-facing, NLS-translated phase, status, and conflict explanations, and by exposing administrative operations (cancellation, hold toggling, priority changes, session termination) that the management console invokes. Because it is a _PRIVATE package, it is not part of the supported public API surface; it is called by sibling AMP packages rather than by customer code. The 12.2.2 ETRM metadata records seven documented program units and identifies this package as a dependency source for six other packages.

Key Procedures and Functions

• WHY_WAIT — Returns a translated string describing why one request is waiting on another. If request1 is not waiting on request2, the function returns null. Request2 must be a pending or running program queued ahead of request1, in the same conflict domain, with a queue_method_code of 'B'. The header explicitly notes that no validation of these constraints is performed, because the function is embedded in a data gatherer select statement that must execute quickly.
• GET_PHASE — Returns a translated (NLS-resolved) phase description for a concurrent request, deriving the user-facing phase text from the internal phase code, status code, hold and enabled flags, start date, and request identifier.
• GET_STATUS — Returns a translated status description corresponding to a request's phase and status codes, using the same set of flags and date/request inputs as GET_PHASE so that both functions render consistent, language-specific labels.
• KILL_SESSION — Terminates a database session, typically the session executing an unattached or long-running concurrent request.
• CANCEL_REQUEST — Cancels a submitted concurrent request through the concurrent processing data model.
• TOGGLE_REQUEST_HOLD — Places a concurrent request on hold or releases an existing hold.
• ALTER_REQUEST_PRIORITY — Modifies the execution priority assigned to a pending concurrent request, affecting its position in the conflict-resolution queue.

Both WHY_WAIT, GET_PHASE, and GET_STATUS carry the pragma restrict_references (..., WNDS) declaration, guaranteeing that they write no database state — a requirement for functions referenced inside SQL select statements, which is precisely how WHY_WAIT is used.

Tables Accessed

The package references the following objects through APPS synonyms:

• FND_CONCURRENT_REQUESTS — the central concurrent request repository; supplies phase, status, hold, priority, and timing columns consumed by GET_PHASE, GET_STATUS, WHY_WAIT, CANCEL_REQUEST, TOGGLE_REQUEST_HOLD, and ALTER_REQUEST_PRIORITY.
• FND_CONCURRENT_PROGRAM_SERIAL — the serialization/conflict-domain definition table; underpins the queue-ordering semantics required by WHY_WAIT, which must evaluate whether a conflicting program is queued ahead.
• GV$SESSION — the global session view used to identify and terminate the database session associated with a running request (KILL_SESSION).
• DBMS_SQL — the Oracle dynamic SQL package, used for programmatically constructed statements rather than for fixed application lookups.

Usage Notes

FND_AMP_PRIVATE is invoked indirectly. The Applications Management Pack console, the Concurrent Manager administration forms, and other AMP packages call these utilities to render request status screens and to perform administrator-initiated actions on submitted requests. WHY_WAIT in particular is designed to be projected from a data gatherer query against FND_CONCURRENT_REQUESTS, which is why its contract explicitly disclaims constraint validation in favor of speed. Because the package is private and undocumented in the public API, customizations should not call it directly; implementers requiring equivalent functionality should use the supported Concurrent Processing public APIs (such as FND_REQUEST) or query the underlying FND_CONCURRENT_REQUESTS tables. In both 12.1.1 and 12.2.2 this object remains an internal AMP dependency rather than a supported integration point.