Oracle E-Business Suite System Administrator's Guide - Configuration Release 12.1 Part Number E12893-04

Contents

Previous

Next

Defining Concurrent Managers

Defining Managers and their Work Shifts in the Oracle Forms UI

This section 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 section, 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.

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 E-Business Suite 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 E-Business Suite 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.

  You cannot alter the definition of the Internal Concurrent Manager.

• 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 E-Business Suite developers using Oracle Application Object Library can register transaction programs with a program library.

Related Topics

Administer Concurrent Managers

Concurrent Managers

Work Shift Definitions

Using Work Shifts to Balance Processing Workload

Using Time-Based Queues

Work Shift by Manager Report

Work Shifts Report

Work Shifts

Overview of Concurrent Processing, Oracle E-Business Suite System Administrator's Guide - Maintenance

Work Shift Definitions

When you define a concurrent manager, you assign one or more work shifts to it. Work shifts determine when the manager operates. You define work shifts using the Work Shifts form.

Disabling a work shift

If you define a period of time as a work shift, but do not necessarily want to use the work shift, you can:

• Not assign the work shift to a concurrent manager

• Assign the number of target processes for the work shift as zero (0), on the Define Manager form.

• Delete a work shift assignment using the Define Manager form.

Work Shifts and Hours of the Day

Work shifts can run twenty-four hours a day, from midnight till the next midnight. In military time this is defined as:

• 12:00am - 00:00:00

• 11:59:59pm - 23:59:59

Using work shifts to run through midnight

The military time clock for a twenty-four period starts and stops at midnight.

If you do not want a work shift to run twenty-four hours a day, but you do want to run programs continuously past 12:00 am, you must define two work shifts:

• The first work shift stops at 23:59 (11:59pm).

• The second work shift starts at 00:00 (12:00 am).

For example, you want to run some data-intensive programs during the night, when most of your employees are away from the job site. You define two work shifts which you assign to this manager.

• The first work shift starts at 20:00 (8:00pm) and stops at 23:59 (11:59pm).

• The second work shift starts at 00:00 (12:00am) and stops at 05:00 (5:00am).

Overlapping Work Shifts - Priority Levels

If you assign overlapping work shifts to a concurrent manager, the work shift with the more specific time period takes effect for the overlapping time period. For example, a work shift for July 4 overrides a work shift from 9:00 am to 5:00 pm on Monday through Friday.

The following table presents a descending list of priority levels for overlapping work shifts. A work shift with a specific date and range of times has the highest priority. The "Standard" work shift has the lowest priority.

Overlapping Work Shifts with the same priority

When you have overlapping work shifts that have the same level of priority, the work shift with the largest target processes takes effect.

For example, you have two work shifts with a range of days and a range of times. You have a "Weekday" work shift from 9:00 am to 5:00 pm on Monday through Friday with 4 target processes.

You also have a "Lunch" work shift from 11:00 am to 1:00 pm on Monday through Friday with 8 target processes.

The "Lunch" work shift takes effect from 11:00 am to 1:00 pm (Mon.-Fri.) because it has the larger number of target processes.

Related Topics

Defining Managers and their Work Shifts

Using Work Shifts to Balance Processing Workload

Using Time-Based Queues

Using Work Shifts to Balance Processing Workload

Part of a manager's definition is how many operating system processes it can devote to reading requests. For each of these processes, referred to as a target process, a manager can start one concurrent program.

For each work shift you assign to a manager, you define a number of target processes.

By using work shifts with different numbers of target processes, you can modify your concurrent processing workload according to the day, time of day, and even specific dates.

The figure below illustrates how, by using three work shifts, a manager can be defined to run three programs concurrently from 6:00am-6:00pm, and six programs concurrently from 6:00pm-6:00am.

Failover Sensitivity for Work Shifts

Nodes can become overloaded when a middle-tier node fails and service instances on that node failover to their secondary nodes. The Load Distribution feature allows the System Administrator to control the allocation of resources during normal processing. The Failover Sensitivity feature allows Work Shifts to failover with fewer target processes than on the original node. This lessens the impact on the existing resources allocated on the secondary node.

The number of failover target processes is entered as part of the standard Work Shift settings in the Service Instance Definition. When failover occurs, the ICM uses the Failover Processes value in place of the normal running processes value as it iterates through service instances to perform queue sizing.

Related Topics

Defining Managers and their Work Shifts

Work Shift Definitions

Using Time-Based Queues

Work Shift by Manager Report

Work Shifts Report

Work Shifts

Using Time-Based Queues

You can create several time-based queues by defining managers to run programs based on how long those programs have typically run in the past. That is, you can specialize managers to segregate requests according to how long those requests take to run.

To do this, use the Completed Concurrent Requests Report in the System Administrator's report security group. This report lists the actual start date and time and actual completion date and time for concurrent programs that completed running. See: Completed Concurrent Requests Report.

Tip: Run your concurrent programs at different times, perhaps, late at night and then again during the midafternoon, to determine processing time during different workload periods.

For example, based on actual time-to-completion, you can specialize different managers to run the following types of programs:

• inventory pick lists

• payable check runs

• postings

• invoice imports

Augment this approach by defining an "overflow" manager, for example, a manager who can accommodate programs directed to one (or more) of the managers above, but whose work shift is restricted to say, 2:00am-4:00am (02:00-04:00). If some of your long-running programs have not started running before the "overflow" work shift begins, then an additional manager is enabled to accommodate those programs.

Further augment this approach with an "exception" manager defined for must have requests. For example, a manager that can run:

• certain programs that must complete by a certain time. The "must-have" manager can be specialized to only read requests for certain programs.

• programs submitted by a particular user, for example, the Company Controller. You can specialize a manager to only read requests from a single application user. You can even define a second, higher-priority, username for a user to sign on with.

Related Topics

Defining Managers and their Work Shifts

Work Shift Definitions

Using Work Shifts to Balance Processing Workload

Work Shift by Manager Report

Work Shifts Report

Specializing Managers to run only certain programs

Grouping Programs by Request Type

Administer Concurrent Managers

Concurrent Managers

Work Shifts

Creating Services within Oracle Applications Manager

Creating and Editing a Concurrent Manager

Use this page to create a new concurrent manager.

Navigation: Site Map > Request Processing Managers (under Application Services) > (B) Create New or (B) Edit

You can define when a manager runs and how many programs the manager can start simultaneously when you assign work shifts to the manager. Specify which programs a manager can start by defining specialization rules.

General

Enter the following information:

Enabled

Check this box if the manager is enabled.

Manager

The name of the manager.

Short Name

The short name of the manager.

Application

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 Rules section.

The combination of an application and the name you define for your manager uniquely identifies the manager.

Cache Size

Enter the number of requests your manager remembers each time it reads which requests to run. For example, if a manager's work shift has 1 target process and a cache value of 3, it will read three requests, and try to run those three requests before reading any new requests.

Tip: 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.

Program Library

Select a library of immediate concurrent programs to make available to your manager. Your manager can only run immediate concurrent programs that are registered in the selected program library. 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.

Resources Group

Optionally enter the resource consumer group for this manager.

Rules

Use the Rules section to specialize your manager to run only certain kinds of requests. Without specialization rules, a manager accepts requests to start any concurrent program.

A listing of available rules is displayed. Check the Include check box for a rule to include it.

The following information is also given for each rule:

• Type

• Application

• Name

• Description

To edit any of this information, use the Edit button. Use the Remove button to remove a rule from the list. To create a new rule, use the Create New dropdown list and click Go.

Work Shifts

Use the Work Shifts section to assign work shifts to your manager. A work shift defines the dates and times the manager is enabled, as well as the number of processes the manager can start running during the work shift.

To add a work shift, use the Add from Available Shifts button.

For each work shift listed, the following is displayed:

Sleep Seconds

The sleep time for your manager during this work shift. Sleep time is the number of seconds your manager waits between checking the list of pending concurrent requests (concurrent requests waiting to be started).

Tip: Set the sleep time to be very brief during periods when the number of requests submitted is expected to be high.

Processes

The number of operating system processes you want your work shift to run simultaneously. Each process can run a concurrent request.

For example, if a work shift is defined with three (3) target processes, the manager can run up to three requests simultaneously.

Failover Processes

In the case of node failover, the maximum number of processes that the work shift can run simultaneously.

Nodes can become overloaded when a middle-tier node fails and service instances on that node failover to their secondary nodes. The Failover Processes value should be smaller than the normal Processes value, to lessen the impact on the existing resources allocated on a secondary node. When failover occurs, the ICM uses the Failover Processes value in place of the normal running processes value as it iterates through service instances to perform queue sizing.

Nodes

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 in Oracle E-Business Suite.

Creating and Editing a Transaction Manager

Use this page to create a new Transaction Manager. Transaction Managers handle synchronous requests from client machines.

Navigation: Site Map > Transaction Managers (under Application Services) > (B) Create New or (B) Edit

General

Enter the following information:

Enabled

Check this box if this transaction manager is enabled.

Manager

The name of the transaction manager.

Short Name

The short name for your transaction manager.

Application

The application associated with the transaction manager.

The combination of an application and the short name you specify here uniquely defines the transaction manager.

Program Library

Select a library of immediate transaction programs to make available to your manager. Your manager can only run immediate transaction programs that are registered in the selected program library. Transaction managers can run only those immediate transaction programs listed in their program library. They can also run transaction programs that use any other type of transaction program executable.

Work Shifts

Use the Work Shifts section to assign work shifts to your manager. A work shift defines the dates and times the manager is enabled, as well as the number of processes the manager can start running during the work shift.

To add a work shift, use the Add from Available Shifts button.

For each work shift listed, the following is displayed:

Sleep Seconds

The sleep time for a transaction manager determines how often a manager will check to see if it should shut down.

Tip: Set the sleep time to be very brief during periods when the number of requests submitted is expected to be high.

Processes

The number of operating system processes you want your work shift to run simultaneously. Each process can run a concurrent request.

For example, if a work shift is defined with three (3) target processes, the manager can run up to three requests simultaneously.

Nodes

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 in Oracle E-Business Suite.

Creating and Editing an Internal Monitor

Use this page to create a new 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.

General

Enter the following information:

Enabled

Check this box if this internal monitor is enabled.

Manager

The name of the internal monitor.

Short Name

The short name for your internal monitor.

Application

The application associated with the internal monitor.

The combination of an application and the short name you define for your internal monitor uniquely identifies the monitor.

Program Library

For an Internal Monitor, the program library is FNDIMON.

Work Shifts

Use the Work Shifts section to assign work shifts. A work shift defines the dates and times the manager is enabled, as well as the number of processes the manager can start running during the work shift.

To add a work shift, use the Add from Available Shifts button.

For each work shift listed, the following is displayed:

Sleep Seconds

The sleep time for your manager during this work shift. Sleep time is the number of seconds your manager waits between checking the list of pending concurrent requests (concurrent requests waiting to be started).

Tip: Set the sleep time to be very brief during periods when the number of requests submitted is expected to be high.

Processes

The number of operating system processes you want your work shift to run simultaneously. Each process can run a concurrent request.

For example, if a work shift is defined with three (3) target processes, the manager can run up to three requests simultaneously.

Nodes

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 in Oracle E-Business Suite.

Create a New Work Shift

Use this page to define work shifts for your services. Define work shifts to specify when your services can work.

Navigation: Site Map - Administration > [Service Instance type] (under Application Services) > Create [Service] > Workshifts region, (B) Add from Available Shifts > (B) Create New Site Map > Work Shift Library (under Application Services) > Create New

• Name - The name of your work shift should be intuitive, for instance "Week Days", "Weeknights" or "Weekends".

• Description - Add a description for your work shift.

• Schedule - For each work shift, specify a time period covering a range of days or a particular date. Specify if you are scheduling by day or by date.

• Day - Enter the first and last days of this shift. For instance, if your shift name is "Week Days", you could enter "Monday" in the "Days of Week From" field and "Friday" in the "Days of Week To" field. If you enter a value in the "Days of Week From" field, you must enter a value in the "Days of Week To field".

• Date - Enter a date here to create a date-specific work shift. Date-specific work shifts override work shifts that do not specify a specific date. If you want to enter a value in this field (specify a date), you may not enter values for the Days of Week fields for this row.

• Time - Enter the times of day at which your concurrent shift begins/ends. The time format is HH24:MM. For example, if your work shift name is "Week Days", you could enter "09:00" (9:00 am) as the start time and "17:00" (5:00 pm) as the end time. Note that Oracle E-Business Suite uses a 24-hour clock.

List of Work Shifts

This page displays the available work shifts.

Navigation: Site Map - Administration > Request Processing Managers (under Applications Systems) > Create New or Edit [Service] > Workshifts region, (B) Add from Available Shifts

The following columns are shown: Name, Start Day, End Day, Start Time, End Time, Date, and Description.

You can use the buttons to edit or delete an existing work shift, or create a new one.

Completed Concurrent Requests Report

This report displays how long concurrent programs actually run. Use this report to segregate requests, based on their typical time-to-complete, by specializing concurrent managers to only read requests for certain programs.

Use this report to record parameters and error messages associated with concurrent programs that have been run.

Report Parameters

If you do not enter any parameters, the report returns values for all completed concurrent requests.

Program Application Name

Choose the application name associated with the program whose completed concurrent requests you wish to report on.

Choose only an application name, without a program name, if you wish to run a report on all completed concurrent requests associated with an application.

Program Name

Choose the name of a program whose completed concurrent requests you wish to report on. You must enter a value for Program Application Name before entering a value for Program Name.

User Name

Choose the name of an application user whose completed concurrent requests you wish to report on.

Start Date/End Date

Enter the start date and end date for your report.

Report Headings

The report headings list the specified parameters and provide you with general information about the contents of the report.

Related Topics

Reviewing Requests, Request Log Files, and Report Output Files, Oracle E-Business Suite System Administrator's Guide - Maintenance

Managing Concurrent Processing Files and Tables, Oracle E-Business Suite System Administrator's Guide - Maintenance

Using Time-Based Queues

Specializing Managers to run only certain programs

Grouping Programs by Request Type

Work Shift by Manager Report

This report documents the work shifts assigned to each concurrent manager. Use the report when defining or editing concurrent managers.

Report Parameters

None.

Report Headings

The report headings provide you with general information about the contents of the report.

Related Topics

Defining Managers and their Work Shifts

Work Shifts Report

Work Shifts Report

This report documents all of your work shift definitions. Use this report when defining or editing concurrent manager work shifts.

Report Parameters

None.

Report Headings

The report headings provide you with general information about the contents of the report.

Related Topics

Defining Managers and their Work Shifts

Work Shift Definitions

Work Shifts Report

Work Shift by Manager Report

Work Shifts field help

Specializing Managers to Run Only Certain Programs

This essay explains how you can specialize managers to run only certain programs.

Introduction to Specialization Rules

Every time your users request a concurrent program to be run, their request is inserted into a database table. Concurrent managers read requests from this table, and start running programs if the manager is defined to read the particular request.

Without specialization rules, a manager reads requests to start any concurrent program.

Using specialization rules, you can specialize a manager to read only certain kinds of requests to start concurrent programs, for example, only requests to start Oracle General Ledger programs, or only requests to start programs requested by the user "Fred". See: Concurrent Managers.

A special type of specialization rule is the combined specialization rule, that can combine more than one action to define a single rule. See: Combined Specialization Rules.

Related Topics

Defining Specialization Rules

Examples - Using Specialization Rules

Defining Combined Specialization Rules

Controlling Concurrent Managers

Concurrent Managers field help

Defining Specialization Rules

A specialization rule associates an action with a type of request. There are two kinds of actions: Include and Exclude.

• Include defines a manager to only read requests of the type specified.

• Exclude defines a manager to read all requests except the type specified.

Requests to run concurrent programs may be allowed or disallowed on the basis of:

• the ORACLE ID of the request's Set of Books (for multiple installs) or Organization if you are using multiple organizations.

• the program itself or the program's application

• the request type of the program

• the user who submitted the request

• a combined rule, which combines more than one action to generate a single rule. The combined rule applies its actions to one or more types of request.

  For example, a combined rule can exclude an action from an Oracle ID and exclude another action from a specific program.

Using more than one rule

Each rule performs one action. When using more than one rule, the rules are evaluated as follows:

• Include rules are evaluated together using 'OR' statements as the binding logic.

  For example, If you use the rules:

  • Include X

  • Include Y

    The result of the rules allows the manager to run either X 'OR' Y but does not require that both programs be run.

• Exclude rules are evaluated together using 'AND' statements as the binding logic.

  For example, If you use the rules:

  • Exclude 1

  • Exclude 2

    The result of the rules prohibits the manager from running programs 1 'AND' 2 together or separately.

• Include rules are evaluated first, then Exclude rules are evaluated. Include rule(s) and Exclude rule(s) are evaluated together as an AND statement. For example, (Include X OR Y) AND (Exclude 1 AND 2).

• An Exclude rule overrides an Include rule.

Specialization rule actions, their binding logic, and examples are presented in the following two tables. See: Specialization Rule Logic - Examples.

Specialization Rule Logic - Examples

The following table gives examples of the action types associated with specialization rules.

Related Topics

Specializing Managers to run only certain programs

Examples - Using Specialization Rules

Defining Combined Specialization Rules

Using Combined Rules

Differences Between Specialization and Combined Rules

Concurrent Managers field help

Combined Specialization Rules field help

Examples - Using Specialization Rules

Following are examples of using specialization rules to define what requests a concurrent manager can read. When multiple rules are used to specialize a manager, the words OR and AND appear between each rule to clarify the relationship among multiple specialization rules.

Using Include and Exclude actions

OR

AND

Simplifying your work

Multiple rules may not always be necessary, or the number or complexity of rules can be simplified. Consider the example below.

OR

Exclude rules override Include rules

AND

AND

Specializing to only run a Program against specific Oracle IDs

In the following example, a manager can be specialized to only run a program against a specific Oracle ID. This is useful when there are multiple installations of an Oracle Application.

AND

Distinguishing a Program from a Request Type

You can specialize a manager to read requests to run all the programs belonging to a Request Type, except for individual programs you wish to identify.

AND

Preventing specific programs from running

You can use an Exclude action more than once. For example, suppose your manager reads all requests to run concurrent programs for a particular application, but you want to prevent your manager from running two specific programs. You can:

AND

AND

Specializing to run only specific programs at certain times

Using multiple Include rules, you can specialize a manager to run only specific programs. Then, when you define the manager's work shift, you can control when the manager reads requests to run the specific programs.

OR

Specializing according to Application User

You can specialize managers to only read requests from specific users.

OR

OR

Related Topics

Specializing Managers to run only certain programs

Defining Specialization Rules

Defining Combined Specialization Rules

Concurrent Managers field help

Defining Combined Specialization Rules

A combined specialization rule combines more than one action to generate a single rule. The actions are combined as AND statements so that the rule is defined as:

Action 1 AND . . .

Action 2 AND . . .

Action 3 AND . . . so on.

You can create combined rules and use them with several managers, instead of duplicating a complex rule each time.

There are two kinds of Actions you may use to build a combined rule; Exclude and Include. Each action is defined by one line within the rule. Combining the specialization lines or individual actions defines the overall combined rule.

An Exclude action overrides a Include action.

For example, you can define an Exclude application program x action and a Include user Yvonne Jones action. Combining these two actions generates the combined rule "read all requests from user Yvonne Jones except requests to run program x". See: Combined Specialization Rules.

Combined specialization rule actions, their binding logic, and examples are presented in the following table.

Related Topics

Specializing Managers to run only certain programs

Defining Specialization Rules

Using Combined Rules

Differences Between Specialization and Combined Rules

Concurrent Managers field help

Combined Specialization Rules field help

Using Combined Rules

Using combined rules you can precisely specialize a manager.

A combined rule combines more than one action to generate a single rule. Each action is defined by one line within the rule. Combining the lines or individual actions defines the overall combined rule.

Tip: You can use a combined specialization rule as one of many rules to specialize a manager.

Using single Exclude and Include actions

A single Exclude action within a combined rule acts the same way as a single Exclude action that defines a specialization rule. Both instruct a manager to read all requests to run concurrent programs except those identified by the action.

A single Include action within a combined rule acts the same way as a single Include action that defines a specialization rule. Both actions instruct a manager to read only the requests that satisfy the action.

Using multiple Exclude actions

Using multiple Exclude actions as multiple lines within a combined rule is equivalent to using multiple Exclude actions as multiple specialization rules.

You can exclude more kinds of requests by adding more Exclude lines to your combined rule.

AND

Using multiple Include actions

Using multiple Include actions adds more requirements to a combined rule, and excludes more kinds of requests.

You cannot use two Include actions for the same action type. Each Include action is an exclusive statement for a particular type of action. For example, you cannot require a request to be for a program that connects to two different Oracle IDs.

AND

Using Exclude and Include actions

You cannot use Exclude and Include actions for the same type of action. Each Include action is an exclusive statement for a particular type of action.

For example, it does not make sense to require a request to be for a program that connects to the Oracle ID “APPS" and disallow a request to connect to another Oracle ID.

Exclude overrides Include

When using multiple lines within a Combined Rule, the Exclude action always overrides a Include action.

AND

Specializing a manager to run one program submitted by one user

You can define a combined rule that instructs a manager to only read requests to run a single program when submitted by a specific user.

AND

Restricting the programs a manager will run for a specific user

You can define a combined rule that instructs a manager to ignore requests to run a certain programs when submitted by a specific user.

AND

Specifying Oracle ID and excluding a program from a request type

AND

AND

Related Topics

Specializing Managers to run only certain programs

Defining Combined Specialization Rules

Differences Between Specialization and Combined Rules

Concurrent Managers field help

Combined Specialization Rules field help

Differences Between Specialization and Combined Rules

The primary difference between a specialization rule and a combined specialization rule is in how the use of multiple actions affects the outcome of the rule, as described in the following table:

Related Topics

Specializing Managers to run only certain programs

Examples - Using Specialization Rules

Defining Combined Specialization Rules

Using Combined Rules

Concurrent Managers field help

Combined Specialization Rules field help

Grouping Programs by Request Type

As System Administrator, you may want to group similar programs together. You do this by defining request types and assigning them to the programs that users request in Oracle E-Business Suite. You can define concurrent managers that only run programs that belong to a particular request type.

Using request types to specialize concurrent managers can help optimize the processing of Oracle E-Business Suite by letting certain types of programs run without having to wait for other types of programs to finish processing. Using request types saves you time when you create a concurrent manager's specialization rules.

Using Request Types

Specializing a concurrent manage by request type involves three steps:

1. Define a Request Type using the Concurrent Request Types form.

2. Assign the Request Type to each concurrent program you want to identify as a member of this request type using the Concurrent Programs form.

3. Select the Request Type when you specialize a concurrent manager using the Concurrent Managers form.

Examples of using Request Types

Some example request types you may want to define are:

Related Topics

Overview of Concurrent Processing, Oracle E-Business Suite System Administrator's Guide - Maintenance

Using Time-Based Queues

Completed Concurrent Requests Report

Specializing Managers to run only certain programs

Administer Concurrent Managers

Concurrent Managers

Controlling Concurrent Managers

This essay explains how to control your concurrent managers.

Manager States

Individual managers read requests to start concurrent programs and actually start programs running when certain conditions are satisfied, such as the manager's work shift definition, number of target processes, and specialization rules.

You can start, shut down, or reset the concurrent managers at any time. Oracle E-Business Suite provides an Internal Concurrent Manager that processes these commands. You can issue commands either to individual managers, or, by altering the state of the Internal Concurrent Manager, you can control every manager at once.

Note: Start your concurrent managers on machines with hostnames of 30 or fewer characters. Managers may fail to start on machines with longer hostnames.

Starting Individual Managers

You can restart or activate managers on an individual basis. Restarting a concurrent manager forces the Internal Concurrent Manager to reread the definition for that concurrent manager. Activating a manager cancels a previous command to deactivate it, and allows the Internal Concurrent Manager to submit a request to start that manager when its work shift starts.

You should restart an individual manager when you:

• modify its work shift assignments

• modify a work shift's target number of processes

• modify its specialization rules

• change a concurrent program's incompatibility rules

Deactivating Individual Managers

When you shut down an individual manager, you can choose whether to abort all requests and deactivate the manager immediately, or to allow it to finish processing its current requests before deactivating.

If you choose to Deactivate the manager, requests that are currently running are allowed to complete.

When you terminate requests and deactivate an individual manager, requests that are currently running are immediately stopped and marked for resubmission (when the manager is activated).

Oracle E-Business Suite concurrent programs are designed so that no data is lost or duplicated when a terminated request is resumed after a shut down. This applies for shutdowns that are normal (e.g., using the "Deactivate concurrent manager" request) or abnormal (e.g., after a hardware failure).

Important: When a manager is selected and explicitly deactivated, it remains that way until you select and explicitly activate that manager. As a prerequisite, the Internal manager must be activated beforehand.

Controlling the Internal Concurrent Manager

When you activate the Internal Concurrent Manager, you activate all other managers as well, except those managers that were deactivated on an individual basis.

When you deactivate the Internal Concurrent Manager, it issues commands to deactivate all active managers. Managers that were deactivated on an individual basis are not affected.

If you terminate requests and deactivate the Internal Concurrent Manager, it issues commands to all other managers to terminate their requests and deactivate. Requests that are currently running are immediately stopped and marked for resubmission when the managers are activated.

Verify Concurrent Manager Status

The Internal Concurrent Manager continuously monitors each concurrent manager's operating system process. This process monitoring is referred to as the Internal Concurrent Manager's PMON cycle. The length of the PMON cycle is one of the arguments passed by the STARTMGR command, which starts up the Internal Concurrent Manager.

You can instruct the Internal Concurrent Manager to immediately verify the operating status of your individual concurrent managers, or to perform a PMON check.

Startup Threshold for Concurrent Managers

Concurrent Managers are started from a Service Manager, which in turn is started by the Internal Concurrent Manager. You can set a threshold for the number of requests the Internal Concurrent Manager will make to start a concurrent manager after it fails to start.

During each ICM PMON cycle, the managers are verified and the system attempts to place a lock on each specific manager. If a manager is not up as expected, then the ICM submits a request to start it. However, a manager may have an underlying issue, such as a configuration issue or corrupted executable, that prevents it from starting. By setting a maximum number of attempts the ICM will make to start a manager over a set time, you can prevent the ICM from continuously making futile attempts to start these managers.

After the underlying problem is fixed, you can restart the manager from the Administer Managers window.

The startup threshold is defined by two profile options:

• CONC: Manager Startup Threshold Limit - This value determines the number of attempts to restart a manager before the system will stop and alert the system administrator. The default value of this profile is 10 (attempts).

• CONC: Manager Startup Threshold Time (minutes) - This value determines the length of time the attempts will be made to restart a manager. If the Threshold Limit as defined above is reached within this time limit, the attempts will stop until the underlying issue has been addressed. The default value of this profile is 60 minutes (1 hour).

If a manager has failed to start after the specified number of attempts (cycles), the manager will not be checked. You can fix the underlying problem, and after it is addressed, you can go to the Administer Managers window, select the manager, and click the Fixed button.

The concurrent manager startup threshold can be disabled by setting the profile option CONC: Manager Startup Threshold Limit to 0. This setting will cause the Threshold functionality to be ignored when managers are being checked for restarting.

Controlling Managers from the Administer Managers form

Use the Administer Concurrent Managers form to issue commands to your concurrent managers.

You can also have the Internal Concurrent Manager "manually" verify the status of your individual managers, and restart individual managers. See: Administer Concurrent Managers.

The following table describes control functions for the Internal Manager.

The following table describes control functions for any other manager.

Controlling the Internal Concurrent Manager from the Operating System

To start the Internal Concurrent Manager, use the shell script adcmctl.sh.

Alternatively, use one of two other commands you may use from the operating system to control the Internal Concurrent Manager: STARTMGR, which starts the Internal Concurrent Manager; and CONCSUB, which can be used to deactivate or abort the Internal Concurrent Manager, or to instruct the Internal Concurrent Manager to verify the operating system process for each individual manager.

The following table compares the Internal manager control states displayed by the Administer Concurrent Managers form with their corresponding operating system command. Not all arguments are shown.

Starting the Internal Concurrent Manager from the Operating System

To start the Internal Concurrent Manager, use the shell script adcmctl.sh.

This command starts the Internal Concurrent Manager, which in turn starts any concurrent managers you have defined.

Alternatively, to start the concurrent managers, you can invoke the STARTMGR command from your operating system prompt.

You must have write privileges to the "out" and "log" directories of every application so that the concurrent managers can write to these directories. You can start the concurrent managers with many different options. An option on some operating systems is to send an electronic mail note to a given user when the concurrent managers shut down. See your installation guide for a discussion of this command.

Use the STARTMGR command:

• during installation of Oracle E-Business Suite

• after you shut down the concurrent managers

• after MIS restarts the operating system

• after the database administrator restarts the database

The STARTMGR command takes up to ten optional parameters.

• Each parameter except PRINTER has a default.

• You can modify the STARTMGR command and your environment to set your own defaults.

Enter the following command at your system prompt to start the Internal Concurrent Manager:

$ startmgr  <optional parameters> 

You can pass the parameters in any order. For example:

$ startmgr sysmgr="<username>/<password>"  mgrname="std" 
 printer="hqseq1"  mailto="jsmith"  restart="N" 
 logfile="mgrlog"  sleep="90"  pmon="5"  quesiz="10"

The startmgr script accepts an Oracle username/password as the sysmgr parameter. Alternatively, you could pass an Oracle E-Business Suite username/password as an appmgr parameter. If no sysmgr or appmgr parameter is provided on the command line, startmgr will prompt you for the Oracle password.

See: Setting Up Concurrent Managers

Viewing the Internal Concurrent Manager startup parameters

The Internal Concurrent Manager's log file displays startup parameter values executed by the STARTMGR command. An example is shown below. You cannot change the parameter values.

logfile=/fnddev/fnd/6.0/log/FND60.mgr  (path is port-specific)
	PRINTER=hqunx138  
	mailto=appldev  
	restart=N    
	diag=N   
  sleep=60 (default)  
	pmon=20 (default)    
	quesiz=1  (default)  

Shutting down the Internal Concurrent Manager from the Operating System

From the operating system prompt, you can use the CONCSUB utility to submit a concurrent request, under the SYSADMIN username and the System Administrator responsibility.

The CONCSUB utility submits a concurrent request and returns you to the operating system prompt. You must wait until the concurrent request completes.

To check on the status of your concurrent request, use the Concurrent Requests form.

CONCSUB username/password 'Responsibility application shortname'
 'Responsibility name' 'Username' [WAIT={Y|N|n}] CONCURRENT
 'Program application shortname'  PROGRAM 

Parameters

Example Syntax using CONCSUB

CONCSUB <Username/Password> SYSADMIN 'System Administrator'
 SYSADMIN  CONCURRENT FND DEACTIVATE 

CONCSUB <Username/Password> SYSADMIN 'System Administrator'
 SYSADMIN  CONCURRENT FND ABORT 

CONCSUB <Username/Password> SYSADMIN 'System Administrator'
 SYSADMIN  CONCURRENT FND VERIFY 

Using CONCSUB to shut down your managers

Use CONCSUB to shut down the concurrent managers:

• before MIS shuts down the operating system

• before the database administrator shuts down the database

• when you want concurrent manager and concurrent program definitions to take effect

Then, use the STARTMGR command to restart the Internal Concurrent Manager, which starts the concurrent managers.

Example - nightly shutdown using CONCSUB

You can use the token WAIT with value Y ( WAIT=Y ) if you want to use CONCSUB to issue a concurrent request from within a shell script containing a sequence of steps. Using the token WAIT insures the managers deactivate, abort, or verify status before the shell script proceeds to the next step.

See: Controlling the Internal Concurrent Manager from the Operating System

1. Shell script customized for specific operating system starts.

2. CONCSUB username/password SYSADMIN 'System Administrator' SYSADMIN WAIT=Y CONCURRENT FND DEACTIVATE

   When the shell script passes control to CONCSUB, CONCSUB waits until the program DEACTIVATE is complete before it returns control to the shell script.

3. Script issues the command to shut down the database.

4. Script issues the command to backup the database.

5. Script issues the command to startup the database.

6. $ startmgr sysmgr="apps/fnd" mgrname="std" printer="hqseq1" mailto="jsmith" restart="N" logfile="mgrlog" sleep="90" pmon="5" quesiz="10"

   The shell script passes control to STARTMGR, which starts up the Internal manager (and all the other managers).

7. Shell script completes.

Hiding the password using CONCSUB

If the username/password are still supplied, the CONCSUB utility will work as usual.

If username only is supplied (no '/password' in the first argument), it will prompt you for an Oracle E-Business Suite username and password.

In the following example, CONCSUB would connect using the .dbc file, and then only run if the Oracle E-Business Suite user "sysadmin" with password "sysadmin" is successfully authenticated.

CONCSUB Apps:User SYSADMIN 'System Administrator' SYSADMIN/sysadmin
 CONCURRENT FND VERIFY

The user can put the password in a file, and then redirect it to standard input (stdin). In UNIX the command would be executed as follows:

CONCSUB Apps:User SYSADMIN 'System Administrator' SYSADMIN
 CONCURRENT FND
FNDMNRMT Y 0 20221 < password.file 

where password.file is an ASCII file that contains the password. This method is recommended for use in shell scripts or batch processes.

Overview of Parallel Concurrent Processing

This essay explains what parallel concurrent processing is, describes the environments it runs in, and explains how it works.

What is Parallel Concurrent Processing?

Parallel concurrent processing allows you to distribute concurrent managers across multiple nodes in a cluster, massively parallel, or networked environment. Instead of operating concurrent processing on a single node while other nodes are idle, you can spread concurrent processing across all available nodes, fully utilizing hardware resources.

Benefits of Parallel Concurrent Processing

Parallel concurrent processing provides Oracle E-Business Suite users with the following benefits:

• High performance - the ability to run concurrent processes on multiple nodes to improve concurrent processing throughput.

• Fault Tolerance - the ability to continue running concurrent processes on available nodes even when one or more nodes fails.

• Adaptability - the ability to integrate with platform-specific batch queue and load-balancing systems to maximize concurrent processing performance on a particular platform.

• Single Point of Control - the ability to administer concurrent managers running on multiple nodes from any node in a cluster, massively parallel, or networked environment.

Parallel Concurrent Processing Environments

Parallel concurrent processing runs in multi-node environments, such as cluster, massively parallel, and networked environments. In these environments, each node consists of one or more processors (CPUs) and their associated memory. Each node has its own memory that is not shared with other nodes And each node operates independently of other nodes, except when sharing a resource such as a disk.

With parallel concurrent processing, one or more concurrent managers run on one or more nodes in a multi-node environment. You decide where concurrent managers run when configuring your system.

You can define any set of concurrent manager specialization rules, and apply them across nodes in any way desired. For example, three “Oracle General Ledger" concurrent managers could be spread across three nodes. Or an “Oracle Payables" concurrent manager and an “Oracle General Ledger" concurrent manager could run simultaneously on the same node.

The following are examples of environments in which parallel concurrent processing can run:

Cluster Environments

In a cluster environment, multiple computers, each representing a single node, share a common pool of disks.

With parallel concurrent processing in a cluster environment, a single ORACLE database resides in the common disk pool, while multiple instances of Real Application Clusters (RAC) run simultaneously on multiple nodes in the cluster. Multiple concurrent managers are also distributed across the nodes in the cluster.

Massively Parallel Environments

In a massively parallel environment, multiple nodes are housed in a single computer. All nodes share access to a common pool of disks. The IBM SP/2, for example, is a massively parallel computer.

With parallel concurrent processing in a massively parallel environment, separate RAC instances run simultaneously on multiple nodes, with multiple concurrent managers also distributed across nodes.

Networked Environments

In networked environments, multiple computers of the same type are connected via a local area network (LAN) to a single database server, or alternatively, to a cluster of database servers.

For example, a simple networked environment could consist of multiple Sun SPARCstations connected via a LAN to a single Sequent server. In a more complex networked environment, multiple Sun SPARCstations could connect to a cluster of Sequent servers.

With parallel concurrent processing in a networked environment, concurrent managers run on multiple workstations. A single database server runs a single instance of ORACLE; or, a cluster of database servers runs multiple ORACLE instances using RAC.

How Parallel Concurrent Processing Works

Concurrent Managers

With parallel concurrent processing, each node with concurrent managers may or may not be running an ORACLE instance. On a node that is not running ORACLE, the concurrent manager(s) connect via Net8 to a node that is running ORACLE.

Parallel concurrent processing is activated along with Generic Service Management (GSM); it can not be activated independently of GSM. With parallel concurrent processing implemented with GSM, the Internal Concurrent Manager (ICM) tries to assign valid nodes for concurrent managers and other service instances. Primary and secondary nodes need not be explicitly assigned. However, you can assign primary and secondary nodes for directed load and failover capabilities.

Note: In previous releases, you must have assigned a primary and secondary node to each concurrent manager.

Initially, a concurrent manager is started on its defined primary node, or if none exists, the node that the ICM assigns to it. In case of node or ORACLE instance failure, all concurrent managers on that node migrate to their respective secondary nodes if defined.

A concurrent manager on its secondary node migrates back to its primary node once that node becomes available. During migration, the processes of a single concurrent manager may be spread across its primary and secondary nodes.

Internal Concurrent Manager

The Internal Concurrent Manager can run on any node, and can activate and deactivate concurrent managers on all nodes. Since the Internal Concurrent Manager must be active at all times, it needs high fault tolerance. To provide this fault tolerance, parallel concurrent processing uses Internal Monitor Processes.

Internal Monitor Processes

The sole job of an Internal Monitor Process is to monitor the Internal Concurrent Manager and to restart that manager should it fail. The first Internal Monitor Process to detect that the Internal Concurrent Manager has failed restarts that manager on its own node.

Only one Internal Monitor Process can be active on a single node. You decide which nodes have an Internal Monitor Process when you configure your system. You can also assign each Internal Monitor Process a primary and a secondary node to ensure failover protection.

Internal Monitor Processes, like concurrent managers, have assigned work shifts, and are activated and deactivated by the Internal Concurrent Manager.

Concurrent Programs and Requests

You can optionally define a target node for a concurrent program. When a request for the program is submitted, only available managers running on the specified node will pick it up.

If no specification is made for the target node of a concurrent program, a request for it will be picked up by any manager available to run it. If a node specification is made for a concurrent program and the node is up, only available managers running on the specified node will pick up the request. However, if the target node is down, any available manager will pick up the request for processing and log an appropriate message in FND_LOG_MESSAGES.

If no specification is made for the target instance of a concurrent program, a request for it will be picked up by the first manager available to run it and will be run in the instance where the manager is already connected. If an instance specification is made for a concurrent program and the instance is up, it will be picked up by the first manager available to run it and the manager will run the request in the specified instance. However, if the target instance is down, the manager will run the request in the instance where it is already connected and log an appropriate message.

Log and Output File Access

The concurrent log and output files from requests that run on any node are accessible online from any other node. Users need not log onto a node to view the log and output files from requests run on that node.

Integration with Platform-Specific Queuing

Some cluster or massively parallel systems have their own mechanisms for queuing batch processes; for example, IBM LoadLeveler. Because users may wish to manage all processing with these mechanisms (and not just Oracle E-Business Suite processing), parallel concurrent processing is designed to integrate with them. Thus, you can match your concurrent process management to the specific capabilities of your operating platform.

For more information on integrating with platform-specific queuing, refer to the installation documentation for your platform.

Managing Parallel Concurrent Processing

This section describes how to manage parallel concurrent processing.

Parallel concurrent processing is always active when Generic Service Management (GSM) is active. Parallel concurrent processing can no longer be activated independently of Generic Service Management.

However, automatic activation of PCP does not additionally require that primary nodes be assigned for all concurrent managers and other GSM-managed services. If no primary node is assigned for a service instance, the Internal Concurrent Manager (ICM) assigns a valid concurrent processing server node as the target node. In general, this node will be the same node where the Internal Concurrent Manager is running. In the case where the ICM is not on a concurrent processing server node, the ICM chooses an active concurrent processing server node in the system. If no concurrent processing server node is available, no target node will be assigned.

Note that if a concurrent manager does have an assigned primary node, it will only try to start up on that node; if the primary node is down, it will look for its assigned secondary node, if one exists. If both the primary and secondary nodes are unavailable, the concurrent manager will not start (the ICM will not look for another node on which to start the concurrent manager). This strategy prevents overloading any node in the case of failover.

The concurrent managers are aware of many aspects of the system state when they start up. When an ICM successfully starts up it checks the TNS listeners and database instances on all remote nodes and if an instance is down, the affected managers and services switch to their secondary nodes. Processes managed under GSM will only start on nodes that are in Online mode. If a node is changed from Online to Offline, the processes on that node will be shut down and switch to a secondary node if possible.

Concurrent processing provides database instance-sensitive failover capabilities. When an instance is down, all managers connecting to it switch to a secondary middle-tier node.

However, if you prefer to handle instance failover separately from such middle-tier failover (for example, using TNS connection-time failover mechanism instead), use the profile option Concurrent:PCP Instance Check. When this profile option is set to OFF, Parallel Concurrent Processing will not provide database instance failover support; however, it will continue to provide middle-tier node failover support when a node goes down.

Defining Concurrent Managers

You define concurrent managers either in the Create New Request Processing Manager page in Oracle Applications Manager or in the Concurrent Managers form. When you define a manager, you specify the manager type, which may be either Concurrent Manager, Internal Monitor, or Transaction Manager.

There are three other types of managers that Oracle E-Business Suite predefines for you: the Internal Concurrent Manager, which describes the Internal Concurrent Manager process, the Conflict Resolution Manager, and the Scheduler. For the Conflict Resolution Manager and Scheduler you can assign the primary and secondary nodes. For the Internal Concurrent Manager you assign the primary node only.

To each concurrent manager and each Internal Monitor Process, you may assign a primary and a secondary node. You may also assign primary and secondary system queue names, if a platform-specific queue management system is available on your platform. See: Concurrent Managers.

Administering Concurrent Managers

Target Nodes

Using the Services Instances page in Oracle Applications Manager (OAM) or the Administer Concurrent Managers form, you can view the target node for each concurrent manager in a parallel concurrent processing environment. The target node is the node on which the processes associated with a concurrent manager should run. It can be the node that is explicitly defined as the concurrent manager's primary node in the Concurrent Managers window or the node assigned by the Internal Concurrent Manager.

If you have defined primary and secondary nodes for a manager, then when its primary node and ORACLE instance are available, the target node is set to the primary node. Otherwise, the target node is set to the manager's secondary node (if that node and its ORACLE instance are available). During process migration, processes migrate from their current node to the target node.

Control Across Nodes

Using the Services Instances page in Oracle Applications Manager or the Administer Concurrent Managers form, you can start, stop, abort, restart, and monitor concurrent managers and Internal Monitor Processes running on multiple nodes from any node in your parallel concurrent processing environment. You do not need to log onto a node to control concurrent processing on it. You can also terminate the Internal Concurrent Manager or any other concurrent manager from any node in your parallel concurrent processing environment.

In an environment enabled with parallel concurrent processing, primary node assignment is optional for the Internal Concurrent Manager. The Internal Concurrent Manager can be started from any of the nodes (host machines) identified as concurrent processing server enabled. In the absence of a primary node assignment for the Internal Concurrent Manager, the Internal Concurrent Manager will stay on the node (host machine) where it was started. If a primary node is assigned, the Internal Concurrent Manager will migrate to that node if it was started on a different node.

If the node on which the Internal Concurrent Manager is currently running becomes unavailable or the database instance to which it is connected to becomes unavailable, the Internal Concurrent Manager will be restarted on a alternate concurrent processing node. If no primary node is assigned, the Internal Concurrent Manager will continue to operate on the node on which it was restarted. If a primary node has been assigned to the Internal Concurrent Manager, then it will be migrated back to that node whenever both the node and the instance to which the Internal Concurrent Manager connects to from that node becomes available

Starting Up Managers

You start up parallel concurrent processing as you would ordinary concurrent processing, by running the adcmctl.sh script from the operating system prompt.

The Internal Concurrent Manager starts up on the node on which you run the adcmctl.sh script. If it has a different assigned node, it will migrate to that node if available.

After the Internal Concurrent Manager starts up, it starts all the Internal Monitor Processes and all the concurrent managers. It attempts to start Internal Monitor Processes and concurrent managers on their primary nodes, and resorts to a secondary node only if a primary node is unavailable.

Shutting Down Managers

You shut down parallel concurrent processing by issuing a "Stop" command in the OAM Service Instances page or a "Deactivate" command in the Administer Concurrent Managers form. All concurrent managers and Internal Monitor processes are shut down before the Internal Concurrent Manager shuts down.

Terminating Concurrent Processes

You can terminate running concurrent processes for a concurrent manager on the local node or on remote nodes by issuing an "Abort" command from the OAM Service Instances page or a "Terminate" command from the Administer Concurrent Managers form.

Migrating Managers

Most process migration occurs automatically in response to the failure or subsequent availability of a primary node. However, you may migrate processes manually by changing the node assignments for a concurrent manager or Internal Monitor Process using the Concurrent Managers form. To put your changes into effect, issue a "Verify" command against the Internal Concurrent Manager from the Administer Concurrent Managers form.

Related Topics

Concurrent Managers

Administer Concurrent Managers Window

View the status of your concurrent managers (including any transaction managers) and, if you wish, change the status of any manager by issuing a control command. For example, you can deactivate a manager that is currently active, then view its new status after the change takes effect.

Use the Refresh button to refresh the data shown.

Administer Concurrent Managers Block

Node

In a parallel concurrent processing environment, a manager's processes are targeted to run on this node.

If a concurrent manager is defined to use a platform-specific system queue, this field displays the name of the queue to which the manager submits its processes.

Processes Actual

Each manager process can run one concurrent request (start one concurrent program). Typically, the number of actual processes equals the number of target processes (the maximum number of requests a manager can run).

However, the number of actual processes may be less than the number of target processes due to manager deactivation or manager migration.

Processes Target

This field displays the maximum number of manager processes that can be active for this manager.

Requests Running/Requests Pending

Typically, when there are requests pending, this number should be the same as the number of actual processes. However, if there are no pending requests, or requests were just submitted, the number of requests running may be less than the number of actual processes.

Moreover, if a concurrent program is incompatible with another program currently running, it does not start until the incompatible program has completed. In this case, the number of requests running may be less than number of actual processes even when there are requests pending.

Controlling a Specific Manager - Status

This field displays the status of a manager after you have chosen a specific action for it using the top row of buttons near the bottom of the window.

You can control concurrent managers individually or collectively by controlling the Internal Concurrent Manager. This field is blank when managers have been activated by the Internal Concurrent Manager.

In a parallel processing environment, this field displays Target node/queue unavailable when the primary and secondary nodes (or system queues) are not available.

The actions you can choose for controlling a manager are:

Reviewing a Specific Manager

View details of a concurrent manager's operation

The following actions are available only for certain services managed Generic Service Management. These services must be defined to accept commands to suspend their operations.

Related Topics

Concurrent Processing Window

Defining Managers and their Work Shifts

Controlling Concurrent Managers

Overview of Parallel Concurrent Processing

Life cycle of a concurrent request, Oracle E-Business Suite System Administrator's Guide - Maintenance

Concurrent Processes Window

View status information about the processes of a specific concurrent manager, whose name and node are identified near the top of the window.

Displaying this window automatically queries all processes that are currently active, migrating, or terminating, as well as processes that have been terminated or deactivated.

Display order is by status value (Active, Migrating, Terminating, Terminated, Deactivated) and within status, by the order in which processes were started.

If you wish to reduce the number of displayed processes, you can delete records by submitting the "Purge Concurrent Request and Managers" report from the Run Requests form. You can delete records according to the number of days since the processes were started. However, you cannot delete the records of currently active managers.

Status

This field cannot be updated. The following are valid status values:

Manager Identifiers Concurrent

This field displays a number generated by the individual concurrent manager that identifies the process. This field cannot be updated.

This number may be referenced if an operating system process ID is not available.

You can use this number to view the log file associated with the process. (This is the same log file you view when you select Manager Log from the View field of the Concurrent Requests form):

• At the operating system level, locate yourself in the log directory $FND_TOP/APPLLOG.

• For concurrent managers, use w<number>.mgr.

• For Internal Monitor processes, use i<number>.mgr.

Manager Identifiers Oracle

This field displays the ORACLE process ID associated with the manager process. This field cannot be updated.

Manager Identifiers System

This field displays the operating system process ID associated with the manager process. This field cannot be updated.

Request Identifiers Running

Please note the following about this field:

• Normally this field is blank, as the run-time of a request is typically very short.

• For a terminated manager, the ID of the request being processed at the time of termination is displayed.

Request Identifiers System

This field displays the operating system process ID for a spawned concurrent process.

Viewing Log Files

Use the three buttons near the bottom of the window to view log files. Log files record information that may be helpful when diagnosing problems.

Concurrent Requests Window

View all running and pending requests for a selected manager, whose name and node are identified near the top of the window.

Request Diagnostics Window

This window informs you when the request completed or if it did not complete, shows you a diagnostic message indicating why.

Related Topics

Concurrent Manager field help

Defining Managers and their Work Shifts

Controlling Concurrent Managers

Overview of Parallel Concurrent Processing

Concurrent Managers Window

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.

Concurrent Managers Block

The combination of an application and the name you define for your manager uniquely identifies the manager.

Application

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.

Type

Once you define a concurrent manager, you cannot update this field. There are several types of managers:

Cache Size (Concurrent Manager only)

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.

Tip: 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.

Data Group (Transaction Manager only)

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.

Resource Consumer Group

The resource consumer group for the manager. For more information on resource consumer groups, see: Resource Consumer Groups in Oracle E-Business Suite.

(Parallel Concurrent Processing Details) Node

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.

(Parallel Concurrent Processing Details) System Queue

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.

Important: 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.

Program Library

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.

Defining Manager Operations

The two buttons near the bottom of the window display additional windows for defining when your manager operates, and, if you wish, specializing your manager to run only certain kinds of programs.

Work Shifts Window

Assign work shifts to a concurrent manager. A work shift defines the dates and times the manager is enabled. For each work shift you define the number of processes the manager starts running.

Work shifts are defined using the Work Shifts form. See: Work Shifts.

Processes

Enter the number of operating system processes you want your work shift to run simultaneously. Each process can run a concurrent request.

For example, if a work shift is defined with three (3) target processes, the manager can run up to three requests simultaneously.

Parameter

Enter the parameter string for a service under Generic Service Management. The value of this field is dependent on the service type definition.

These parameters are used only for managers that are services, such as the OAM Generic Collection Service, the OPP, the Workflow services, and so on. The parameters are specific to each service. For example, the OPP service uses these parameters:

oracle.apps.fnd.cp.opp.OPPServiceThread:2:0:max_threads=5 

This tells the service to use the class OPPServiceThread, use 2 service threads, and use a maximum of 5 request threads.

Sleep Seconds

Enter the sleep time for your manager during this work shift. Sleep time is the number of seconds your manager waits between checking the list of pending concurrent requests (concurrent requests waiting to be started).

Tip: Set the sleep time to be very brief during periods when the number of requests submitted is expected to be high.

Specialization Rules Window

Specialize your manager to run only certain kinds of requests. Without specialization rules, a manager accepts requests to start any concurrent program.

Include/Exclude

Select from the poplist whether or not to include or exclude those requests that are based on the rule to run.

Type

Select the type of specialization rule you want to assign to your manager. Based on the rule's action you selected, allow or disallow, requests can be run by your manager according to a:

• Combined Rule

  For example, only requests that satisfy the combined rule you select are allowed to be run by your manager. Or conversely, requests that satisfy a certain combined rule are excluded from running.

  Combined specialization rules, which combine more than one logical statement, are defined using the Combined Specialization Rules form. See: Combined Specialization Rules.

• ORACLE ID

  For example, programs with a certain ORACLE ID are excluded from running. Or conversely, a concurrent manager only includes programs with a specific ORACLE ID.

• Program

  For example, only the program you select is excluded from running. Or conversely, a concurrent manager only includes the programs you select. You can also include or exclude all programs belonging to a specific application using the Program type by entering the application in the Application field and leaving the Name field empty.

• Request Type (of the program)

  For example, programs of a certain request type are excluded from running. Or conversely, a concurrent manager only includes programs with the request type you select.

• User (application username at sign on)

  For example, all programs submitted by a certain user are excluded from running. Or conversely, a concurrent manager includes only programs submitted by the user you select.

Work Shifts Window

Use this window to name and define your concurrent manager work shifts. Define work shifts to specify when your concurrent managers can work.

For each work shift, specify a time period covering a range of days or a particular date. See: Work Shifts Definitions.

Name

The name of your concurrent work shift should be intuitive, for instance "Week Days", "Weeknights" or "Weekends".

From/To

Enter the times of day at which your concurrent shift begins/ends. The time format is HH24:MM. For example, if your work shift name is "Week Days", you could enter "09:00" (9:00 am) as the start time and "17:00" (5:00 pm) as the end time. Note that Oracle E-Business Suite uses a 24-hour clock.

Days of Week From/Days of Week To

Enter the first and last days of this shift. For instance, if your shift name is "Week Days", you could enter "Monday" in the "Days of Week From" field and "Friday" in the "Days of Week To" field. If you enter a value in the "Days of Week From" field, you must enter a value in the "Days of Week To field". You may not use the Date field for this row.

Date

Enter a date here to create a date-specific workshift. For instance, you can name a workshift "Memorial Day", and enter the date in this field to enable this workshift only on the Memorial Day holiday.

Date-specific workshifts override workshifts that do not specify a specific date. If you want to enter a value in this field (specify a date), you may not enter values for the Days of Week fields for this row. See: Overlapping Work Shifts - Priority Levels.

Related Topics

Defining Managers and their Work Shifts

Work Shift by Manager Report

Work Shifts Report

Administer Concurrent Managers field help

Concurrent Managers field help

Combined Specialization Rules Window

Define rules identifying which requests a concurrent manager can read. With the rules you define here, you may specialize the function of a concurrent manager.

Using this window, you can define several Include and Exclude statements, each referred to as a specialization line, and combine the lines into a single specialization rule referred to as a Combined Rule.

Unlike the individual rules you define using the Specialization Rules window from within the Concurrent Managers window, the combined rules you define here differ in two ways:

• You can combine Include and Exclude statements. This enables you to identify very specific requests for running concurrent programs.

• Within a combined rule, using multiple Include statements restricts a concurrent manager more.

  With individual rules you define using the Specialization Rules window (within the Concurrent Managers window), the more "Include" rules you define, the less restricted a manager becomes.

  See: Concurrent Managers

Combined Specialization Rules Block

Together, the application name and the name you define for your combined specialization rule uniquely identifies the rule.

Application

The application name does not prevent a concurrent manager from starting programs associated with other applications.

Specialization Rules Block

Define the individual rules (statements) that make up your combined specialization rule.

• Each rule in this block defines one statement.

• The sum of all the specialization rules defines your combined specialization rule.

Include/Exclude

Select from the poplist whether to include or exclude those requests that are based on the rule to run.

Type

Select the type of specialization rule you want to enforce on a concurrent manager.

You cannot combine two Include rules of the same type. For example, you cannot include programs to be associated with an ORACLE ID, then, on another line, include programs to be associated with a second, different ORACLE ID.

Based on a rule's action, exclude or include, programs can be run by your manager according to a:

• ORACLE ID

  For example, programs with a certain ORACLE ID are excluded from running. Or conversely, a concurrent manager only includes programs with a specific ORACLE ID.

• Program

  For example, only the program you select is excluded from running. Or conversely, a concurrent manager only includes the programs you select. You can also include or exclude all programs belonging to a specific application using the Program type by entering the application in the Application field and leaving the Name field empty.

• Request Type (of the program)

  For example, programs of a certain request type are excluded from running. Or conversely, a concurrent manager only includes programs with the request type you select.

• User (application username at sign on)

  For example, all programs submitted by a certain user are excluded from running. Or conversely, a concurrent manager includes only programs submitted by the user you select.

Related Topics

Specializing Managers to run only certain programs

Defining Specialization Rules

Defining Combined Specialization Rules

Using Combined Rules

Differences Between Specialization and Combined Rules

Grouping Programs by Request Type

Administer Concurrent Managers field help

Concurrent Managers field help

Concurrent Request Types Window

Use this window to identify several concurrent programs as a group by assigning each program a common request type.

You assign a request type defined here to a concurrent program using the Concurrent Programs window. Then, when you define a concurrent manager using the Define Concurrent Manager window, you can define the manager to run (Allow) or not run concurrent programs based on their request type.

For example, you could define a request type as “end-of-month reports", assign that request type to several concurrent programs, then define a concurrent manager to only run "end-of-month" requests.

Concurrent Request Types Block

Name and describe each type of concurrent request you want to define. The combination of application name plus request type uniquely identifies your concurrent request type.

This application name does not prevent you from assigning this request type to concurrent programs associated with other application names.

Related Topics

Specializing Managers to run only certain programs

Grouping Programs by Request Type

Concurrent Managers field help

Combined Specialization Rules field help

Viewer Options Window

Use this form to define the MIME types for the output formats of your concurrent requests. These MIME types are used in viewing reports.

For each file format, you can associate one or more MIME types.

A user can use one MIME type to view reports of a certain format. For example, a user can view all text format reports in Microsoft Word. The MIME types for supported formats for a particular user are set by several profile options. They are:

• Viewer: Application for HTML

• Viewer: Application for PCL

• Viewer: Application for PDF

• Viewer: Application for PostScript

• Viewer: Application for Text

This MIME type is sent to a browser window when the user views a report of that file format.

Viewer Options Block

Associate one or more MIME types with each supported file format. By defining viewer options, you can specify the application or applications that are available for displaying files of each format.

File Format

The file format.

MIME Type

The MIME type to use for the file output.

Allow Native Client Encoding

If this box is checked, the Report Viewer will convert the output file into the character set specified by the FND: Native Client Encoding profile option.

Related Topics

Defining the Reports Viewer, Oracle E-Business Suite System Administrator's Guide - Maintenance

Reviewing Requests, Request Log Files, and Report Output Files, Oracle E-Business Suite System Administrator's Guide - Maintenance

Nodes Window

A node consists of one or more processors and their associated memory. In parallel concurrent processing environments (such as cluster, massively parallel, and homogeneous networked environments) each node operates independently of other nodes except when sharing resources, such as a disk.

You can assign concurrent managers to different nodes to spread your concurrent processing workload and increase throughput. A concurrent manager runs its processes on the nodes to which it is assigned.

Nodes Block

Node

Enter the operating system name of a node.

Platform

Select the operating system platform that your node resides on.

Base Path Variable

Consult your installation manual to determine the correct base path variable for your platform to determine the location of the concurrent managers' log and out files for this node.

Related Topics

Overview of Parallel Concurrent Processing

Concurrent Managers field help

Copyright © 1994, 2010, Oracle and/or its affiliates. All rights reserved.