Defining Managers and their Work Shifts In Oracle Apps

Defining Managers and their Work Shifts

This essay explains how you can define concurrent managers and specify when a manager is enabled.
A concurrent manager is itself a concurrent program that starts other concurrent programs running. When an application user submits a request to run a program, the request is entered into a database table that lists all of the requests. Concurrent managers read requests from the table and start programs running. See: Concurrent Managers.
In this essay, we explain how to specify when a manager is enabled, how to use managers to balance your applications processing workload across different time periods, and how to associate a library of immediate concurrent programs to be called by your manager.

Defining new managers

You can define as many concurrent managers as you want. When you define a manager, you:

• Assign a predefined library of immediate concurrent programs to your manager.

Immediate concurrent programs are subroutines associated with concurrent managers. All other concurrent programs are spawned as independent processes at run time.

• Assign work shifts to your manager, which determines what days and times the manager works.

• For each work shift, you define the maximum number of operating system processes the manager can run concurrently to read requests (start programs) during the work shift.

• Specialize your manager to read only certain kinds of requests.

Figure 1 - 12 illustrates the details of defining a concurrent manager.
Figure 1 - 12.

Program Libraries

For a program that is spawned, a concurrent manager initiates or spawns another operating system process. A program that is immediate runs as part of the concurrent manager's operating system process.
A program library contains immediate concurrent programs that can be called by your manager.
An immediate concurrent program must be registered with a program library. Application developers using Oracle Application Object Library can register concurrent programs with a program library.
The Oracle Application Object Library FNDLIBR program library contains Oracle Applications immediate concurrent programs, and is assigned to the Standard concurrent manager. In most cases, you will include the FNDLIBR library with your manager's definition.

The Internal and the Standard concurrent managers

Oracle System Administration predefines two managers for you:

• The Internal Concurrent Manager, which functions as the "boss" of all the other managers. The Internal Concurrent Manager starts up, verifies the status of, resets, and shuts down the individual managers.

The Internal Concurrent Manager also enforces program incompatibility rules by comparing program definitions for requested programs with those programs already running in an Oracle username designated as a logical database (i.e., an Oracle account where program incompatibility rules are enforced).

You cannot alter the definition of the Internal Concurrent Manager.

See: Defining Program Incompatibility Rules

• A manager named Standard. The Standard manager accepts any and all requests; it has no specialization. The Standard manager is active all the time; it works 365 days a year, 24 hours a day.

Warning: You should not alter the definition of the Standard concurrent manager. If you do, and you have not defined additional managers to accept your requests, some programs may not run. Use the Standard manager as a safety net, a manager who is always available to run any request. Define additional managers to handle your installation site's specific needs.

Transaction Managers

While conventional concurrent managers let you execute long-running, data-intensive application programs asynchronously, transaction managers support synchronous processing of particular requests from client machines. A request from a client program to run a server-side program synchronously causes a transaction manager to run it immediately, and then to return a status to the client program.
Transaction managers are implemented as immediate concurrent programs. At runtime, concurrent processing starts a number of these managers. Rather than polling the concurrent requests table to determine what to do, a transaction manager waits to be signalled by a client program. The execution of the requested transaction program takes place on the server, transparent to the client and with minimal time delay. At the end of program execution, the client program is notified of the outcome by a completion message and a set of return values.
Communication with a transaction manager is automatic. The transaction manager mechanism does not establish an ongoing connection between the client and the transaction manager processes. The intent of the mechanism is for a small pool of server processes to service a large number of clients with real-time response.
Each transaction manager can process only the programs contained in its program library. Oracle Applications developers using Oracle Application Object Library can register transaction programs with a program library.
A transaction manager is associated with a particular data group, and uses that data group to connect to the database. Transaction managers can only process requests submitted from responsibilities associated with the same data group.
If you create custom data groups, you should define new transaction managers (using the predefined program libraries associated with the seeded transaction managers) for each application in your data group that uses transaction managers.