Advanced Concurrent Managers

A concurrent manager will run requests based on both its assigned:

• Work shift/s - when the manager can run and the number of manager processes the manager should run and
• Specialization Rules - The programs the custom manager can run.

Note: In general, all requests run through the Standard manager unless you create a custom manager with a work shift and assign a program via a specialization rule and then exclude the program from the standard manager.

Custom Concurrent Managers

A word of warning: - Creating a custom manager is relatively easy to process, getting rid of one is not. In fact you are not meant to delete a custom manager, only disable them, so plan carefully before you go creating custom managers.

Work shifts

A work shift defines when one or more manager/s will run. Out of the box – all Concurrent managers are assigned the “standard” work shift. This work shift runs between 00:00 am and 23:59 seven (7) days a week.

Before you go creating additional work shifts you really want to be very sure of why you require a custom work shift, what will run in that work shift and what will happen to any program assigned to the manager / work shift when the work shift defines the manager as inactive.

One of the most complex custom work shifts is one to only run selected concurrent programs overnight. There are three (3) basic steps to achieving this setup:

• In order for a manager to only run requests overnight (spans midnight) you must create two (2) work shifts and assign both those work shifts to the “Overnight” Manager:

                         Overnight_am to run between 18:00 and 23:59

                         Overnight_pm to run between 00:00 and 07:00

• You then create a custom concurrent manager usually with a descriptive name such as “Overnight_only” and assign it both the overnight_am and overnight_pm work shifts.
• The final step is to assign the programs you want to be run by the “overnight_only” manager using specialisation rules.

Note: When a request is submitted to run in the “Overnight_only” manager before or after the “Overnight_only” manager is running, the request will be marked as Pending Error, as there are no managers to run the request until the managers start.

Specialization rules

Specialization rules are used to assign specific concurrent manager programs to specific queues.

Specialization rules can be one of the more complex Oracle Applications features to set up and once set up, one of the more complex to find using the current E-Business Suite screens. This makes it hard for an administrator taking over a site to understand and troubleshoot. Remember, with specialization rules simplicity is the key.

To add to the complexity, there are a number of specialization rule combinations:

• By Program
• By Application user
• By Oracle User
• By Request Type
• By Complex Rule, which is a combination of Program, application user and / or Oracle user

In the case of a program rule, it’s a simple process of “including” a program to run in the custom manager and “excluding” the program from the standard manager.

Specialization Rules to concurrent manager (Custom/Standard) is set via the applications  

Concurrent > Manager > Define

Request types

Request types are one of the most powerful features of concurrent processing; they allow you to assign new requests of a program from one concurrent manager to another without the need to bounce the concurrent managers.

Note: Once a program has been submitted the queue cannot be changed.

A request type is a logical folder if you will, which is assigned to a specific queue by specialization rules the same way as a program is assigned e.g. The request type “Slow” is “included” to the concurrent manager “Slow” queue and “excluded” from the standard manager.

The request type for a concurrent program is set via the applications Concurrent > Program > Define screen

Incompatibility Rules

Programs may also not run when you expect based on one or more incompatibility rules.

An incompatibility rule defines that a selected program cannot run whilst a program that has been defined as incompatible is running.

An example of this is the GL Posting program “GLPPOS”, this program has been defined as incompatible with itself, as such a second or subsequent posting program being submitted must wait until the initial posting program has completed.

Much like specialization rules, incompatibility rules are easy to create but not so easy to keep track of.

Incompatibility rules are managed vie the application Concurrent > Programs > Define Screen. Select the incompatibilities button.

Role of the Conflict Resolution Manager (FNDCRM)

The conflict resolution manager assesses each requested concurrent program against programs that are running, referencing the applications incompatibility rules.

When a program lists other programs as being incompatible with it, the Conflict Resolution Manager prevents the program from starting until any incompatible programs in the same domain have completed running.

Run Alone Programs

You can make a program incompatible with all other concurrent programs by defining the program to be run-alone via the run alone option in the concurrent program define screen. Care should be exercised here as once this program is running no other programs can run at the same time.

How many concurrent managers should I have?

It is a common misconception that the more managers you have the better throughput you will get. This situation is further compounded once the business find out you can add managers. They too generally believe there are spare resources you are not utilising, and therefore that you should add more managers.

When configuring managers it is best to start low, and work up.

A general rule of thumb is you should have no more managers than 2 (standard and custom) times the number of CPUs (optimal is 1.8 as this leaves head room for user connections).

Always resist the urge to add managers

·         Generally no more than 2 managers per CPU

·         Custom managers for FSGs ( Assume 1 FSG will consume one CPU )

·         Custom managers for selected slow jobs

·         Custom managers for selected fast jobs

Note: When you creating custom managers do not forget to reduce the number of standard managers.

Sleep and cache settings in Concurrent Managers:

When a queue wakes up (sleep time) it queries the FND_CONCURRENT_REQUESTS table for any pending requests. The value of the cache size will determine the number of rows that will be returned. If a request completes within the managers sleep time, additional requests held in cache can be run prior to the next manager wake up time.