Search Results submit_cp

Overview

FND_WF_STANDARD is a standard Oracle Workflow PL/SQL package owned by APPS and classified as OTHER within the ETRM repository. Its core business function is to bridge Oracle Workflow process definitions with the Oracle Concurrent Manager by providing the executable PL/SQL logic behind the standard "Concurrent Program" workflow activity types. When a workflow process must run a concurrent program — for example, as part of a business event, an approval flow, or a scheduled process chain — the activity node in the process definition references the procedures in FND_WF_STANDARD. These procedures submit the request, monitor its execution status, and seed a callback mechanism so that the Workflow Engine can resume the process once the concurrent request completes.

The package header carries the version comment $Header: AFWFSTDS.pls 120.1.12020000.1 2012/06/30, placeholders in the file name reference AFWFSTDS, and the header declares AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user rather than definer's rights. Only the publicly declared interface is documented; no private package body constructs are exposed.

Key Procedures and Functions

The package exposes six documented program units. The three workflow-standard entry points share the industry-standard Oracle Workflow activity signature — itemtype, itemkey, actid, funcmode, and resultout — and are intended to be wired directly into workflow activity function references of type PL/SQL or "Function" (not "PL/SQL Stored Procedure" in the traditional sense, though either can be used).

• SUBMITCONCPROGRAM — Submits the concurrent program associated with the current workflow activity. This is the primary entry point invoked when a workflow node is configured to launch a concurrent request as part of the process.
• EXECUTECONCPROGRAM — Handles execution-phase logic for the concurrent program activity, typically invoked when the Workflow Engine takes the activity into its runnable state.
• WAITFORCONCPROGRAM — Implements the wait/blocking semantics of the activity, checking whether the submitted concurrent request has completed before allowing the workflow to progress.
• SUBMIT_CP — A helper procedure that carries out the actual request submission logic. The req_id parameter is declared as an IN OUT NOCOPY NUMBER, indicating it receives and returns the concurrent request identifier assigned by the Concurrent Manager.
• SEED_CB — A function that returns a NUMBER and seeds the callback record used to resume the workflow when the concurrent request finishes. It receives the standard workflow activity context plus the req_id.
• CALLBACK — The completion handler invoked by the Concurrent Manager (via the standard callback mechanism) when the concurrent request terminates. It emits errbuff, retcode, and step back to the caller.

Tables Accessed

Only one base table is documented as accessed through APPS synonyms: FND_CONCURRENT_REQUESTS. This table is the central repository of concurrent request state (phase, status, and request identifiers). FND_WF_STANDARD reads and writes this table to obtain the request ID returned by SUBMIT_CP and to determine completion status during the WAITFORCONCPROGRAM phase. No other FND_CONCURRENT_* tables appear in the documented metadata.

Usage Notes

FND_WF_STANDARD is normally not called directly. It is invoked by the Oracle Workflow Engine when a workflow process definition includes a standard concurrent program activity, or it may be referenced indirectly by other workflow-integration packages. The metadata records that this package is referenced by 5 other packages, confirming that generic workflow components and custom extensions depend on it. Typical usage contexts include Oracle Applications workflow processes (for example, order or requisition flows) that must trigger a report or interface program, and custom workflow developments that reuse the standard "run concurrent program" pattern. Custom PL/SQL code should reference the documented procedures only through the package specification; direct manipulation of FND_CONCURRENT_REQUESTS should be avoided in favor of these APIs.