Search Results fnd_cp_opp_req




Overview
Explore in AI Chat

Overview

FND_CP_OPP_REQ is an Oracle E-Business Suite package owned by the APPS schema and classified under the "OTHER" API category. It belongs to the Oracle Publishing Platform (OPP) infrastructure that underpins the concurrent processing framework, specifically the post-processing stage through which completed concurrent requests are routed for output publication, distribution, and delivery. In EBS 12.1.1 and 12.2.2, OPP provides the mechanism by which a finished report or output file is delivered through configured delivery options such as email, fax, printer, or file transfer.

The package is primarily a service-layer component. It does not present a user-facing business function; instead, it answers a fundamental routing question for the OPP engine: is a given concurrent request a "published request" that is subject to post-processing actions, and if so, which request carries the authoritative publishing definitions? This distinction matters because a reprinted or copied request inherits publishing behavior from a parent request rather than carrying its own OPP action rows. By resolving the correct parent, FND_CP_OPP_REQ prevents duplicated post-processing and ensures that delivery definitions are honored exactly once. The package also manages the lifecycle of the FND_CONC_PP_ACTIONS rows by applying an optimistic locking pattern, guaranteeing that parallel post-processor instances do not both claim the same request. The header comment indicates a 2007 revision level (120.2.12000000.3), and the code defines the POST_REQUEST_STATUS status constants PP_PENDING ('P'), PP_COMPLETE ('C'), PP_TIMEOUT ('T'), and PP_ERROR ('E').

Key Procedures and Functions

  • PUBLISHED_REQUEST — Documented in both an earlier function form and a later procedure form added under Bug 6275963. The function form accepts a request identifier and returns a boolean indicating whether that request has publishing actions. The procedure form extends this by returning, through its output parameters, an is_published flag and the identifying request id of the published request (pub_reqid). When the supplied request is a simple reprint of an already published request, the parent request id is returned; otherwise the returned id matches the input request id.
  • UPDATE_ACTIONS_TABLE — Updates the FND_CONC_PP_ACTIONS table for a requesting context, taking the concurrent request id and the process id of the OPP service so that PROCESSOR_ID can be stamped. It returns a success indicator that is 'Y' only if the update was performed, and 'N' if another process had already claimed the row, providing the concurrency guard described above.
  • SELECT_POSTPROCESSOR — Selects the appropriate post-processor to handle the post-processing actions associated with a request.
  • POSTPROCESS — Drives the actual post-processing operation for a request after the post-processor has been determined.
  • ADJUST_OUTFILE — Performs adjustments to the concurrent request output file, presumably to prepare it for the delivery mechanism defined by the publishing actions.

Tables Accessed

The package operates largely against concurrent processing metadata. FND_CONC_PP_ACTIONS is the central table read and written, holding the post-processing actions whose PROCESSOR_ID is stamped by UPDATE_ACTIONS_TABLE. FND_CONCURRENT_REQUESTS, FND_CONCURRENT_PROGRAMS, FND_CONCURRENT_PROCESSES, and FND_CONCURRENT_QUEUES supply the request, program, process, and queue definitions used to identify and route requests. FND_CONC_REQ_OUTPUTS and FND_CP_SERVICES relate to output files and the OPP service configuration, while FND_APPLICATION and DBMS_LOCK support application context and serialization.

Usage Notes

FND_CP_OPP_REQ is invoked by the OPP service and the concurrent manager's post-processing mechanism rather than directly by end users. It is not referenced by any other documented package, so customizations that need to determine whether a request is published, or to resolve the parent request of a reprint, should call PUBLISHED_REQUEST rather than querying FND_CONC_PP_ACTIONS directly. The metadata does not document parameters for every procedure, so callers should obtain signatures from the EBS instance itself before writing custom code against this package.