Use this window to define your concurrent managers. You can determine when a manager runs and how many programs a manager can start simultaneously when you assign workshifts to the manager. Determine which programs a manager can start by defining specialization rules.
The combination of an application and the name you define for your manager uniquely identifies the manager.
The application name does not prevent a manager from starting programs associated with other applications. To restrict a manager to only running programs associated with certain applications, go to the Specialization Rules window.
Once you define a concurrent manager, you cannot update this field. There are several types of managers:
| Concurrent Manager | Concurrent Managers start concurrent programs running. |
| Internal Monitor | Internal Monitors monitor the Internal concurrent manager in a parallel concurrent processing environment. If the Internal Concurrent Manager exits abnormally (for example, because its node or its database instance goes down), an Internal Monitor restarts it on another node. |
| Transaction Manager | Transaction managers handle synchronous requests from client machines. |
Enter the number of requests your manager remembers each time it reads which requests to run. For example, if a manager's workshift has 1 target process and a cache value of 3, it will read three requests and wait until these three requests have been run before reading new requests.
In reading requests, the manager will only put requests it is allowed to run into its cache. For example, if you have defined your manager to run only Order Entry reports then the manager will put only Order Entry requests into its cache.
If you enter 1, the concurrent manager must look at its requests list each time it is ready to process another request.
By setting the cache size at a higher number, the concurrent manager does not have to read its requests list each time it runs a request. However, the manager does not recognize any priority changes you make for a particular request if it has already read that request into its cache. Further, even if you give a higher priority to a new request, that new request must wait until the buffer is empty and the manager returns to look at the requests list. That request may have to wait a long time if you set the buffer size to a high number.
You should use cache size to tune your concurrent managers to work most efficiently for you site's needs. If your organization tends to reprioritize jobs going to a certain manager, that manager should have its buffer size set fairly low.
Suggestion: Enter a value of 1 when defining a manager that runs long, time-consuming jobs, and a value of 3 or 4 for managers that run small, quick jobs.
The data group the transaction manager uses to connect to the database. Transaction managers only run programs submitted from responsibilities that use the same data group as the transaction manager.
Note: Data groups are no longer supported by Oracle E-Business Suite. This section is provided for reference only.
The resource consumer group for the manager. For more information on resource consumer groups, see: Resource Consumer Groups in Oracle E-Business Suite.
If you are operating in a parallel concurrent processing environment and you want your manager to operate on a specific node, select the name of the node.
The primary node, if available, is the node your concurrent manager operates on. If the primary node or the database instance on it goes down, your concurrent manager migrates to its secondary node. Your concurrent manager migrates back to its primary node when that node becomes available.
Nodes must be previously registered with Oracle E-Business Suite, using the Nodes window. See: Nodes.
If you are operating in a parallel concurrent processing environment and you want your manager to use a platform-specific queue management system instead of generic concurrent processing queue management, specify the queue or class name of that system. For example, you may choose a system queue name from a platform-specific queue management system like NQS or IBM Load Leveler.
The primary system queue is the queue you associate with the primary node. The secondary system queue is the queue you associate with the secondary node.
Attention: To ensure that your manager uses your platform-specific queue management system, you should start the concurrent managers in the proper mode. Refer to platform-specific documentation to determine if your platform supports interfacing with system queues. For UNIX platforms, refer to the appropriate Oracle E-Business Suite installation Update. For all other platforms, refer to the appropriate Oracle E-Business Suite installation guide.
Concurrent managers can run only those immediate concurrent programs listed in their program library. They can also run concurrent programs that use any other type of concurrent program executable as long as the specialization rules include them.
Immediate concurrent programs must be registered in a program library by an applications developer using Oracle Application Object Library.
Transaction Managers can only run programs listed in their program library.
The buttons near the bottom of the window display additional windows for defining when your manager operates, specializing your manager to run only certain kinds of programs, and defining environment variables.
| Environment | You define environment variables and values for a regular concurrent manager in this window. Note that you cannot use this window for service managers internal to concurrent processing and the ICM. This window can also be used to define parameters for Java services. |
| Specialization Rules | You define what kinds of requests the manager reads by defining specialization rules for your manager. |
| Work Shifts | You define when the manager operates by assigning one or more work shifts to your manager. With each work shift, you can vary the number of programs the manager can run simultaneously. |