Search Results okl_parallel_processes




Overview
Explore in AI Chat

Overview

The table OKL.OKL_PARALLEL_PROCESSES is a core infrastructure object within the Oracle E-Business Suite (EBS) Leasing and Finance Management (OKL) module. Its documented purpose is to support the spawning of child concurrent programs for the master billing programs. In high-volume leasing operations, a single master billing run must process a large number of contracts and transactions. Rather than executing serially, the application divides the workload into discrete units of work and distributes them across multiple parallel worker requests. OKL_PARALLEL_PROCESSES acts as the coordination and tracking table for that parallel execution model, recording which business objects have been assigned, their processing status, and the volume of work associated with each assignment.

From a heuristic Data Vault modeling perspective, this table is classified as standalone. The classification is derived from the foreign-key structure, which shows only a single reference (KHR_ID to OKL_PRTFL_CNTRCTS_B) and no inbound dependencies. A practitioner applying Data Vault techniques would therefore treat OKL_PARALLEL_PROCESSES as an independent hub or work-queue table rather than as a link or satellite attached to a larger transactional core.

Key Information Stored

The table contains 18 documented columns in the 12.2.2 physical schema. The most operationally significant are summarized below.

  • KHR_ID — Foreign key to OKL_PRTFL_CNTRCTS_B, identifying the contract or portfolio contract header associated with the parallel work unit. This is the principal business-key candidate for joining to leasing contract data.
  • OBJECT_TYPE / OBJECT_VALUE — Classify the business entity being processed and hold its identifying value, allowing heterogeneous object types to share a single queue.
  • OBJECT_STATUS / PROCESS_STATUS — Track the lifecycle and completion state of each work unit, distinguishing pending, in-progress, and completed records.
  • ASSIGNED_PROCESS — Identifies the child concurrent program or worker assigned to the record.
  • VOLUME — Quantifies the work contained in the unit, supporting load balancing across workers.
  • TRX_ID — References the underlying transaction being billed.
  • START_DATE — Timestamp for the commencement of processing.
  • ORG_ID — Operating unit discriminator, enabling Multi-Org filtered reporting.
  • REQUEST_ID / PROGRAM_ID — Standard concurrent manager identifiers linking the row to the parent request and the responsible program.
  • Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, and PROGRAM_UPDATE_DATE provide full WHO-column traceability.

No explicit surrogate primary key is documented in the metadata; KHR_ID combined with object and transaction identifiers serves as the effective business key.

Common Use Cases and Queries

The primary use case is monitoring and troubleshooting parallel billing runs. Support and operations teams query the table to determine whether child processes completed, stalled, or failed.

  • Billing run progress — Count rows grouped by PROCESS_STATUS and PROGRAM_ID to measure completion rates for a given REQUEST_ID.
  • Failed unit identification — Join KHR_ID to OKL_PRTFL_CNTRCTS_B to list contracts whose parallel units did not complete successfully.
  • Load distribution analysis — Aggregate VOLUME by ASSIGNED_PROCESS to assess worker balancing.
  • Operating unit reporting — Filter by ORG_ID for Multi-Org-aware reporting.

A representative query pattern selects KHR_ID, PROCESS_STATUS, VOLUME, and ASSIGNED_PROCESS from OKL_PARALLEL_PROCESSES where REQUEST_ID matches the concurrent request under investigation. Such queries are typically executed from a DBA or support session rather than through a standard form.

Related Objects

  • OKL_PRTFL_CNTRCTS_B — Referenced by the KHR_ID foreign key; the contract header table supplying the business context for each work unit.
  • FND_CONCURRENT_REQUESTS — Joined via REQUEST_ID to reconcile parallel units with the concurrent manager request record.
  • FND_CONCURRENT_PROGRAMS — Joined via PROGRAM_ID to resolve the master and child program definitions.
  • OKL_TRX_* transaction tables — Related through TRX_ID for the underlying billing transactions.
  • OKL_BILLING master programs — The concurrent programs that populate and consume this table during billing execution.
  • HR_OPERATING_UNITS — Joined via ORG_ID for operating unit descriptions in reporting.

Direct DML against OKL_PARALLEL_PROCESSES is not supported; the table is maintained exclusively by the leasing billing concurrent programs.