Search Results day_per_sec

Overview

FND_TRANSACTION is a low-level Oracle E-Business Suite utility package owned by the APPS schema that provides synchronous transaction submission and inter-process coordination services within the concurrent processing framework. It is classified as an OTHER API in the ETRM documentation and is not intended as a public business API. Rather, it functions as an internal infrastructure component used by concurrent managers, transaction processors, and other EBS packages that need to synchronously invoke a concurrent program request, wait for its completion, and retrieve return values from the invoked program. In the context of a search for "project transaction transfer," this package appears because project-oriented transaction programs (for example, processes that move expenditure, cost, or interface transactions between staging and interface tables) frequently rely on FND_TRANSACTION to coordinate their execution. The package carries the internal header AFCPTRNS.pls, and its version stamp dates to 2005, indicating it is a long-standing, stable element of the FND foundation product family that predates the 12.1.1 and 12.2.2 releases and is carried forward unchanged.

Key Procedures and Functions

• SYNCHRONOUS — The core routine of the package. It submits a synchronous transaction request, naming a target transaction program by application short name and program short name, and waits up to a caller-supplied timeout in seconds for completion. It accepts up to twenty program arguments, each limited to 480 characters, with a total combined argument size capped at 3K. Its defined result codes distinguish success, timeout, no manager available, argument size overflow, and other failures.
• GET_VALUES — Retrieves return values produced by a previously executed synchronous transaction. The package exposes return values through a VARCHAR_TABLE collection, and this routine provides the accessor for those values.
• DEBUG_INFO — Supports diagnostic interrogation of concurrent debug information, relating to the debug-mode request types defined in the package constants.
• POST_TM_EVENT — Posts an event to the transaction manager event store, supporting the event-driven signaling used to coordinate transaction processing among concurrent processes.

The package additionally exposes constants such as DAY_PER_SEC, SEC_PER_DAY, DEFAULT_TIMEOUT, ARGMAX, ARGSTOTAL, and the E_SUCCESS / E_TIMEOUT / E_NOMGR / E_OTHER / E_ARGSIZE result codes, together with the TYPE_REQUEST and debug request type constants and the debug_flag, conc_queue_id, and return_values package variables.

Tables Accessed

The package reads metadata and configuration from FND_APPLICATION, FND_CONCURRENT_PROGRAMS, FND_CONCURRENT_QUEUES, FND_RESPONSIBILITY, and FND_CONC_PROCESSOR_PROGRAMS to resolve the target transaction program and locate an eligible concurrent manager. It writes debug output to FND_CONCURRENT_DEBUG_INFO, records transaction manager events in FND_TM_EVENTS, and obtains identifiers from FND_TRN_REQUEST_ID_S. It also draws on DBMS_RANDOM, DBMS_UTILITY, DUAL, and V$NLS_PARAMETERS for supporting services such as random value generation, argument size checks, and NLS-aware processing.

Usage Notes

FND_TRANSACTION is typically invoked from other PL/SQL packages rather than directly from forms. The ETRM metadata records that it is referenced by 22 other packages, confirming its role as a shared dependency in the FND and adjacent product schemas. The AUTHID CURRENT_USER declaration means the package executes with the privileges of the calling user, so callers must have appropriate grants on the underlying FND tables and views. Custom code requiring synchronous execution of a concurrent program with retrieval of results may call SYNCHRONOUS, but the 480-character per-argument and 3K total argument limits must be respected; exceeding the total returns E_ARGSIZE. Because this is an internal, undocumented interface with no public API designation, Oracle does not guarantee backward compatibility, and developers using it for project transaction transfer scenarios should isolate the call behind their own wrapper and validate behavior against both 12.1.1 and 12.2.2 instances.