Search Results concurrent_time_period_id




Overview
Explore in AI Chat

Overview

The FND_CONCURRENT_TIME_PERIODS table is a core data object within the Application Object Library (FND) module of Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2. It serves as the master repository for defining concurrent processing work shifts. These time periods are fundamental to the operational scheduling and resource management of the Concurrent Manager architecture. Administrators define shifts (e.g., "Day Shift," "Night Shift," "Weekend") within this table to control when specific managers are active, which types of concurrent programs they can run, and how many processes they can utilize. This enables fine-grained control over batch processing workloads, aligning them with business hours, system maintenance windows, and available system resources.

Key Information Stored

The table stores the configuration for each defined work shift. Its primary structure, as indicated by the primary and unique keys, centers on an APPLICATION_ID and a CONCURRENT_TIME_PERIOD_ID or CONCURRENT_TIME_PERIOD_NAME. The APPLICATION_ID links the shift definition to a specific application, typically seeded as 0 (FND) for system-level shifts. The CONCURRENT_TIME_PERIOD_ID is the unique numeric identifier, while CONCURRENT_TIME_PERIOD_NAME is the unique descriptive name for the shift. While the provided metadata does not list all columns, typical data stored includes the start time, end time, and days of the week for which the shift is active. This configuration directly dictates the availability windows for concurrent queues.

Common Use Cases and Queries

The primary use case is the administration and reporting of concurrent manager schedules. System administrators query this table to audit defined shifts, often joining it with manager definition tables. A common reporting need is to list all configured time periods. A basic query would be:

  • SELECT concurrent_time_period_id, concurrent_time_period_name FROM apps.fnd_concurrent_time_periods WHERE application_id = 0 ORDER BY 1;

Another critical scenario involves troubleshooting. When a concurrent request is pending or a manager appears inactive, administrators verify the active time period for the relevant queue. This requires joining FND_CONCURRENT_TIME_PERIODS with FND_CONCURRENT_QUEUES and FND_CONCURRENT_QUEUE_SIZE. Analysts may also run historical analyses to correlate system load with defined work shifts by joining with request history tables.

Related Objects

FND_CONCURRENT_TIME_PERIODS has documented relationships with several key concurrent processing tables, forming the backbone of the scheduling model.

  • FND_APPLICATION: A foreign key relationship exists where FND_CONCURRENT_TIME_PERIODS.APPLICATION_ID references FND_APPLICATION.APPLICATION_ID. This ties the work shift to its owning application.
  • FND_CONCURRENT_QUEUE_SIZE: This is a critical child table. The foreign key is defined on FND_CONCURRENT_QUEUE_SIZE.PERIOD_APPLICATION_ID and FND_CONCURRENT_QUEUE_SIZE.CONCURRENT_TIME_PERIOD_ID, referencing the primary key in FND_CONCURRENT_TIME_PERIODS. This table stores the specific number of processes (target and actual) a concurrent manager can run for each defined work shift.
  • FND_CONCURRENT_QUEUES: While not explicitly listed in the provided foreign keys, this table is intrinsically related. Queue definitions reference time periods to determine their schedule, and operational joins typically involve FND_CONCURRENT_QUEUES, FND_CONCURRENT_QUEUE_SIZE, and FND_CONCURRENT_TIME_PERIODS.