Search Results fnd_conc_pp_actions

Overview

The FND_CONC_PP_ACTIONS table is a core Application Object Library table within the Oracle E-Business Suite (EBS) database, owned by the APPLSYS schema. Its primary role is to serve as a log or staging area for post-processing actions that must be executed after a concurrent request completes. The "PP" in its name stands for "Post-Processing." This table is integral to the concurrent manager architecture, enabling deferred or conditional logic that depends on the outcome of a submitted job. When a concurrent request finishes, the system can insert records here to trigger subsequent actions, such as spawning child requests, sending notifications, or updating related application data, thereby orchestrating multi-step business processes.

Key Information Stored

The table's structure centers on linking actions to specific concurrent requests and tracking their creation and modification. Based on the provided metadata, the primary and foreign keys reveal its critical columns. The CONCURRENT_REQUEST_ID column is the table's primary key, directly linking each post-processing action to a single record in the FND_CONCURRENT_REQUESTS table. This one-to-one relationship suggests that the table is designed to hold a definitive post-processing instruction set for a request. Other key columns include CREATED_BY and LAST_UPDATED_BY, which are foreign keys to FND_USER, recording the user IDs responsible for the action record. The LAST_UPDATE_LOGIN column is a foreign key to FND_LOGINS, providing audit trail information about the session. While the specific action details (stored in columns not listed in the brief metadata, such as action type or arguments) are not defined here, the key structure confirms its function as an audit-capable control table for request lifecycle management.

Common Use Cases and Queries

This table is primarily used by the Concurrent Manager infrastructure itself and by custom programs designed to participate in complex, chained workflows. A common operational use case is diagnosing why a subsequent expected action did not occur after a request completed; a developer or administrator might query this table to see if a post-processing record was created. A typical diagnostic query would join to the main requests table:

• SELECT fcp.*, fcr.request_id, fcr.program_short_name FROM apps.fnd_conc_pp_actions fcp, apps.fnd_concurrent_requests fcr WHERE fcp.concurrent_request_id = fcr.request_id AND fcr.request_id = :req_id;

Another use case involves cleanup or monitoring scripts that might purge old action records. Since it has a direct foreign key to the requests table, it is often included in joins for comprehensive request lifecycle reporting, providing insight into the phases a request goes through after its main execution ends.

Related Objects

As defined by its foreign key constraints, FND_CONC_PP_ACTIONS has direct, dependent relationships with several fundamental EBS tables. Its most significant relationship is with FND_CONCURRENT_REQUESTS, the master table for all submitted jobs. This is the central link for its operational purpose. For auditing, it relates to FND_USER (twice, for creator and last updater) and FND_LOGINS. While not listed in the metadata, it is logically closely tied to the concurrent manager processes that read from it and to any application code that utilizes the post-processing API (such as FND_CONCURRENT package procedures) to populate it. It is a child table to FND_CONCURRENT_REQUESTS, meaning its records are typically purged or archived in line with the concurrent request history.