This section explains how a request to run a concurrent program is handled by Oracle E-Business Suite, and what the life cycle of a concurrent request is.

In Oracle E-Business Suite, concurrent processing simultaneously executes programs running in the background with online operations. As System Administrator, you can manage when programs are run and how many operating system processes Oracle E-Business Suite devotes to running programs in the background.

When a user runs a report, a request to run the report is generated. The command to run the report is a concurrent request. The program that generates the report is a concurrent program. Concurrent programs are started by a concurrent manager.

Concurrent Managers start concurrent programs

Every time your users request a concurrent program to be run, their request is inserted into a database table, and is uniquely identified by a request ID. Concurrent managers read requests from this table.

Part of a manager's definition is how many operating system processes it can devote to running requests. This number is referred to as the manager's number of target processes, or number of workers.

Running concurrent programs

A concurrent program actually starts running based on:

• When it is scheduled to start

• Whether it is placed on hold

• Whether it is incompatible (cannot run) with other programs

• Its request priority

Concurrent Request Priorities

The priority of a concurrent request is determined by application username, and is set by the System Administrator using the Concurrent:Priority user profile option.

The first available concurrent manager compares the request's priority to other requests it is eligible to process, and runs the request with the highest priority.

When choosing between requests of equal priority, the concurrent manager runs the oldest request first.

Parent requests and Child requests

Often, several programs may be grouped together, as in a request set. Submitting the request set as a whole generates a request ID, and as each member of the set is submitted it receives its own request ID. The set's request ID identifies the Parent request, and each of the individual programs' request ID identifies a Child request.

Recalculation of Dynamic Default Parameters in Standard Request Submission

Parameters used in Standard Request Submission (SRS) can have default values that are generated dynamically, such as by SQL statements, from profile option values, or using the current date or time. Prior to Release 12.2.4, in the case of resubmitting or copying a request, the original parameter values are always reused. In Release 12.2.4 and later, a flag "Recalculate Parameters" can be set to determine if the parameter values should be recalculated upon re-submission or copying a request.

Each concurrent program now has a "Recalculate Default Parameters" flag attached to it. This flag is available as a field in the Define Concurrent Programs form and in the Define Concurrent Program HTML-based page. The default value for this field is unchecked; that is, not to recalculate parameter values.

Each request also has a "Recalculate Default Parameters" flag. At request submission, the program's flag will be checked, and if it is set, the flag will be set for the request. If the request is scheduled to be run more than once, the flag will be set to 'Y' at re-submission. If checked, all parameters that have dynamic default values will be recalculated for the next submission.

The Standard Request Submission form has a Recalculate Parameters check box in the Schedule window, and the HTML-based Schedule Request Submission page has a Recalculate Default Parameters check box. The check box only appears for Periodic and On Specific Days schedules. The check box reflects the value of the concurrent program's flag; that is, if the flag is set to No then the check box will be unchecked. In this way the user can override the program's default action if he or she wishes.

This flag takes precedence over the Increment Dates flag. If both are checked, the dynamic default value will be recalculated, if the parameter has one. If the parameter does not have a dynamic default, the date can be incremented.

If the program has a custom increment procedure, none of these procedures will apply. Both check boxes would be grayed out and the user should not be able to select the check boxes for Recalculate Default Parameters or Increment Dates. The custom increment procedure will be the only one to modify the parameters on re-submission.

When a user selects the Copy button in the SRS window to find a previous request to copy, a new window is shown. In this window the user can search for previous requests. The program name, parameters, request date and request ID are shown for a given request. The LOV shows all the programs the user is able to submit. Once the user selects a program, the window will show all requests run for that program. The Find Previous Requests window has a Recalculate Parameters check box that reflects the state of the program's flag; that is, if the flag is set to No, the check box will be unchecked. However, the user can then override the program's default action as desired. All hidden parameters will be recalculated regardless of the program's flag or the check box value.

A concurrent request proceeds through three, possibly four, life cycle stages or phases:

Within each phase, a request's condition or status may change. The following table shows a listing of each phase and the various states that a concurrent request can go through.