Search Results fetch_next_task




Overview
Explore in AI Chat

Overview

APPS.FND_OAM_DSCRAM_TASKS_PKG is an Oracle E-Business Suite internal PL/SQL package that supports the Applications DBA (AD) patching and file system synchronization infrastructure. The name derives from the "DSCRAM" family of objects, which underpin Oracle Applications Manager (OAM) task execution and the parallel processing of patch-related tasks across application tier nodes. The package is declared with AUTHID CURRENT_USER, meaning that it executes in the schema and privilege context of the calling user rather than as its owning schema, which is consistent with the way many OAM and AD utility packages are designed for invocation from concurrent programs and administrative sessions.

Functionally, the package manages task state within a session. A session is first initialized against a task, bundle, and run context, after which the package exposes accessors and validation logic that other OAM packages — most notably the accompanying *_UNITS_PKG procedures — use to drive task consumption. The package is documented in ETRM as classified OTHER and is referenced by four other packages, confirming its role as a low-level building block rather than an end-user API.

Key Procedures and Functions

The documented public interface contains four procedures and functions:

  • GET_TASK_ID — An accessor function that returns the numerical ID of the task assigned to the current session. Its documented invariant states that the state must already have been initialized by a prior call to EXECUTE_TASK within the same session; if no such initialization occurred, the function raises NO_DATA_FOUND. This makes it a reliable way for downstream code to discover which task it is currently processing.
  • FETCH_NEXT_TASK — Retrieves the next available task for the bundle identifier held in bundle state. The caller passes a p_requery flag indicating whether the underlying SELECT should be re-executed or whether the API should simply advance to the next row of the previous query result. The procedure returns the task identifier, an FND_API-compliant return status, and a descriptive return message. When the queue is exhausted, the return status is G_RET_STS_EMPTY, which callers use as the signal that the bundle has been fully processed. The bundle must be initialized beforehand, otherwise an error status is returned.
  • VALIDATE_CONTINUED_EXECUTION — A static API consumed by the companion units package. Its documented invariants require that an internal assign step has already populated the session state. It accepts flags controlling whether entity queries are forced (typically after an error has been observed) and whether parent entities such as the task, bundle, and run should be recursed into during validation. It returns the standard FND_API status and message pair.
  • EXECUTE_TASK — The initialization entry point. Although the excerpt does not reproduce its full specification, the invariants of GET_TASK_ID establish that EXECUTE_TASK is the call that establishes the session's task state before any accessor or validation routine is used.

Tables Accessed

The package operates against two documented tables through APPS synonyms:

  • FND_OAM_DSCRAM_TASKS — Stores the individual task records, including the TASK_ID returned by FETCH_NEXT_TASK. The package queries this table to select the next task for a given bundle and to validate task-level state.
  • FND_OAM_DSCRAM_UNITS — Stores the subordinate units of work. The package participates in validating unit and parent entity relationships, which is why the companion _UNITS_PKG is documented as a consumer of this package's validation routine.

Usage Notes

This package is not intended for direct use by end users or by general customizations. It is invoked as part of the OAM and AD patching framework, typically from concurrent programs and from administrative processing that coordinates parallel task bundles across middle-tier nodes. Custom code that requires this functionality should call the higher-level OAM APIs rather than these internals, since the state invariants — mandatory prior EXECUTE_TASK initialization and prior internal assign operations — are enforced implicitly and violation results in exceptions or non-success return statuses. The p_requery and forced-query flags exist to support efficient bulk consumption of task queues while still allowing revalidation after errors, a pattern characteristic of long-running patch execution.