Search Results grab_next_batch_range




Overview
Explore in AI Chat

Overview

BEN_MAINTAIN_BENEFIT_ACTIONS is an APPS-owned PL/SQL package in Oracle EBS Release 12.1.1 and 12.2.2 that orchestrates the execution of a Benefit Action. A Benefit Action is the administrative container that drives a benefits processing run across a population of participants — for example, a Life Event batch, an Open Enrollment window, or an eligibility re-evaluation. Rather than processing every participant serially in a single database session, the package decomposes the population into work ranges and dispatches them to parallel concurrent workers ("slaves"), each of which processes a subset of person actions.

The package therefore behaves as the coordination layer of the Benefits Action framework. It owns the batch partitioning logic, the lifecycle handshake between the master process and its parallel slaves, and the range-allocation mechanism by which each slave claims the next available chunk of work. Package-level state is held in a PL/SQL associative array indexed by binary integer (g_processes_table) together with a counter (g_num_processes), which collectively track the set of in-flight slave processes for a given run. The source header (benbmbft.pkh, version 120.0) confirms the package has been shipped as-is since the 11i-to-R12 transition and is not a customer-modifiable object.

Key Procedures and Functions

  • START_SLAVES — The entry point that launches the parallel processing run. It accepts the Benefit Action identifier along with the full set of processing parameters that define the population: program, plan, plan type, option, eligibility profile, variable rate profile, person and compensation selection rules, reporting group, business group, effective date, mode, and derivable factors. Life event context is supplied through the life event occurred date and the life event operation code. Two GSP rate-sync parameters — the evaluate-eligibility flag and the life event operation code — are optional and default to null. The procedure spawns the requested number of slave threads across the requested number of ranges.
  • GRAB_NEXT_BATCH_RANGE — Implements the work-claiming protocol. Given a Benefit Action identifier, it returns the start and end person action identifiers of the next unpicked batch range, together with a boolean indicating whether any rows were found. This allows multiple concurrent slaves to drain the range table without contention.
  • CHECK_SLAVES_STATUS — Evaluates the health of the running slave set. It takes the process count and process array, a master indicator, and returns a boolean flag indicating whether any slave has errored, allowing the master to detect failure and abort or report.
  • CHECK_ALL_SLAVES_FINISHED — The completion test used by the parent process. Given the Benefit Action identifier and business group, it determines whether all slave concurrent requests have terminated and returns a boolean indicating that an error occurred during the run. This is the procedure most commonly referenced in diagnostics, because a stalled or never-terminated slave set causes the parent to wait indefinitely.
  • GET_PERACTIONRANGE_PERSONDETS — Retrieves the person-level detail for a bounded range of person actions, using the start and end person action identifiers produced by GRAB_NEXT_BATCH_RANGE. This supplies each slave with the participant records it must process.

Tables Accessed

  • BEN_BATCH_RANGES — Stores the partitioned work ranges; read by GRAB_NEXT_BATCH_RANGE and written as ranges are claimed.
  • BEN_BENEFIT_ACTIONS — The parent run definition, supplying action-level context and status.
  • BEN_PERSON_ACTIONS — The individual participant action rows that constitute the real work of the run.
  • FND_CONCURRENT_REQUESTS — Queried to determine slave request completion and phase, which underpins CHECK_ALL_SLAVES_FINISHED and CHECK_SLAVES_STATUS.
  • DBMS_LOCK — Used to serialize access around range allocation so concurrent slaves do not claim the same batch.

Usage Notes

The package is invoked internally by the Benefits Action concurrent program rather than by end users directly. It is referenced by two other packages, indicating it is part of a layered framework in which a driver package submits the master concurrent request and this package manages the master/slave fan-out. Oracle Forms such as the Benefit Actions and Life Events windows ultimately trigger runs that route through START_SLAVES.

From a troubleshooting perspective, CHECK_ALL_SLAVES_FINISHED is the key object. When a Benefit Action appears to hang, the failure is typically that one or more slave concurrent requests have not reached a terminal phase, preventing the completion test from returning true. The recommended diagnostic path is to inspect FND_CONCURRENT_REQUESTS for the parent Benefit Action request, identify the child slave requests, and review their log and output files for errors. The slave_errored out parameter provides the programmatic signal that a slave failed rather than simply completing without finding data. Because the package relies on package-level global state, it is not safe for concurrent execution within a single session, and custom code should not invoke these procedures outside the supported Benefits Action flow.