Search Results call_api

Overview

CLN_NP_CONC_API_CALL is a server-side PL/SQL package owned by the APPS schema that provides the infrastructure to execute a user-defined PL/SQL function in concurrent mode within Oracle E-Business Suite. In the context of the ETRM (Enterprise Transaction and Relationship Management) product family, the package serves as the bridge between the Oracle Workflow engine and the Oracle concurrent manager. Its stated purpose is to run a user-defined PL/SQL function asynchronously, so that long-running or resource-intensive business logic does not block the Workflow background process or the interactive user session that triggered the workflow.

The package originated in the CLN (Customer Relationship Management / interaction) module lineage, as reflected in the source header ECXNPCRS.pls dated August 25, 2005, and the creation history attributed to Kodanda Ram in May 2002. The naming convention signals its role: "CLN" denotes the application family, "NP" refers to the Notification Processor framework, and "CONC_API_CALL" describes its responsibility to invoke an API through the concurrent manager.

Key Procedures and Functions

The package exposes a single documented procedure, CALL_API. Its purpose is to submit a concurrent request that executes a user-defined PL/SQL function on behalf of the Workflow runtime. Documentation identifies the functional arguments it receives: the item type, the item key, the action ID, the function mode, and a result output parameter. The procedure is declared with the standard Workflow callback signature, accepting the item type, item key, action ID, and function mode as inbound values and returning a result through an IN OUT NOCOPY parameter.

The procedure does not execute the target function synchronously. Instead, it packages the request so that the Oracle Concurrent Manager picks it up and runs the designated PL/SQL logic in a separate concurrent request. This decoupling is deliberate: Workflow activities may be triggered from numerous sources, and offloading the actual function execution to the concurrent manager provides isolation, restartability, and the standard concurrent request monitoring and logging facilities. No additional documented procedures or functions exist in this package beyond CALL_API.

Tables Accessed

According to the documented metadata, the package references one table through an APPS synonym: WF_PARAMETER_LIST_T. This is an Oracle Workflow runtime table that stores the parameter list associated with a workflow activity or function invocation. The package reads this table to retrieve the attributes and parameters required to construct the concurrent request for the user-defined function. The parameter list defines the inputs the target API expects, and it is the mechanism by which Workflow passes context from the item type and item key into the concurrent program submission.

No other tables are documented as accessed by this package. Notably, the package relies on the concurrent manager's own internal tables for request submission and status tracking, but those interactions occur through the standard concurrent request submission APIs rather than direct table access within this package.

Usage Notes

CLN_NP_CONC_API_CALL is invoked indirectly and is not intended to be called directly by end users or developers. The documented execution chain is: a workflow is started, the workflow calls CLN_NP_PROCESSOR_PKG.TAKE_ACTIONS, and that processor in turn invokes CALL_API within this package. This places the package squarely within the Notification Processor / action-handling framework of the ETRM application.

Because the package is documented as referenced by zero other packages in the ETRM metadata, its caller relationship with CLN_NP_PROCESSOR_PKG is the primary integration point. Administrators troubleshooting workflow actions that submit concurrent requests should examine the Oracle Concurrent Manager request queue for requests generated by this call path. The package is compatible with both Oracle EBS 12.1.1 and 12.2.2, though the online patching architecture of 12.2.2 means the APPS synonym resolution and editioning behavior apply as with any other APPS-owned code object. Customizations should avoid modifying this package directly; instead, the user-defined PL/SQL function itself is the correct extension point.