Search Results wait_for_request

Overview

The APPS.DPP_BPEL_POLLCREATENOTIF package body is a component of Oracle E-Business Suite's Distributed Planning Process (DPP) module, which supports demand planning, supply chain collaboration, and order promising flows within the Advanced Supply Chain Planning (ASCP) and related planning families. The package is part of the DPP BPEL integration layer, used to coordinate notifications and status polling for BPEL-driven concurrent request execution. It exists to bridge Oracle Workflow Business Event (BPEL) process invocations with the standard Oracle EBS concurrent manager, allowing external BPEL orchestrations to submit a concurrent program and then monitor its completion synchronously.

The naming convention DPP_BPEL_ indicates that this code belongs to the BPEL adapter utilities used by DPP business flows. The package is header-versioned at 120.0 with a last modification date of 2008/03/25, indicating it has been stable across both the 12.1.1 and 12.2.2 releases and has not required structural changes since the original 12.0 cycle.

Key Procedures and Functions

The ETRM metadata documents exactly one callable program unit within this package body:

• WAIT_FOR_REQUEST — A wrapper function that polls a submitted concurrent request until it reaches a terminal state, and then translates the resulting request status into a human-readable notification message. The function accepts a request identifier, a polling interval, and a maximum wait threshold, and returns a numeric status code. Through its output parameters, it exposes the request's phase, status, development phase, development status, a success message, and a formatted error message. Internally, the function delegates the actual polling to FND_CONCURRENT.WAIT_FOR_REQUEST, converting the boolean return of that standard FND API into an integer via SYS.SQLJUTL.BOOL2INT.

The function's primary value-add is its error-handling logic. After the underlying FND call returns, the function inspects the development status and produces a localized, token-substituted error message using the FND_MESSAGE API. Six distinct error conditions are recognized and mapped to named DPP messages: no information returned (DPP_BPEL_CONC_PGM_NOINFO), deleted (DPP_BPEL_CONC_PGM_DELETED), terminated (DPP_BPEL_CONC_PGM_TERMINATED), error (DPP_BPEL_CONC_PGM_ERROR), no manager (DPP_BPEL_CONC_PGM_NO_MANAGER), and disabled (DPP_BPEL_CONC_PGM_DISABLED). Each message passes the request ID as TOKEN_01, enabling operations staff to trace the failing request directly.

Tables Accessed

The documented metadata records no direct table references from this package via APPS synonyms. This is consistent with its design as a thin orchestration wrapper: all persistent data access is performed indirectly through APPS.FND_CONCURRENT.WAIT_FOR_REQUEST, which reads the standard concurrent manager interface tables (FND_CONCURRENT_REQUESTS, FND_CONCURRENT_PROGRAMS, and related run-time views) on behalf of the caller. Similarly, FND_MESSAGE resolves message text from the FND_MESSAGES and FND_MESSAGE_TOKENS metadata tables. Because this package issues no DML of its own, it holds no locking or transactional responsibility and is safe to call repeatedly in a polling loop.

Usage Notes

Although the metadata records zero inbound references from other documented packages, WAIT_FOR_REQUEST is designed to be invoked from BPEL process definitions or from custom PL/SQL that submits a DPP concurrent program and then requires synchronous confirmation of its outcome before proceeding. It is not exposed through a standard Oracle Forms user interface, as it is an internal integration utility.

Typical invocation follows a two-step pattern: the caller submits the request via FND_REQUEST.SUBMIT_REQUEST, obtains the request ID, and then calls DPP_BPEL_POLLCREATENOTIF.WAIT_FOR_REQUEST passing a suitable interval and maximum wait. A return value of 0 combined with a non-null x_error_message signals failure, and the caller should raise the error into the BPEL fault path rather than retry blindly. When the development status is one of the terminal failure states, no further polling is useful. Callers should choose p_max_wait conservatively, since the function blocks until the request completes or the threshold expires.