Skip Headers

Oracle E-Business Suite Setup Guide
Release 12.2
Part Number E22953-21
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Concurrent Processing

Overview of Concurrent Processing

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

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

Concurrent Requests, Programs, and Processes

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

Concurrent Managers start concurrent programs

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

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

Running concurrent programs

A concurrent program actually starts running based on:

Concurrent Request Priorities

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

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

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

Parent requests and Child requests

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

Recalculation of Dynamic Default Parameters in Standard Request Submission

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

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

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

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

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

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

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

Life Cycle of a Concurrent Request

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

Variable Description
Pending Request is waiting to be run
Running Request is running
Completed Request has finished
Inactive Request cannot be run

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

Concurrent Request Phases and States
Phase Status Description
PENDING Normal Request is waiting for the next available manager.
PENDING Standby Program to run request is incompatible with other program(s) currently running.
PENDING Scheduled Request is scheduled to start at a future time or date.
PENDING Waiting A child request is waiting for its Parent request to mark it ready to run. For example, a report in a report set that runs sequentially must wait for a prior report to complete.
RUNNING Normal Request is running normally.
RUNNING Paused Parent request pauses for all its child requests to complete. For example, a report set pauses for all reports in the set to complete.
RUNNING Resuming All requests submitted by the same parent request have completed running. The Parent request is waiting to be restarted.
RUNNING Terminating Running request is terminated, by selecting Terminate in the Status field of the Request Details zone.
COMPLETED Normal Request completes normally.
COMPLETED Error Request failed to complete successfully.
COMPLETED Warning Request completes with warnings. For example, a report is generated successfully but fails to print.
COMPLETED Cancelled Pending or Inactive request is cancelled, by selecting Cancel in the Status field of the Request Details zone.
COMPLETED Terminated Running request is terminated, by selecting Terminate in the Status field of the Request Details zone.
INACTIVE Disabled Program to run request is not enabled. Contact your system administrator.
INACTIVE On Hold Pending request is placed on hold, by selecting Hold in the Status field of the Request Details zone.
INACTIVE No Manager No manager is defined to run the request. Check with your system administrator.

Related Topics

Reviewing Requests, Request Log Files, and Report Output Files

How to View Request Status and Output

Setting End User Report and Log File Access Privileges

Managing Concurrent Processing Files and Tables

Service Management

An Oracle E-Business Suite system depends on a variety of services such as Concurrent Managers and Workflow Mailers. Such services are composed of one or more processes that must be kept running for the proper functioning of the applications. Previously many of these processes had to be individually started and monitored by system administrators. Management of these processes was complicated by the fact that these services could be distributed across multiple host machines. Service Management helps to greatly simplify the management of these processes by providing a fault tolerant service framework and a central management console built into Oracle Applications Manager.

Generic Service Management (GSM, or simply Service Management) is an extension of concurrent processing, which provides a powerful framework for managing processes on multiple host machines. With Service Management, virtually any application tier service can be integrated into this framework. Services such as the Oracle Workflow Mailer or Java services can be managed under Generic Service Management.

With Service Management, the Internal Concurrent Manager (ICM) manages the various service processes across multiple hosts. On each host, a Service Manager acts on behalf of the ICM, allowing the ICM to monitor and control service processes on that host. System administrators can then configure, monitor, and control services though a management console which communicates with the ICM.

Generic Service Management

the picture is described in the document text

Service Management provides a fault tolerant system. If a service process exits unexpectedly, the ICM will automatically attempt to restart the process. If a host fails, the ICM may start the affected service processes on a secondary host. The ICM itself is monitored and kept alive by Internal Monitor processes located on various hosts.

Service Management provides significant improvements in the manageability of Oracle E-Business Suite. System administrators can now use the central console in Oracle Applications Manager (OAM) to manage a variety of services that formerly had to be managed independently on separate hosts. The entire set of system services may be started or stopped with a single action. Service Management also provides a great benefit by automatically compensating for certain system failures.

Service processes are very much like concurrent manager and transaction manager processes. They must be kept running on a middle tier for the proper functioning of their respective products. The concurrent processing management feature has been built for concurrent managers and transaction managers, to provide fault tolerance, process distribution, and simplified configuration and control.

Benefits of Service Management

To extend process management support to the various Applications services, the Internal Concurrent Manager must be able to start, monitor, and control processes on all Applications tiers. Every node of every tier will have an Oracle RPC-based Service Manager installed. The ICM will use the Service Manager to manage processes.

Concepts

Service

A service is a process or collection of processes that perform actions at the request of client processes. A concurrent manager is a type of service where the client submits a request for actions to be processed while the client continues to do other work.

While active, a service must have one or more listener processes that wait to process requests from clients. An example of a listener is a concurrent manager process which periodically polls a queue for requests to process.

Service Instance

Each service controlled by service management may have multiple service instances. Each instance may consist of one or more processes.

Network Failure Recovery

As part of its shutdown process, the ICM determines if it's being forced to shutdown due to losing its database connection. This is done by looking for specific error messages ORA-3113, ORA-3114, or ORA-1041. If one of these error messages is detected, the ICM spawns the reviver process, which attempts to make a database connection. If unsuccessful, it sleeps for a period before trying again. This continues until either a successful connection is made or it receives a signal to shut itself down.

When a successful connection is made, the process kills the old ICM database session, and then starts a new ICM using the normal start manager script. Once the ICM is restarted, it starts up any other managers that had also shut down, and normal processing resumes.

Failover Sensitive Workshifts

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 processes than on the original node. This lessens the impact on the existing resources allocated on the secondary node.

The number of failover 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.

Overview of Concurrent Programs and Requests

A concurrent program is an executable file that runs simultaneously with other concurrent programs and with online operations, fully utilizing your hardware capacity. Typically, a concurrent program is a long-running, data-intensive task, such as posting a journal or generating a report.

Standard Request Submission (SRS) is an Oracle E-Business Suite feature that allows you to select and run your concurrent programs from a single, standard form (Submit Request) or window (Schedule Request). Requests to run concurrent programs are called concurrent requests.

There are two main ways to group concurrent programs. Request sets are defined to run several concurrent program in a single request. Request groups are used to control access to concurrent programs via responsibilities. Both request sets and request groups are discussed in later sections

Related Topics

Organizing Programs into Request Sets

System Administrator Request Set Privileges

Organizing Programs into Request Groups

Copying and Modifying Program Definitions

Running Reports and Programs, Oracle E-Business Suite User's Guide

Controlling Access to Concurrent Programs and Limiting Active Requests for a User

You can restrict users' access to submit and view concurrent requests.

Controlling Access to Concurrent Programs with Request Security Groups

Note: This method is used in releases prior to Release 12.

A request security group is a collection of reports or concurrent programs. A System Administrator defines request security groups in order to control user access to reports and concurrent programs. Only a System Administrator can create a request security group.

Controlling Access to Concurrent Programs using Role-Based Access Control (RBAC)

RBAC allows administrators to have more granular control in securing data related on concurrent programs and requests.

Submitting Requests

Administrators can assign individual programs/sets, all programs/sets in a request group, programs/sets belonging to one or more applications, and so on, either to the user directly or to a role that can then be assigned to one or more users. For more information on RBAC, see: Overview of Access Control with Oracle User Management, Oracle E-Business Suite Security Guide.

If applications are included in the request groups, all programs/requests sets that are created in these applications will also be automatically included. Please note that request submission applies to both programs and request sets.

The following types of "instance sets" can be used for assignment (but administrators can create new instance sets based on their needs):

To enable this functionality, the following are seeded:

To grant access to a request security group to a role, follow these steps:

  1. Define your role (User Management responsibility).

  2. Define your request security group (System Administrator responsibility).

  3. Define your grant (Functional Administrator responsibility).

    1. Enter a Name and Description (optional) for the grant.

    2. Enter the Security Context for the grant.

    3. Under Data Security, choose "Concurrent Programs" or "Request Sets" as the object. Click Next.

    4. For the Object Data Context, select "Instance Set" for the Data Context Type. Choose either "Programs that can be accessed" or Request Sets that can be accessed" as appropriate. Click Next.

    5. Review the Instance Set information. Under Instance Set Details, enter the request group and its application. Specifically, enter the request group name as Parameter 1 and the application short name as Parameter 2.

    6. Choose "Request Operations" as the permission set under "Set". Click Next.

    7. Review the grant information and save your work.

Note that there are two seeded grants for all users to account for request group assignments that already exist for legacy responsibilities. These are:

Viewing Requests

You can control users' access to viewing requests with RBAC.

Note: In previous releases, the Concurrent: Report Access Level profile was used to control privileges to report output files and log files generated by a concurrent program. This profile is no longer used.

Seeded "instance sets" allow administrators to grant:

to another user (or a group of users - via a role).

System administrators can create new "instance sets" based on their needs. They can grant access to requests (of a particular program/set) submitted by all users to a specific set of users. For example, say a given application's administrators group want to track all requests of a particular type or program submitted by business users. Then the following approach, to grant specific programs' requests to a group of users, can be used:

  1. Create an instance set that selects all the requests belonging to the particular program irrespective of which user submitted it.

    For example,

    &TABLE_ALIAS.request_id in
        ( select cr.request_id
          from fnd_concurrent_requests cr, fnd_concurrent_programs cp
          where cr.concurrent_program_id = cp.concurrent_program_id
          and cr.program_application_id = cp.application_id
          and cp.concurrent_program_name = &GRANT_ALIAS.PARAMETER1)

    If you want to grant access to a set of programs instead of a single program, '&GRANT_ALIAS.PARAMETER1' can be replaced with a subquery that returns all the programs in a particular request group.

  2. Create a grant to grant this instance set to (an existing) role, for example, "<Application> Administrator" role, and assign the program name to grant. Use the "Concurrent Requests" data object in creating this grant.

  3. Ensure that the role is assigned to all users that should have access to these requests.

Limiting Active Requests by a User

As System Administrator you can limit the number of requests that may be active (status of Running) for an individual user. This ensures that a user cannot monopolize the request queue. For example, if a user with an Active Request Limit of 5 submits 20 requests, only 5 requests will be run at the same time. The remaining requests will be run when the number of active requests for the user drops below 5. Use the Profile Options window to set the Concurrent: Active Request Limit profile. To set a global limit for all users, set this option at the site level. You can then modify limits for individual users by setting this profile option at the User level.

Organizing Programs into Request Sets

Reports and concurrent programs can be assembled into request sets.

Request sets define run and print options, and possibly, parameter values, for a collection of reports or concurrent program. End users, with the appropriate privileges, and System Administrators can define request sets. A System Administrator has request set privileges beyond those of an end user. Request sets can be run from Forms-based applications and HTML-based applications.

Request sets are a quick and convenient way to run several reports and concurrent programs with predefined print options and parameter values. Request sets group requests into stages that are submitted by the set. The order in which the stages are submitted is determined by the status of previous stages.

Request sets can also be used by a System Administrator to customize access to reports and concurrent programs. Using request sets, a System Administrator can:

As System Administrator, you have privileges beyond those of your application users, including a privileged version of the Request Set window.

Defining Request Sets

You can run the same set of concurrent requests regularly by defining a request set, and then submitting the request set from the Submit Requests form.

As System Administrator, you can include any Standard Request Submission report or concurrent program in the request sets you define. When end users define a request set, they can only select from reports and programs that belong to their responsibility's request security group.

Use the Request Set form to create and edit request sets.

Request Set Stages

This section describes how request set stages are defined and organized.

Organizing Request Sets into Stages

Request sets are divided into one or more "stages" which are linked to determine the sequence in which requests are run. Each stage consists of one or more requests that you want to run in parallel (at the same time in any order). For example, in the simplest request set structure, all requests are assigned to a single stage. This allows all of the requests to run in parallel.

Request Set with a Single Stage

the picture is described in the document text

To run requests in sequence, you assign requests to different stages, and then link the stages in the order you want the requests to run.

Request Set with a Sequence of Stages

the picture is described in the document text

The concurrent manager allows only one stage in a request set to run at a time. When one stage is complete, the following stage is submitted. A stage is not considered to be complete until all of the requests in the stage are complete.

One advantage of using stages is the ability to run several requests in parallel and then move sequentially to the next stage. This allows for a more versatile and efficient request set.

Request Set with Multiple Requests Running in Parallel within a Stage

the picture is described in the document text

Using Stage Status

Like request sets and concurrent requests, stages can complete with different statuses. Each stage can complete with a status of Success, Warning, or Error. You can use these completion statuses to structure your request set, by defining which stage will follow the current stage based on its completion status. For example: a request set always begins with Stage 1. If Stage 1 completes with the status Success, then the Success link is followed, and Stage 2 is submitted. After Stage 2 completes, the set ends. If Stage 1 completes with Warning, then the Warning link is followed, and Stage 3 is submitted. After Stage 3 completes, the set ends. If Stage 1 completes with Error, then the Error link is followed, and Stage 4 is submitted. After Stage 4 completes, the request set ends.

Request Set Using Stage Statuses

the picture is described in the document text

In this example, the stage status is determined using the Standard stage function. The Standard stage function uses the statuses of the requests within the stage to calculate the status for the stage. If all of the requests in a stage complete with a status of Success, then the status for the stage is Success. If one or more requests complete with a status of Error, then the status of the stage is Error. For a stage's status to be Warning, one or more of the requests must have a status of Warning, and no request may have a status of Error.

Linking of Stages

There are no restrictions on linking stages within a request set. Any stage may be linked to any other stage, including itself. Two or more links can point to the same stage. For example, Stage 1 can link to Stage 2 if the completion status of Stage 1 is Success or Warning, and link to Stage 3 if the status is Error.

Request Set with Multiple Links to Stages

the picture is described in the document text

You determine the end of a request set by not specifying a followup stage for each completion status. You can end a request set after any stage in the request set. When any stage completes with a status that does not link to another stage, the request set ends.

You can use the linking of stages to control your request set. In previous releases you had three options: run in parallel, run sequentially, and run sequentially but abort on Error. All of these are easy to recreate using the request set wizard. You can use the Request Set Wizard button in the Request Set window to start the wizard. The wizard takes your input and creates the request set as follows:

Variable Description
Run in Parallel Creates one stage containing all of the requests you wish to run in parallel.
Run Sequentially Creates a separate stage containing the request or requests for each step in the sequence and link in the appropriate order.
Run Sequentially but abort on Error Sets up your sequence the same as it did for Run Sequentially, but when it links the stages, it does not enter a follow up stage as a link in the Error completion status field.

Stage Evaluation Function

The completion status of a stage is determined by a predefined function. The Oracle E-Business Suite Standard Stage Evaluation function uses the completion status of the requests it contains. Use this function to determine the status of a stage.

Request Set Completion Status

When a stage completes with a status for which there is no link defined, the request set ends. The completion status for the request set is determined by one of the following methods:

Printing Request Sets

On a report-by-report basis, you can select a different printer for each report in a request set. When you define a request set, print options, such as the printer a report is sent to, are saved so you do not have to specify them again when you run the request set.

Important: If a printer is defined for a concurrent program using the Concurrent Programs form, then that value cannot be updated, either by a user profile option setting, a request set definition, or when running the program or request set.

Note: Defining a printer for a request set concurrent program (for example, Request Set Payables Aging Reports) in the Concurrent Programs form has no effect; the printer definition is not referred to.

Holding Request Sets

In some circumstances, such as when a request set has a large number of stages and takes a long time to execute, administrators may want to yield a request set to higher priority requests. By utilizing the Hold Request Set feature, users can place a running request set on hold and effectively control the execution of request set stages.

The Hold and Remove Hold buttons are available on the OAM View Running Requests page. To hold a request set, simply select the request set and click the Hold button. Click Remove Hold when you want the request set to continue executing.

Request Sets as Concurrent Programs

When you define a request set or a stage within a request set that allows incompatibilities, a concurrent program is created to run the requests in your request set according to the instructions you enter.

All concurrent programs that run request sets are titled Request Set <name of request set>, and programs that run request set stages are titled Request Set Stage <name of request set stage>. In the Concurrent Programs form, to query request set or request set stage concurrent programs on the basis of a program's name, enter the following in the Name field:

Request set and request set stage concurrent programs create log files documenting the execution of the request set or stage. Each report or concurrent program within a request set or stage also creates its own log file.

Note: The recorded actual start time for a request is the start time the request's status is changed to "Running". A request may need to wait to start until it has necessary information from child process(es).

When you run a request set that allows incompatibilities, you submit a request to run the concurrent program that defines the request set. The request set concurrent program submits a request set stage concurrent program. The request set stage concurrent program submits the requests for the individual programs and reports within the stage. A request to run the request set concurrent program or the request set stage concurrent program is a Parent request, while the requests to run the programs and reports are Child requests.

You can review the status of a request set and the programs it contains using the Concurrent Requests form. The following table displays information pertaining to request sets in the Running phase.

Statuses for Request Sets in the Running Phase
Status Description
Paused Parent request pauses for all its Child requests to complete. For example, a request set stage pauses for all reports in the stage to complete.
Resuming All requests submitted by the same Parent request have completed running. The Parent request resumes running.

Modifying Request Sets

A request set can only be modified by its owner or by a System Administrator. To make modifications, query the request set you want to modify in the Request Set window.

Note: If you wish to retain modifications to request sets provided by your Oracle application during upgrades, you must rename or recreate the request set using a different name before you upgrade. If you modify a predefined request set without changing the name, your modifications are overwritten when you upgrade your Oracle E-Business Suite.

Creating Request Sets

Follow this procedure to create a request set:

  1. Navigate to the Request Set window.

  2. Enter a Name for your request set.

  3. Enter a Set Code for your request set. This name is used internally to reference your request set.

  4. Enter the Application with which you want to associate your request set.

  5. Enter a Description of your request set if you like.

  6. The Owner field defaults to your username and can only be changed by your system administrator.

  7. Enter values for the Active Dates "From" and "To" fields to define an effective period when you and others can run the request set. If the current date is outside the range you define, the request set will not be available in the Submit Requests window. Note that the request set will not be available on the date specified in the "To" field.

  8. Check the Print Together check box to send all your requests to the printer together when they complete, or uncheck the check box to send each request one at a time to the printer as it completes.

  9. Check the Allow Incompatibility check box to allow your system administrator to specify programs that this request is incompatible with (may not run with). Leave Allow Incompatibility unchecked to specify that this request set may run with all other concurrent requests or request sets.

  10. Choose Define Stages or Link Stages if you have finished defining your stages.

Defining Stages

Follow this procedure to define stages:

  1. The value for the Display Sequence is defaulted in sequence as you enter your stages. You may change the display order of the stages by modifying this field.

  2. Enter a Name for the stage.

  3. Enter a Description of your stage if you like.

  4. Enter a Stage Code for the stage. This code is used internally to reference the stage.

  5. In the Function field of the Function region, use the List of Values to select a function. The default value for this field is the Standard Stage Evaluation function. This function bases its completion status on the normal completion status of the requests it contains. Other functions may be provided by your Oracle product. For a description of these functions, refer to the user's guide for that product.

  6. Use the "The Return Value of this Stage Affects the Set Outcome" check box if you want to ensure that the request set's completion status is equal to the completion status of this stage.

    Note: If you choose this check box for more than one stage, the completion status of the request set will equal the completion status of the last of these stages to run within the set.

  7. Use the Allow Incompatibility check box to allow your system administrator to specify programs that this stage is incompatible with (may not run with). Leave Allow Incompatibility unchecked to specify that this stage of the request set may run with all other concurrent requests or request sets.

  8. Choose Requests.

Stage Requests Window

In the Stage Requests window you define which requests you want to include in the stage.

  1. Select the report or program you want to include in your request set. A description of the request you choose and its associated application appears in the Description and Application fields.

    The list of requests you can choose includes the requests that your responsibility's request group lets you access from the Submit Requests form.

  2. Use the Allow Stage Function to Use This Program's Results check box to indicate which programs or reports should be included.

  3. The Print Options region reflects the options for the current request. Specify the number of Copies of output to print, the Style to print, the Printer to print to, and whether to save the output to an operating system file.

    Standard Request Submission saves these options so you do not have to specify them again when you run the request set. If you do not wish to specify these options for each request when you define the set, Standard Request Submission uses the values of your personal profile options as the default when you submit the request set. See: Concurrent Processing User Profile Settings, Oracle E-Business Suite Maintenance Guide.

    Note: Some requests may have a required Style or Printer that you cannot change.

  4. When you are done with the Print Options, choose Parameters to display the Request Parameters window.

Request Parameters Window

The Request Parameters window lets you customize the parameter values of a specific request in a request set. The fields at the top of the Request Parameters window list general information about the current request set and the request for which you can customize the parameter values. The multi-row portion of the window lists the parameters for that request.

  1. The Sequence field displays the order in which each request parameter appears when you run the request in the Submit Requests window (lower numbers appear before higher numbers). Only your system administrator can change a parameter's order.

  2. The Prompt field is a display-only field that shows the request parameter's prompt.

  3. Check the Display check box to specify that you can see a request parameter at submission time, or uncheck the check box to specify that a parameter should not be displayed at submission time.

  4. Check the Modify check box to specify that you can insert or change the value for a request parameter at submission time, or uncheck the check box to specify that a parameter cannot be changed at submission time.

  5. Use the Shared Parameter field to set a default value for a parameter that occurs in more than one report or program of a request set. Once you enter the same parameter label in the Shared Parameter field for each occurrence of the same parameter, the value that you assign to the first occurrence of the parameter becomes the default value for all subsequent occurrences of the parameter. The shared parameter label simply enables you to set an initial default value for all occurrences of the same parameter so you can avoid typing the same value all over again for every occurrence of the parameter.

    For example, suppose you define a request set that includes three reports, and all reports include a parameter called “Set of Books". You want the “Set of Books" parameter to default to the same value in all reports. To accomplish this, enter a label called “Book" in the Shared Parameter field for the first occurrence of this parameter. You can also assign a value in the Default Value field of this parameter now, or wait until you run the request set to assign a default value when the parameter first appears. Enter the label “Book" in the Shared Parameter field of all other occurrences of the “Set of Books" parameter in your request set. When you submit this request set from the Submit Requests window, every parameter that you label “Book" defaults to the value you assign to the first occurrence of the “Set of Books" parameter.

    Important: Note that if you later change the value of a parameter that contains a shared parameter label, you change only the value for that instance of the parameter, and not the value for all other occurrences of that labelled parameter.

    We recommend that if you make a parameter with a shared parameter label modifiable, that you also display the parameter so you can always see what the parameter's current value is. This helps reinforce the understanding that a later value change to one labelled parameter cannot propagate a value change to all other similarly labelled parameters.

  6. Optionally enter a Default Type and Value for the parameter.

  7. Save your work.

  8. Go back to the Stage Requests window and repeat Steps 9 through 11 to add more requests to the request set stage.

    You can select a request more than once if you want to run the same request with different default parameter values.

  9. To start a new stage, return to the Stage window and choose New Record from the File Menu.

Linking Stages

Follow this procedure to link stages:

  1. Enter the Start Stage. The stage you enter here is the first stage submitted for the request set.

  2. Enter the stages you want to run following the first stage in the Success, Warning, and Error columns. To ensure that a particular stage follows the preceding stage regardless of the completion status, enter the desired stage in all three columns. To stop the request set if a stage ends in Error, leave the Error column blank. Any time you do not specifically indicate which stage should follow for a completion status, the request set will exit on that completion status.

    In the example shown in the table below, the request set will always exit if any stage returns a completion status of error. In addition, stages C and D will terminate the request set regardless of their completion status. If Stage A returns a status other than Error, Stage B will be submitted. Finally, when Stage B completes with a status of Success, it is followed by Stage C, or if the status is Warning, Stage D will follow.

  3. Choose Done.

The following table shows an example of linking stages as in step 2 above:

Example of Linking Stages for a Request Set
Display Sequence Name Success Warning Error
1 Stage-A Stage-B Stage-B  
2 Stage-B Stage-C Stage-D  
3 Stage-C  
4 Stage-D  

Restarting Request Sets

If a request set completes with a status of Error, the Restart button, on the Oracle Applications Manager - View Completed Requests page is enabled. The system also automatically captures, records, and saves the information of the first stage that fails so that when the user clicks on the Restart button the request set can restart from that point.

Once the stage has been identified, the request set program submits the stage program in resubmit mode. In this mode, the program looks at the same stage from the previous run and determines which programs need to be rerun, (only those that ended in error), and runs those programs. If this stage completes successfully or has a Warning status, the system proceeds to the next stage using the normal mechanism of restarting the request set program.

Note: Users may restart a request set multiple times. The logs for each stage and individual programs are maintained independent of the number of runs as each stage and program submission generates a new request. However, the logs and associated files for a request set are rewritten each time the set is restarted.

Related Topics

Overview of Concurrent Programs and Requests

Request Sets and Owners

There are significant differences between end user and System Administrator privileges when defining or editing request sets.

End users own the request sets they create

An end user can create a request set by selecting reports, other request sets, or concurrent programs that are part of the report security group assigned to his or her responsibility.

When an end user creates a request set, the user automatically becomes the “owner" of the request set. Ownership is identified by the person's application username.

End users use the Request Set form to create a new request set, or to query and update any request sets they own. End users can only edit request sets they own.

We sometimes refer to a request set that an end user owns as a private request set. Private request sets are not automatically added to a request security group. That is, other users cannot access your private request sets using the Submit Requests window unless the System Administrator assigns that request set to a request security group.

Request sets owned by an end user are always available to that user, regardless of what responsibility the user is operating under. However, a standard submission form customized to display only reports in a request group using a code does not display private request sets.

When a user signs on to Oracle E-Business Suite, the user can run requests, request sets, and concurrent programs included in:

End User Benefits from Private Request Sets

Private request sets offer two main benefits to end users:

  1. The request sets that users own are always available to them, regardless of which responsibility they are working under.

  2. Users can create as many request sets as they want without adding request set choices to the list of standard submission concurrent programs that other users must select from.

System Administrator Request Set Privileges

As System Administrator, you can:

After you define a request set, you can assign a user to be its owner if you want the user to be able to run or edit this request set from any responsibility. Request sets without an owner cannot be edited or updated by any end users. In this way, you can guarantee print options and report parameters for a request set. You can also later edit the request set to remove or change its ownership properties.

Other users can also run a request set if you, as System Administrator, assign the request set to their responsibility's request security group. If you do not assign a request set to a request security group, then only the owner can run the request set. In this way, you can grant access to reports and concurrent programs on a user-by-user basis.

Request Security Groups, Request Sets, and Reports

As System Administrator you can add any request set, including private request sets, to a request security group. This allows you to provide members of a responsibility access to reports and programs outside their request security group.

Request set editing and report viewing privileges are different for reports that belong to a user's request security group than they are for reports that are not in the user's request security group.

System Administrator Benefits from Request Sets

Request sets offer three main benefits to System Administrators:

  1. Request sets offer a means of controlling access to concurrent programs on a user-by-user basis.

    By defining a request set, assigning it an owner, and then not assigning the request set to any request security group, the reports and programs in the request set are only available to the owner.

  2. By leaving the Owner field blank, System Administrators can create request sets whose individual programs and parameters cannot be edited or updated by end users.

    Only a System Administrator can edit a request set that has no owner.

  3. System Administrators can provide members of a responsibility access to reports and programs outside their request security group.

    By defining a request set that contains reports or programs not in a request security group, and assigning that request set to the request security group, users can be granted run, but not edit privileges for selected reports or programs.

Request Set Incompatibilities

A request set is actually a concurrent program that submits requests to run each program in the request set. You can allow incompatibility rules to govern your request set so that the request set does not run at the same time as other reports or concurrent programs. You can also apply these rules to the stages that make up the request set.

Use the Concurrent Programs form to query the request set concurrent program and list those programs, and/or stages you want to define as incompatible with your request set. See: Concurrent Programs.

All concurrent programs that run request sets are titled Request Set <name of request set>. In the Concurrent Programs form, if you query a request set concurrent program on the basis of the program's name, you must enter in the Name field the words:

"Request Set" before the name of a concurrent program

"Request Set %" to perform a query on all request set programs

When you list a program as incompatible with your request set, the program will not run simultaneously within the same conflict domain as the request set or any of the reports within the set. See: Defining Program Incompatibility Rules.

Related Topics

Overview of Concurrent Programs and Requests

Defining Program Incompatibility Rules

Concurrent Programs

Sharing Parameters in a Request Set

Parameters, also referred to as arguments, are values that define aspects of a program's execution. You can share a parameter and its entered value among some or all of the requests in your request set.

You identify a parameter as shared by giving it a label. Then, for each concurrent program in your request set, you can assign the same label to a parameter for that program. Among the programs in your request set, the parameters for each program share or accept a common value.

The first time you enter a value for any of the shared parameters, that value becomes the shared parameter's value. This is useful, because you only have to enter a value once, rather than for each program in the request set.

Behavior of Shared Parameters

Selecting a value for a shared parameter provides a default for subsequent occurrences of the parameter. Changing a shared parameter's value provides a new default for subsequent occurrences of the parameter, but does not affect prior requests in the set.

Once all the shared parameters contain values, changing the value for a shared parameter has no effect on the other shared parameters.

Important: Do not hide shared parameters. Do not set shared parameters to Display = No (which prevents modifying the value) or Modify = No. This prevents updates to shared parameters, which are not propagated to other reports in the set, from generating unwanted inconsistencies.

Example - Shared Parameter Value

We've created a request set containing two reports, a Concurrent Programs Report and the Concurrent Program Details Report. The two reports and their parameters are listed in the table below:

Example of Two Reports with Their Parameters
REPORT PARAMETERS
Concurrent Programs Report Application Name
Concurrent Program Detail Report Application Name, Program

We identify the parameter Application Name as a parameter shared between the two reports. We want to enter a value only once, that is, when the Report Parameters window appears for the first report in the set, requiring us to enter Application Name.

To identify a shared parameter, we give it a name, in this example, applname, and enter it as a Shared Parameter for each report.

First Example Report with a Shared Parameter

the picture is described in the document text

Second Example Report with a Shared Parameter

the picture is described in the document text

Related Topics

Overview of Concurrent Programs and Requests

Control the Behavior of Request Parameters

Concurrent Programs

Request Sets Report

This report documents request set definitions, including the set's owner, program incompatibilities, as well as printer and print style information. Use this report when defining or editing request set definitions.

Report Parameters

None.

Report Headings

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

Related Topics

Overview of Concurrent Programs and Requests

Organizing Programs into Request Sets

Concurrent Programs Report

Organizing Programs into Request Groups

This essay explains how you can organize your applications programs and reports into request groups. It presents the following topics:

Defining a Request Group

When defining a request group, you can include:

Two Types of Request Groups

A request group is used by Oracle E-Business Suite at two different levels:

  1. Responsibility level

    When a request group is assigned to a responsibility, it is referred to as a request security group, and it defines the reports, request sets, and concurrent programs that a user, operating under that responsibility, can select from the Submit Requests Window.

  2. Form level

    When a request group is assigned a code, that code can be passed as a parameter to the Submit Requests Window. The code helps define the function that calls the Submit Requests Window.

    The list of values for that unique Submit Requests Window lists the reports, request sets, and concurrent programs in the request group.

Request Security Groups

When a request group is assigned to a responsibility, the request group is referred to as a request security group. Any user signed on under a responsibility can run the reports and concurrent programs contained in their responsibility's request security group.

The Submit Requests standard submission form displays a list of all the reports and programs in the current responsibility's request security group.

Related Topics

Using Codes with Request Groups

Customizing the Submit Requests Window using Codes

Report Group Responsibilities Report

Request Groups

Using Codes with Request Groups

Normally, when a menu calls the standard request submission form, that form can list the reports and concurrent programs contained in the report security group for the current responsibility.

Alternatively, you can assign a code to a request group so that a customized standard submission form only displays a list of concurrent programs contained in that particular request group. A request group code is simply an argument that is passed from a menu to a customized standard submission form. To summarize:

Related Topics

Organizing Programs into Request Groups

Customizing the Submit Requests Window

Customizing the Submit Requests Window using Codes

Request Groups

Customizing the Submit Requests Window

You can customize the Submit Request window in several ways.

Rename the Window Title

You can change the title to reflect the requests available in the window. See: Customizing the Submit Requests Window using Codes.

Restrict Requests Available to A Request Group

You can restrict the reports and programs available to those in a specified request group. See: Customizing the Submit Requests Window using Codes.

Restrict Requests to a Single Request

You can call Submit Requests form for a single request submission by passing the program/set name as parameters

The parameters window pops up on navigation to the form when called with a program/report_set name. The form exits after the user acknowledges the displayed request ID for the submitted request.

Restrict Requests To A List of Requests

You can call Submit Requests form to submit one or more requests for a single program/set by passing the program/set name as parameters

The parameters window pops up on navigation to the form and the user can submit one or more requests for the program that was passed as a parameter. Requests for other programs cannnot be submitted in this case.

Pass Parameters Used in Value Set Parameters

You can pass additional parameters to the Submit Requests form that can be referenced in the value sets to validate the request parameters.

Pass Manufacturing "ORG" Parameters

You can pass 5 ORG related parameters and refer to them in the value set. Alternatively, you can bring up a ORG LOV on navigation to the Submit Requests form that populates the ORG parameters which can be referenced in the value sets.

Complete List of All Submit Request Parameters

Below is the comprehensive list of parameters supported by the "Run Requests"/SRS form and additional information about their usage.

Customizing the Submit Requests Window using Codes

You can give the Submit Requests Window a different title, and define the form so that it allows users to select only those reports or concurrent programs belonging to a request group that you have assigned a code to. To do this, you register a form function that references the Submit Requests Window, and you pass certain arguments to the function. Then you construct your menu to include this form function. For more information, see Oracle E-Business Suite System Security Guide.

Using a Request Group Code as an Argument

The following table describes the parameters passed to associate a request group with the Submit Requests Window and to customize the title of that form. Text is entered in the Parameters field of the Form Functions form.

Examples of Parameters to Use in Customizing the Submit Requests Window
Parameter Syntax followed by Example Explanation
REQUEST_GROUP_CODE ="Request Group Code" REQUEST_GROUP_CODE = "OE_CONC_PROGRAMS" This parameter passes the request group's code. (Required)
REQUEST_GROUP_APPL_SHORT_NAME = "Application short name" REQUEST_GROUP_APPL_SHORT_NAME = "OE" This parameter identifies the short name for the application associated with the request group. (Required)
TITLE ="Application_short_name:Message_Name" TITLE = "FND:SRS_NEWTITLE" This parameter identifies a message whose contents define the title, as well as the application short name of that message. (Optional)
LOOKUP = "Y|N" LOOKUP = "Y" This parameter indicates whether the TITLE parameter is a message name or a hardcoded string. The default value is "Y", which indicates that TITLE is a message name. (Optional)

Related Topics

Customizing the Submit Requests Window

Organizing Programs into Request Groups

Using Codes with Request Groups

Report Group Responsibilities Report

Request Groups

Report Group Responsibilities Report

This report lists those responsibilities which have access to a report or a request set. Use this report when granting access privileges to reports and request sets, either by assigning reports and request sets to request security groups, or when assigning owners to a request set.

Report Parameters

Application Name

Choose the application name associated with the report or request set.

Report Name/Request Set Name

Either choose the name of a report or request set.

Related Topics

Overview of Concurrent Programs and Requests

Organizing Programs into Request Groups

Request Groups

Defining Program Incompatibility Rules

This essay explains how you can define incompatibility rules for your concurrent programs and reports.

Incompatible and Run Alone Programs

When a concurrent program is incompatible with another program, the two programs cannot access or update the same data simultaneously.

When you define a concurrent program, you can list those programs you want it to be incompatible with. You can also list the program as incompatible with itself, which means that two instances of the program cannot run simultaneously.

You can also make a program incompatible with all other concurrent programs by defining the program to be run-alone.

There are two types of program incompatibilities, "Global" incompatibilities, and "Domain-specific" incompatibilities.

You can define a concurrent program to be globally incompatible with another program -- that is, the two programs cannot be run simultaneously at all; or you can define a concurrent program to be incompatible with another program in a Conflict Domain. Conflict domains are abstract representations of groups of data. They can correspond to other group identifiers, such as sets of books, or they can be arbitrary.

You define a concurrent program to be run-alone or to be incompatible with specific concurrent programs by editing the concurrent program's definition using the Concurrent Programs window. See: Concurrent Programs.

Program incompatibility and run-alone program definitions are enforced by the Conflict Resolution Manager (CRM).

The two user-level constraints, set by the Concurrent:Active Request Limit and Concurrent:Sequential Requests profile options, are now enforced globally across all conflict domains.

Request Sets - Incompatibilities Allowed

When you define a request set or request set stage that allows incompatabilities, you create a concurrent program that runs the reports in your request set or stage according to the instructions you entered. Using the Concurrent Programs window, when you list programs as incompatible with a request set, those programs are prevented from starting until all the reports in the set or stage have completed running.

To define incompatibility rules for a request set and request set stage:

All concurrent programs that run request sets are titled Request Set <name of request set> while all concurrent programs that run request set stages are titled Request Set Stage <name of stage>-Request Set <name of request set>. In the Concurrent Programs form, if you query a request set or stage concurrent program on the basis of the program's name, you must enter in the Name field the words:

Related Topics

Overview of Concurrent Programs and Requests

Request Set Incompatibilities

Modifying an Incompatible Programs list

Data Groups

Concurrent Programs

Concurrent Conflict Domains

If two programs are defined as incompatible with one another, the data these programs cannot access simultaneously must also be identified.

In other words, to prevent two programs from concurrently accessing or updating the same data, you have to know where, in terms of data, they are incompatible. A Conflict Domain identifies the data where two incompatible programs cannot run simultaneously.

Conflict Domains

In Oracle E-Business Suite, data is stored in database tables that belong to a particular application. Each table may also contain information used to determine what conditions need to be met to access the individual records. These conditions may consist of one or more of the following data groupings:

A conflict domain is an abstract representation of the groupings used to partition your data. There is no limit to the number of domains that can be defined, but excessive domains may hurt performance.

All programs are assigned a conflict domain when they are submitted. If a domain is defined as part of a parameter the concurrent manager will use it to resolve incompatibilities. If the domain is not defined by a parameter the concurrent manager uses the value defined for the profile option Concurrent:Conflicts Domain. Lastly, if the domain is not provided by a program parameter and the Concurrent:Conflicts Domain profile option has not been defined the 'Standard' domain is used. The Standard domain is the default for all requests.

All programs use the Standard conflict domain unless a value is defined for the profile option Concurrent:Conflicts Domain or a conflict domain is defined through a program parameter.

Each request submitted uses parameters which identify the records that it will access. For programs that are defined with incompatability rules an additional parameter (conflict domain parameter) is used. The conflict domain may be set automatically based on such variables as a login ID, set of books, or the organization the user is working in. The conflict domain parameter may in some cases be selected in the parameters field of the Submit Requests form. Once the parameter is determined the Conflict Resolution Manager (CRM) uses the domain to ensure that incompatible programs do not run simultaneously in the same domain.

Enforcing Incompatibility Rules

Concurrent managers read requests to start concurrent programs running. The Conflict Resolution Manager checks concurrent program definitions for incompatibility rules.

If a program is identified as Run Alone, then the Conflict Resolution Manager prevents the concurrent managers from starting other programs in the same conflict domain.

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

The figures below illustrate the role of the Conflict Resolution Manager when enforcing program incompatibility rules.

In a simple example without incompatibilities, a user submits a request to run a program. This request is then added to the request table which contains a list of requests. Managers then read requests from this table and start the associated concurrent programs.

A more complex example users may have submitted one request with incompatibility rules and another request to run a program that must be run alone. In this case these requests are added to the request table, but the Conflict Resolution Manager then checks the statuses of the requests in the table and marks which requests are ready to be run. The concurrent managers then read only the "ready" requests and start their concurrent programs.

Simple Run Program Request

the picture is described in the document text

Complex Run Program Request

the picture is described in the document text

Related Topics

Overview of Concurrent Programs and Requests

Copying and Modifying Program Definitions

Modifying an Incompatible Programs list

Concurrent Programs

Log and Output File Names and Locations

Log and output files must have specific names and locations for users to review the files online.

For custom concurrent programs discussed later, if you use the Oracle Application Object Library routine fdpwrt() to write to files, the concurrent managers automatically name the files according to the operating system's naming conventions. This method of writing to files is completely portable. You do not have to rewrite your programs to name your log and output files differently if you port your application to another platform.

Standard Names

Standard names for log and output files are listed in the following table:

Standard Names for Log and Output Files
File Type File Name
Log l<request ID>.req
Output Default: <USERNAME>.<request ID> or O<request ID>.out or user.out based on value of APPCPNAM

The variable parameters shown in this table have the following values:

On UNIX platforms, the filenaming works as described in the following table:

Filenames on UNIX
APPCPNAM Variable Assignment in UNIX Output File Format
APPCPNAM = "REQID" o999999.out
APPCPNAM = "USER" <Applications user>.out
APPCPNAM = "USER.REQID" <Applications user>.999999
(unset or unrecognized syntax) o999999.out

In the above table, <Applications user> refers to an Oracle E-Business Suite user name and '999999' stands for a concurrent request ID.

On Windows platforms, the default format is o<request ID>.out. Setting APPCPNAM to USER on a Windows platform results in the output files having the format <user ID>.out.

File Locations

Beginning with Release 12.2.6, Oracle E-Business Suite provides a choice of storage strategies for management of large numbers of concurrent processing log and output files. Customers can specify the strategy that best suits their particular needs. These strategies are called schemes.

All log and output files are kept under $APPLCSF. Regardless of the scheme chosen, $APPLCSF will always be the top level directory.

The scheme is determined by the $APPLLDM environment variable. Before Release 12.2.6, this variable had two settings: 'single' and 'product'. These two schemes remain valid and 'single' is still the default scheme.

If $APPLLDM is unset, the managers will default to using 'single'. When $APPLLDM is defined but invalid, request log/output files will go to $APPLCSF/log|out, and manager logs will go to $APPLCSF/system/log.

The value of $APPLLDM can be changed in the standard way or using the cpadmin utility. All managers must be shut down before changing the value of $APPLLDM.

Because there is typically not the same volume of manager log files as there are request log files/output files, manager logs will not be kept with request log files; rather, they will be kept in the $APPLCSF/system/log directory. This strategy is identical to the 'product' scheme. The exception to this rule is the 'single' scheme. If this scheme is used, all manager logs will still be kept in $APPLCSF/log (unchanged from earlier releases).

In regard to purging, the purge program, "Purge Concurrent Request and/or Manager Data" (FNDCPPUR), will purge files no matter what their location is. Using a scheme that involves creating new directories may leave empty directories around after running a purge. You should clean up these directories after running a purge.

Note: Files will not be rotated or moved once they are created.

Scheme names and parameters

SCHEME = single

This is the default scheme. This scheme takes no parameters. Request log files will go into $APPLCSF/logand log files will go into $APPLCSF/out. Manager logs will go into $APPLCSF/log directory. These directories must exist before starting managers.

SCHEME = product

This scheme takes no parameters. Request log and out files will go to$APPLCSF/<product short name>/log and $APPLCSF/<product short name>/out, respectively. Manager logs will go into the $APPLCSF/system/log directory. These directories must exist before starting managers.

SCHEME = user

Takes no parameters. Requests log and out files will go to $APPLCSF/<user name>/log and $APPLCSF/<user name>/out, respectively. Manager logs will go into the $APPLCSF/system/log directory. User name directories need not exist when starting managers.

SCHEME = date

date:<string> (required)  

This scheme takes a string as a required parameter.

Valid values are same as C function strftime() with following exceptions.

  1. Resulting string must not include special characters, spaces, wild cards, or directory delimiters such as /and \. The characters . and .. are also prohibited.

  2. Resulting string must only create one level of directory Therefore, a string such as %Y/%m/%d is invalid whereas %Y-%m-%d is valid. It will result in directory 2016-01-25, for example.

Requests log and out files will go to $APPLCSF/<resulting string>/log and $APPLCSF/<resulting string>/out, respectively. Manager logs will go to the $APPLCSF/system/log directory. Date directories need not exist when starting managers.

SCHEME = reqidexp

reqidexp:<integer> (required)  

This scheme takes an integer value for a parameter. Valid values are all positive integers; however, reasonableness of that figure must be assured by the user. Zero is a valid value; however, every request will be placed on its own directory making it meaningless in most cases.

Consider this formula:

result = int(request_id / 10^(parameter)) * 10^(parameter)   

If argument is 1, request 12345 will be placed in 12340

If argument is 2, request 12345 will be placed in 12300

If argument is 3, request 12345 will be placed in 12000

Requests log and out files will go to $APPLCSF/<resulting string>/log and $APPLCSF/<resulting string>/out, respectively. Manager logs will go to $APPLCSF/system/log directory. These derived directories need not exist when starting managers.

SCHEME = reqidmod

reqidmod:<integer> (required)  

This scheme takes an integer value for a parameter. Valid values are all positive integers except for zero. Using 1 is meaningless in most cases as it will only create one directory. The value must also be reasonable; see below.

Managers will create specified n number of directories starting with 0 (zero) and continue with other numbers in sequential order. Then, each manager process will perform the following function to determine log and output location.

result = request_id mod <parameter>   

If argument is 1, directory 0 will be created. Request 12345 will be placed in this directory.

If argument is 2, directories 0 and 1 will be created. request 12345 will be placed in directory 1. This scheme will result in directory 0 for even numbered request_ids and 1 for odd numbered request_ids.

If argument is 3, directories 0, 1, and 2 will be created. Request 12345 will be placed in directory 0, 12346 will be placed in directory 1, and 12347 will be placed in 2. Using large number will result in large number of directories.

Using numbers larger than current request_id will result in having one directory for each result and empty directories.

Requests log and out files will go to $APPLCSF/<resulting string>/log and $APPLCSF/<resulting string>/out, respectively. Manager logs will go to $APPLCSF/system/log directory. These derived directories need not exist when starting managers.

SCHEME = requidn

This scheme takes a positive integer value for a parameter, N. Directories are created on an as-needed basis, in which the maximum number of files in a directory is N. For example, if the first request ID is 123456 and N is 1000, then the first directory will be named '123000'. Requests 123456 through 123999 will go into this directory, and then directory '124000' is created. Requests 124000 through 124999 will go into this directory '124000', and so on. If a request creates more than one output file (for example, in publishing), then N may be exceeded. The directories for request log and out files are $APPLCSF/<string determined by N>/log and $APPLCSF/<string determined by N>/out, respectively.

SCHEME = mgrproc

This scheme takes no parameters.

Requests log and out files will go into $APPLCSF/<manager's process ID>/log and $APPLECSF/<manager's process ID>/out, respectively. Therefore, each manager's process will have its own directory. Please note that the manager's process ID is not the UNIX PID or other operating system derived numbers. It refers to process ID generated when the manager was started. This number is represented as Manager ID in the Administer Concurrent Managers > Processes window, and is also used as part of the manager's log file names.

Manager logs will go to $APPLCSF/system/log directory. The derived directories need not exist when starting managers.

SCHEME = orgid

Takes no parameters. Request log and out files will go to $APPLCSF/org_id/log and $APPLCSF/org_id/out, respectively. If there is no org_id for the request (org_id = NULL), then the files will go into a directory called 'no_org'. Manager logs will go into the $APPLCSF/system/log directory. The org_id directories need not exist when starting managers.

Custom Concurrent Programs

This section provides information for system administrators on custom concurrent programs. It explains certain procedures and conventions for creating customized concurrent programs:

For information on creating custom concurrent programs, see the Oracle E-Business Suite Developer's Guide.

For information on setting up the development environment , see the Oracle E-Business Suite Concepts Guide.

Oracle Tool Concurrent Programs

If you write concurrent programs in PL/SQL, SQL*Plus, or Oracle Reports, name the program exactly as you identified it in the Execution File field of the Concurrent Program Executable window, plus an extension if necessary.

The following table lists the file extensions used for these programs and the directories where the programs should reside. (This does not apply to PL/SQL stored procedures, which are stored in the database.) The directories are under your custom application's TOP directory, $<PROD>_TOP.

If you use shared PL/SQL libraries with your Oracle Reports programs, and you want to include the libraries you write for your custom application, place the libraries in the $APPLPLS directory under your custom application's TOP directory.

Oracle Tools for Concurrent Programs and Their File Extensions and Directories
Tool Extension Directory Comments
SQL*Plus and PL/SQL .sql $APPLSQL The program name is case sensitive and must exactly match the Execution file you defined with Oracle Application Object Library.
Oracle Reports .rdf $APPLREP Oracle Application Object Library looks for the .rdf file first. It uses the .rex file if it does not find the .rdf file. The program name is case sensitive and must exactly match the execution file name you defined with Oracle Application Object Library.
SQL*Loader .ctl $APPLBIN

Pro*C Concurrent Programs

When you write a concurrent program in Pro*C, copy the skeleton programs EXMAIN.c and EXPROG.c from the directory $FND_TOP/$APPLUSR. Rename the files and globally replace SUBROUTINE_NAME with the name of your subroutine.

EXMAIN.c is the skeleton used for your spawned programs. EXPROG.c is the skeleton used for your program's logic. This module can be used to create a spawned or an immediate program. For immediate programs, you must include your copy of EXPROG.c in a program library. See below for information on building a program library.

You can use programs written with these skeleton programs as spawned or immediate concurrent programs. Spawned programs run as a separate process while immediate programs run linked in with a concurrent manager.

Important: Oracle provides information on immediate concurrent programs for backwards compatibility only. We strongly recommend that you do not create any new immediate concurrent programs. You should define your new Pro*C concurrent program executables as spawned.

Naming Your Executable File

Name your program's executable file exactly as you identified it in the Execution File field of the Concurrent Program Executable window. Put your executable file in the $APPLBIN directory under your application's TOP directory.

Building Your Program Library

Register a new program library with the Register Concurrent Program Library form and register all the programs you want to include in this library. Then enter "Yes" in the Rebuild field and commit. This creates a request to build a new catalog file called <Library Name>.c under $<PROD>_TOP/$APPLLIB$ . You should compile the <Library Name>.c file after the request completes.

Sample program libraries such as prgcat.c and prglib.c are located under $FND_TOP/$APPLUSR.

Tip: For ease of maintenance, define your concurrent program executables as spawned.

Compiling C and Pro*C Programs

Your environment for compiling custom code depends on the file $FND_TOP/usrxit/devenv.env. If you change this file, you should reread it by logging in again so that the changes take effect.

You compile your C or Pro*C programs into object modules using $FND_TOP/usrxit/Makefile. You then link your programs using adrelink. We do not support both compiling and linking executables using a single makefile or utility.

To compile the C program example.c, use the following syntax. In all the examples, you should run the commands from the directory in which your files are located.

$ make -f $FND_TOP/usrxit/Makefile example.o

To compile the Pro*C program proexamp.pc, use the following syntax:

$ make -f $FND_TOP/usrxit/Makefile proexamp.o

To compile the four C and Pro*C programs a.c, b.c, c.pc, d.pc (all of which are in the current directory), use the following syntax:

$ make -f $FND_TOP/usrxit/Makefile a.o b.o c.o d.o

Linking Spawned Concurrent Programs as Stand-alone Programs

If you want your spawned concurrent program to run as a stand-alone program, perform the following steps before compiling your stand-alone executable.

For custom concurrent programs you define under your custom application (as recommended), you should copy the sample.mk file from $FND_TOP/usrxit to your $<PROD>_TOP/$APPLLIB directory. Modify your copy according to the instructions contained in the file. This is the file adrelink uses to link your stand-alone executables.

Then enter the following commands.

$ . $FND_TOP/fndenv

Move to the directory in which your source files are kept.

$ cd <source_directory> 
$ make -f $FND_TOP/$APPLLIB/Makefile <source file>.o

Here, <source file> is the name of the file containing your program and <directory> is the directory where the source file is located.

You can then link your stand-alone executable and place the executable in the $APPLBIN directory under the TOP directory for your custom application:

$ adrelink force=y "<appl_short_name> <program name>"

In this relink command, <appl_short_name> is the application short name of the application your program belongs to, and <program name> is the program name.

Linking your Immediate Concurrent Program

To create a program library, you link your compiled library catalog with your program object files using an Oracle Application Object Library link procedure.

Important: Oracle provides information on immediate concurrent programs for backwards compatibility only. We strongly recommend that you do not create any new immediate concurrent programs. You should define your new Pro*C concurrent program executables as spawned.

Make sure the environment variable $LUSRLIB includes the modules that define the functions for the immediate concurrent programs and your program library. Set the $LUSRPRG variable to include the object modules of your library catalog. The file devenv in the directory $FND_TOP/$APPLUSR defines the variables $LUSRLIB and $LUSRPRG. The file fndenv executes devenv.

The files devenv and fndenv are UNIX shell scripts that set up the necessary environment variables.

We recommend that you make a copy of the working program library before linking your new immediate concurrent program library in case your new program library does not function as expected. To link your program library, execute this command from the operating system:

$ adrelink force=y "fnd UFNDLIBR"

This creates your new program library as UFNDLIBR. You can rename it, but the name of your new program library must be eight characters or less.

Testing Pro*C Concurrent Programs

You can use the following method to test your program. You must pass each argument needed by your program. To pass parameters, enter the following at the operating system prompt:

 $ <program name> <ORACLE username>/<ORACLE password> 0 Y \
[<parameter 1> <parameter 2>... ]

Instead of the Oracle username and password, you can use an Oracle E-Business Suite username and password, if the corresponding user has the System Administrator responsibility.

The program name must be uppercase and the same name that you entered in the Execution File field of the Concurrent Program Executable window. The 0 and Y arguments are required.

If any of your program-specific parameters includes spaces, enclose that parameter in double quotes. If a parameter contains a literal double quote, precede that mark with a backslash [\].

Host Language Concurrent Programs

Name your program <name>.prog, where <name> is the value you enter in the Execution File field of the Concurrent Executable window. Then make a symbolic link using your execution file name (without an extension) to fndcpesr , which is located in the $FND_TOP/$APPLBIN directory. Put your executable file and the linked file in the $APPLBIN directory under your application's TOP directory.

For example, name your custom shell script CUSTOM.prog. Create a symbolic link to fndcpesr named CUSTOM. Place both files in your $APPLBIN directory. Create your concurrent program executable using the execution file CUSTOM.

Host Program Parameters

The concurrent manager running your program puts your program name in $0, the four arguments orauser/pwd, userid, username, and request_id in $1 to $4, and your program specific parameters in $5 and beyond. Each of these arguments can be at most 50 characters.

For example, if you pass two parameters into your program, you use $5 to refer to the first parameter and $6 to refer to the second parameter.

Protecting Your Oracle User Password

In some cases, there are security concerns with passing your Oracle username and password on the command line to your HOST program. If you do not want the concurrent manager to pass your username/password to your program, you can have the manager pass it as an environment variable instead. Alternatively, you can not pass it at all.

Note: Passing the username/password in an environment variable is not any more secure than passing it on the command line.

First, define your concurrent program executable as a HOST program in the Concurrent Program Executable form.

To have the username/password passed as an environment variable, enter the term 'ENCRYPT' in the Execution Options field of the Concurrent Programs window when defining a concurrent program using this executable. 'ENCRYPT' signals the concurrent manager to pass the username/password in the environment variable fcp_login. The argument $1 is left blank.

If you do not want the username/password passed to the program at all, enter 'SECURE' in the Execution Options field. The concurrent manager will not pass the username/password to the program.

Success Codes

By default, a shell script returns success (status code 0). If your script traps an error, use the UNIX exit command "exit 1" to return failure (status code 1) to the concurrent manager running the program.

Log and Out Files

Use names in FCP_LOG and FCP_OUT. In this way the log and output/report files can be viewed online.

Testing Your Program

You should test using the <name>.prog file to make sure your script behaves correctly.

Submitting Concurrent Requests (CONCSUB)

You can test your concurrent program by submitting the program using the CONCSUB utility from the operating system.

Syntax

You can submit a concurrent request to run any concurrent program by running the CONCSUB program with the following syntax:

$ CONCSUB <APPS username>[/<APPS password>] \
<responsibility application short name> \
<responsibility name> \
<username> \
[WAIT=N|Y|<n seconds>] \
CONCURRENT \
<program application short name> \
<program name> \
[PROGRAM_NAME="<description>"] \
[REPEAT_TIME=<resubmission time>] \
[REPEAT_INTERVAL= <number>] \
[REPEAT_INTERVAL_UNIT=< resubmission unit>] \
[REPEAT_INTERVAL_TYPE=< resubmission type>] \
[REPEAT_END=<resubmission end date and time>] \
[LANGUAGE=<language of the request>] \
[TERRITORY=<territory of the request>] \
[START=<date>] \
[IMPLICIT=< type of concurrent request> \
[<parameter 1> ... <parameter n>]

Note: You can enter the APPS username only and enter the password when prompted. Alternatively, you can enter the password on the command line, but this method may be insecure.

For parameters that follow the CONCURRENT parameter and include spaces, enclose the parameter argument in double quotes, then again in single quotes. Oracle Application Object Library requires this syntax because it parses the argument string twice. For example, to pass this argument to a program:

This is an example

pass this argument through CONCSUB:

'"This is an example"'

Example

Here is an example of the command to run CONCSUB:

echo "$password" | CONCSUB APPS \
SYSADMIN \
"System Administrator" \
SYSADMIN \
WAIT=N \
CONCURRENT \
FND \
FNDFMRTC \
PROGRAM_NAME='"Register Custom Tables Weekly"' \
REPEAT_INTERVAL=7 \
REPEAT_INTERVAL_UNIT="DAYS" \
REPEAT_INTERVAL_TYPE="START" \
START='"08-JUN-14 23:55:00"'
CGL
APPLSYS
ALL
CGL

Note: You can submit queue control requests for managers and services by passing the queue control request name, manager application short name, and manager short name. Example:

CONCSUB <username>/<password> SYSADMIN 'System Administrator' SYSADMIN CONCURRENT FND ACTIVATE FND STANDARD

Parameters

The following entries explain the required and optional parameters for submitting a concurrent program with CONCSUB. Default values are listed to the right.

Variable Description
username/ password Required. The ORACLE username and password that provides access to the data that your program uses. Alternatively, an Oracle E-Business Suite username and password for a user with the System Administrator responsibility. Another option is "Apps:User" which then requires the password of the FND_USER in the parameter username.
responsibility application short name Required. The application short name of the responsibility whose concurrent processing options you want to use.
responsibility name Required. The name of your responsibility. If the name of your responsibility includes spaces, enclose that name in double quotes.
username Required. The uppercase username of the application user whose concurrent processing options you want to use.
WAIT Optional. A flag that indicates whether to wait for the submitted request to complete. If you leave this parameter out, the default value of N makes CONCSUB return you to the operating system prompt without waiting for your request to complete.
Set WAIT=Y to have CONCSUB check the request status every 60 seconds and return you to the operating system prompt when your request is completed. You can also enter an integer value for a number of seconds, as in WAIT=30, for CONCSUB to check for request completion every <number> seconds.

Important: Using WAIT=Y or WAIT=<number> requires that your request completes before CONCSUB returns you to the operating system. If the concurrent manager is down, your CONCSUB process waits indefinitely until the concurrent manager is started and the request completes.

CONCURRENT Required. A flag that separates the program-specific parameters from the operating system parameters.
program application short name Required. The application short name of your concurrent program.
program name Required. The uppercase name of your program. It must be the short name that you enter in the Concurrent Programs window when defining a concurrent program.
PROGRAM_ NAME Optional. A descriptive name for your program. The program field on the View Requests form displays this as the user-friendly program name. The concurrent program short name passed to CONCSUB is often hard for end users to understand, so the PROGRAM_NAME parameter allows you to pass a more easily remembered name for your concurrent program. If you do not specify a PROGRAM_NAME, the View Requests form displays the user-friendly program name specified in the Concurrent Programs window.
You may also use the PROGRAM_NAME parameter to indicate the batch that your request processes for programs that process a set of data, where there could be several requests for a given program that are active at the same time.
REPEAT_TIME Optional. The time of day to resubmit the request. The format for the time is HH24:MI or HH24:MI:SS. For example, REPEAT_TIME=14:30 resubmits your request daily at 2:30 p.m.

Important: Do not use REPEAT_TIME with other resubmission parameters except for the optional parameters REPEAT_END and START.

REPEAT_ INTERVAL Optional. The interval between resubmission (a positive integer or real number). Use this parameter along with REPEAT_INTERVAL_UNIT to specify the time between resubmissions.
REPEAT_ INTERVAL_ UNIT Optional. The unit of time used for the interval between resubmissions. The available units are MINUTES, HOURS, DAYS or MONTHS. Use this parameter along with REPEAT_INTERVAL to specify the time between resubmissions. For example, setting REPEAT_INTERVAL=12 and REPEAT_INTERVAL_UNIT=HOURS resubmits your request every twelve hours. The default value is DAYS.

Important: Do not use REPEAT_INTERVAL and REPEAT_INTERVAL_UNIT with REPEAT_TIME.

REPEAT_ INTERVAL_ TYPE Optional. Whether to time the resubmission interval from the requested start time of the request or from its completion. Set this parameter either to START or END. The default value is START.

Important: Use REPEAT_INTERVAL_TYPE only if you use REPEAT_INTERVAL.

REPEAT_END Optional. The date and time to stop resubmitting the concurrent request. Use one of the following for the format of the end date:
'"DD-MON-RR HH24:MI:SS"' (as in '"07-APR-14 18:32:05"')
or
'"DD-MON-RRRR HH24:MI:SS"' (as in '"07-APR-2014 18:32:05"')
Note that because this date format includes a space, you must enclose the date in double quotation marks and single quotation marks. You can also specify just the date:
'DD-MON-RR'
or
'DD-MON-RRRR'
LANGUAGE Optional. The NLS language for the request.
TERRITORY Optional. The NLS territory for the request.
START Optional. A start date and time for your program in this format:
'"DD-MON-RR HH24:MI:SS"' (as in '"07-APR-02 18:32:05"')
Because this date format includes a space, you must enclose the date in double quotation marks and single quotation marks. If you do not specify a start time, your program submits immediately and is processed by the next available concurrent manager. The default value is the current time.
IMPLICIT Optional. Whether to show this concurrent request on the View Requests form. Specify NO, YES, ERROR or WARNING. The value IMPLICIT=NO allows the request to appear on the View Request form. The default value is NO.
The value IMPLICIT=YES means that only the System Administrator's privileged View Concurrent Requests form displays this request. Use this value if the request is not interesting to the user.
Specify IMPLICIT=ERROR or IMPLICIT=WARNING, respectively, if you want the request to appear only if it fails or completes with warnings.
REPEAT_DAYS Optional. The number of days after which to repeat the concurrent request, calculated from the last requested start date. The number can be a positive integer or real number. For example, REPEAT_DAYS=1.5 resubmits your request every 36 hours.

Important: Do not use REPEAT_DAYS with other resubmission parameters except for the optional parameters REPEAT_END and START.

Tip: REPEAT_DAYS will become obsolete in a future release. You may therefore want to use REPEAT_INTERVAL, REPEAT_INTERVAL_TYPE and REPEAT_INTERVAL_UNIT instead of REPEAT_DAYS.

parameter 1 ... parameter n Optional. Your program-specific parameters. If a parameter includes spaces, enclose that parameter in double quotes, then in single quotes. If a parameter contains a double quotation mark as part of the argument, precede that mark with a backslash [\].

Copying and Modifying Program Definitions

These sections explain how you can copy and modify concurrent program definitions.

Warning: Do not overwrite program definitions for existing concurrent programs. Copy the program, rename it, then make any desired modifications to the new program.

Related Topics

Overview of Concurrent Programs and Requests

Copying and Renaming a concurrent program

Defining Program Incompatibility Rules

Alter Program Priority

Modifying an Incompatible Programs list

Concurrent Program Parameters

Example of modifying a program's parameters

Concurrent Programs

Warnings for Modifying Program Definitions

Copying and Renaming a concurrent program

You can copy your concurrent programs and modify them to create new programs with definitions that meet your needs. You can modify how a concurrent program operates by changing the program's definition of:

Rather than overwrite a concurrent program's definition, you should customize a program by copying and renaming an existing program, then modifying the new program to suit your needs. The figure below illustrates the basic steps in copying and modifying a new concurrent program.

As the figure illustrates, you can copy parameters, and then modify the behavior of the parameters. Or you can copy the list of incompatible programs, and then modify the list. Finally , you can change the associated printer and/or print style.

Modifying a Concurrent Program

the picture is described in the document text

Related Topics

Overview of Concurrent Programs and Requests

Copying and Modifying Program Definitions

Example of modifying a program's parameters

Concurrent Programs

Alter Program Priority

You may wish to control the priority of some requests on a program level rather than at the user level.

Setting the priority for a program allows any request to run that concurrent program to use your selected priority rather than the priority of the user submitting the request.

For example, a user can submit a variety of requests at the standard priority determined by the value of the user profile Concurrent:Priority. However, when the user submits a request for a particular concurrent program, you want that request to have a higher priority.

You assign that program a priority of 10. When the user requests that program to run, it receives the higher priority defined on the Concurrent Program window rather than the user's standard priority and is processed ahead of other requests. When the users requests other concurrent programs that do not have a specified priority, those requests use the user's Concurrent:Priority profile value.

Related Topics

Copying and Modifying Program Definitions

Concurrent Programs

Modifying an Incompatible Programs List

A concurrent program's definition may include a list of incompatible programs. When a program is listed as incompatible with another program, the two programs cannot run simultaneously in the same conflict domain. See: Defining Program Incompatibility Rules.

You can view which programs are incompatible with a concurrent program from the Incompatible Programs block on the Concurrent Programs window. The programs listed cannot run simultaneously within the same conflict domain as the concurrent program whose definition you are viewing.

To modify the list of incompatible programs you can either:

Add new programs to the list.

The Scope field refers to whether you want the program by itself to be incompatible, or whether you want the program and all child requests, that is, concurrent programs started by the program as part of a request set, to be incompatible.

Related Topics

Copying and Modifying Program Definitions

Concurrent Programs

Administer Concurrent Managers

Concurrent Program Parameters

Parameters, also referred to as arguments, are assigned to standard submission concurrent programs. To define a program as standard submission, set the value of the Standard Submission field in the Concurrent Programs form to Yes.

Important: All the mechanisms for parameter defaulting (including references to values of other parameters, user profiles, etc.) are evaluated only at submission time.

There are two aspects to a parameter associated with a concurrent program: its value set and its behavior.

Variable Description
Parameter value set The valid values the parameter can accept. The set of valid values is referred to as a value set.
Parameter behavior How the parameter behaves within an application. For example, whether:
  • an entry value for the parameter is required in order for the program to work

  • the parameter is displayed to the end user

  • a default value is automatically provided for the parameter

If you wish to define or modify a value set, you must first carefully plan your value set's purpose and implementation.

Using the Concurrent Programs form, you can see a concurrent program's parameters by choosing Parameters. Each parameter has a value set that defines what values are permissible for the parameter. To see the name of a parameter's value set, look at the Value Set field in the Argument Details block.

Related Topics

Copying and Modifying Program Definitions

Control the Behavior of Request Parameters

Example of modifying a program's parameters

Concurrent Programs

Control the Behavior of Request Parameters

The behavior of parameters in programs running individually may differ from when those programs are run as part of a request set.

You define how a program's parameters behave when you define the program using the Concurrent Programs form.

Using the Request Set form, you can also define how a program's parameters behave when the program is run as part of a request. In addition, you can define parameters in different programs in a request set to all share the same value by labeling them as Shared Parameters. See: Sharing Parameters in a Request Set.

Warning: Modifying a concurrent program's definition by adding new or deleting existing parameters, or changing a parameter's value set can prevent the program from running. See: Warnings for Modifying Program Definitions.

Not Displaying Parameters

Using the Concurrent Programs form or the Request Set form, you can set a parameter so it does not display to an end user. Because parameters that do not display cannot be modified, setting a parameter to not display:

If you define a parameter to not display, then the parameter does not appear when the program is run using the Submit Requests form, nor does it appear in the Request Set form.

If you define a parameter to not display, using the Request Set form, then the parameter does not appear on the Submit Requests form when the program is run as part of a request set.

Viewing displayed parameters after a request is submitted

After a request is submitted to run a concurrent program, the program's parameters may be displayed in the Details block of the Concurrent Requests form.

When a parameter is set to not display, it does not appear in the Details block of the Concurrent Requests form.

These displayed parameter values exactly match the values that the concurrent manager passes to the concurrent program, and may or may not correspond to the displayed value that the user chose.

For example, in the Submit Requests form, the user may choose "Oracle General Ledger" as a parameter, but the corresponding application ID displays in the Concurrent Requests form.

Tip: If your users encounter errors when running a program, you can look at the exact values that the concurrent program uses to help you diagnose the problem.

Setting Default Values for Parameters

Parameter default values can be changed by users when they submit a program or request set to run.

You can set a default value for a parameter using the:

Entering erroneous default values

If the Default Type or Default Value for a parameter is incorrect, when the program is being set to run using the Submit Requests form, a window displays along with an error message.

If the parameter is not displayed, you receive an error message. You cannot update a field that is not displayed.

Warning: Be careful when entering the default type and default value, because these values are not validated with the value sets for your parameters. If you enter incorrect values, they do not appear as defaults when you run this request set using the Submit Requests form.

Preventing modification of parameter values in a Request Set

If a parameter is displayed in the Request Set form and there is no default value provided by the program's definition, you can define a default value or have the parameter inherit a shared value, and then prevent end users from modifying that value.

Set the Modify field in the Request Set form to No if you want to show the value for a parameter but not allow changing it when the request set is run using a Standard Submission form. You can set a value for the parameter using a default value or a shared parameter.

If the Display field is set to No, the Modify field automatically defaults to No, and you cannot update it.

Caution: Set defaults for required parameters before turning Modify to No. Otherwise the Submit Requests form returns an error when attempting to submit this report.

Changing responsibility to see changes take effect

Modifying parameter behavior, for example, changing whether a parameter is displayed to the end user, takes effect immediately after you commit your change. However, some changes do not appear to you unless you change responsibility or select your current responsibility again.

Behavior of Program Parameters

The following table describes how a parameter's details affect its behavior in the Concurrent Program form and the Run Requests form.

Program Parameters and Their Behavior in the Concurrent Program Form and Run Requests Form
Parameter Details Concurrent Program Form Run Requests Form
Required Yes Parameter requires a value (entered by user or a default).
Display Yes Parameter is displayed.
Display No Parameter is not displayed, and cannot be modified.
Default Type & Value Yes - Default Type and Value entered. A default value displays, and can be changed by the user.
Default Type and Value No default entered. No default value is displayed.

The following table describes how a parameter's details affect its behavior in the Request Sets form and Run Requests form.

Program Parameters and Their Behavior in the Concurrent Program, Request Set, and Run Request Forms
Parameter Details Concurrent Program Form Request Set Form Run Requests Form
Required Yes Parameter does not require a value. Parameter requires a value.
Display Yes Parameter is displayed. - Display set to Yes. Parameter is displayed.
Display Yes Parameter is displayed. - Display set to No. Parameter is not displayed.
Display No Parameter not displayed. Parameter not displayed.
Modify n/a Yes Value can be modified.
Modify n/a No Value cannot be modified.
Default Type & Value Yes - Default Type and Value entered. Default Type and Value cannot be modified. Default values can be changed by the user.
Default Type & Value No default entered. Yes - a Default Type and Value can be entered. Default values can be changed by the user.
Default Type & Value No default entered. No - Default Type and Value are not entered. No default value is displayed.

Warnings for Modifying Program Definitions

The following table lists warnings for modifying program definitions:

Warnings for Modifying Program Definitions
Action Form Used Warning
Changing the number of columns or rows in a report program. Concurrent Programs - Report Information region. Some report programs are written to produce a precise output. Changing the output definition could prevent the program from running, or produce poor results.
Setting print style to Dynamic. Concurrent Programs - Report Information region - Style field. Dynamic print style informs the program to generate its output based on output dimensions that may vary. Special coding within a program is required to support the Dynamic print style.
Changing the number of parameters in a program definition. Concurrent Programs - Parameters window. Programs are defined to expect x number of parameters. If you add a new parameter (x + 1), the program will ignore it. Deleting a parameter can cause a program not to run.
Changing Value Sets. Concurrent Programs - Argument Details region - Value Set field. Programs expect values of a certain type and length. Programs may not operate if value set is changed.
Changing tokens. Concurrent Programs - Argument Details region - Token field. Programs expect values of a certain type and length. Program may not operate if expected token is not received.
Defining a concurrent executable or program's execution method as Immediate. Concurrent Program Executables - Execution Method field. Concurrent Programs - Executable Information region - Method field. Concurrent programs whose execution method is Immediate must be registered with the program library FNDLIBR. Application developers can register programs with program libraries, System Administrators cannot.

Related Topics

Copying and Modifying Program Definitions

Concurrent Program Parameters

Example of modifying a program's parameters

Concurrent Program Details Report

Example of Modifying a Program's Parameters

Consider the following example of when and how to modify a concurrent program's parameters.

If one user submits a large number of concurrent requests on a daily basis, for example, an Oracle Bill of Materials or Oracle Purchasing supervisor, you can create a streamlined purge program that only purges that user's concurrent processing records.

You can run this program as System Administrator and have it automatically resubmitted on a specific time interval.

You could also create a request set containing this one program and define the user as the owner of the request set. Then, if you do not assign the request set to any report security group, only the user (owner) can run the program. This way, the user can be responsible for purging their own records.

The System Administrator's Purge Concurrent Request and/or Manager Data program contains twelve parameters. You can copy, rename, and modify the program so it displays only three parameters, with only one parameter requiring user entry. See: Purge Concurrent Request and/or Manager Data, Oracle E-Business Suite Maintenance Guide.

The table below summarizes the steps to follow in our example.

Example of Steps Used in Modifying a Concurrent Program's Parameters
Form Used Task
Concurrent Programs (Concurrent Programs Define) Query the Application Object Library program named "Purge Concurrent Request and/or Manager Data" and press Copy. Select both Copy Arguments and Copy Incompatible Programs. Enter a new name for the program you are going to copy, for example, enter JSMITH PURGE.
Concurrent Programs To modify the JSMITH PURGE program's parameters, select the Parameters button.
Concurrent Programs, Parameter Window Modify the following seven parameters so they do not display (user JSMITH cannot see nor change the program's default values): Oracle ID, Program Application, Program, Manager Application, Manager, Responsibility Application, Responsibility.
Modify the following three parameters so they do not display (user JSMITH cannot see nor change the default values you set). Set the parameters to the following (Type=Constant) default: Entity = Request, Mode = Age, User Name = JSMITH.
Leave the following two parameters unchanged so they display. Mode Value will require JSMITH to enter a value, and Report is set to a default value of "Yes": Mode Value, Report.
Request Set (Reports Set) Create a request set with one program in it, the JSMITH PURGE program. Enter JSMITH in the Owner field. If this request set is not assigned to any report security group, only JSMITH will be able to run the JSMITH PURGE program.
Standard Request Submission program form. For example, the Run Reports form (Reports Run) When first submitting the JSMITH PURGE program to run, navigate to the Resubmission Options region and enter, for example, "5" and "Days" in the Interval field.

Related Topics

Copying and Modifying Program Definitions

Concurrent Program Parameters

Control the Behavior of Request Parameters

Concurrent Program Details Report

Conflict Domains

A conflict domain is a set of related data stored in one or more ORACLE schemas and linked by grants and synonyms. Do not confuse logical databases with your ORACLE database. The ORACLE database contains all your Oracle E-Business Suite data, with each application's data usually residing in one ORACLE schema. You can think of a logical database as a line drawn around a set of related data for which you wish to define concurrent program incompatibilities. In other words, logical databases determine which concurrent programs cannot run at the same time.

Logical Databases and Program Incompatibilities

When an ORACLE schema is identified as belonging to a logical database, concurrent program incompatibility rules are enforced when concurrent programs connect to the ORACLE schema.

By checking for incompatibilities between programs running concurrently, accessing the same data, Oracle E-Business Suite ensures that data retrieved by one program is not incorrect or adversely affected when retrieved by another program.

Example - Program Incompatibilities

An example of a concurrent program that is incompatible with other concurrent programs is Oracle General Ledger's Posting program, used to post journal entries.

If the Posting program's incompatibility with other Oracle E-Business Suite concurrent programs were not enforced, other financial reports running simultaneously with the Posting program could contain incorrect account balance information. Logical databases ensure that this does not happen.

Defining Logical Databases

The installation process automatically defines logical databases and assigns ORACLE schemas to them.

A Standard logical database can be assigned to every Oracle E-Business Suite product so that every concurrent program, if incompatible with any other program, does not run concurrently with that program, regardless of which ORACLE schema those two programs connect to. Assigning every ORACLE schema to the same (e.g., Standard) logical database is a fail-safe method of enforcing program incompatibility rules.

You must define new logical databases only if you build a custom application whose data do not interact with data found in existing logical databases.

As a general rule, you should define a logical database for each custom application, and assign that application's ORACLE schema(s) to the corresponding logical database.

However, if a custom application's data interacts with another application's data, you should assign the two applications' ORACLE schemas to the same logical database.

Registering your custom application's tables ensures that the table names appear as QuickPick values in the Define Alerts form.

Concurrent Program Details Report

This report documents concurrent program definitions, including executable file information, execution method, incompatible program listings, and program parameters. If a concurrent program generates a report, column and row information, as well as print output and print style, are also documented.

Use this report when considering concurrent program modifications, such as modifying program incompatibility rules.

Report Parameters

Caution: If you do not enter any parameters, the report returns values for all concurrent programs, and may be very lengthy.

Application Name

Choose the application name associated with the concurrent program whose program definition details you wish to report on.

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

Program

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

Report Headings

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

Concurrent Programs Report

Concurrent Programs Report

This report shows which concurrent programs are currently enabled nand which programs are disabled.

Use this report to record the execution method, argument method, run alone status, standard submission status, request type, and print style information associated with your concurrent programs.

Report Parameters

Application Name

Choose the application name associated with the concurrent programs whose program information you wish to report on.

If you do not enter an application name, the report will return values for all concurrent programs.

Report Headings

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

Related Topics

Overview of Concurrent Programs and Requests

Concurrent Program Details Report

Concurrent Programs

Request Groups Window

Request Groups Window

the picture is described in the document text

Use this window to define a request group. A request security group is the collection of requests, request sets, and concurrent programs that a user, operating under a given responsibility, can select from the Submit Requests window.

System Administrators:

Users:

Request Groups Block

Enter the following fields.

Group

Use the request group's name to assign the request group to a responsibility on the Responsibilities window. An application name and request group name uniquely identify a request group.

Application

Select the name of the application you wish to associate with your request group. An application name and a request security group name uniquely identify a request security group. This application name does not prevent you from assigning requests and request sets from other applications to this request group.

Code

Assign a code to this request group. Some products use the request group code as a parameter that identifies the requests a customized standard submission form can select. See: Customizing the Submit Requests Window using Codes.

Requests Block

Specify the requests and request sets in the request group.

Type

Choose program or set to add one item, or choose application to include all requests in an application.

Related Topics

Overview of Concurrent Programs and Requests

Organizing Programs into Request Groups

Using Codes with Request Groups

Customizing the Submit Requests Window using Codes

Report Group Responsibilities Report

Concurrent Program Executable Window

Concurrent Program Executable Window

the picture is described in the document text

Define a concurrent program executable for each executable source file you want to use with concurrent programs. The concurrent program executable links your source file logic with the concurrent requests you and your users submit to the concurrent manager.

Important: You cannot add new immediate programs to a concurrent manager program library. We recommend that you use spawned concurrent programs instead.

Concurrent Program Executable Block

The combination of application name plus program name uniquely identifies your concurrent program executable.

See: Concurrent Programs Window

Executable

Enter a name for your concurrent program executable. In the Concurrent Programs window, you assign this name to a concurrent program to associate your concurrent program with your executable logic.

Short Name

Enter a short name for your concurrent program executable.

Application

The concurrent managers use the application to determine in which directory structure to look for your execution file.

Execution Method

The execution method cannot be changed once the concurrent program executable has been assigned to one or more concurrent programs in the Concurrent Programs window.

The possible execution methods are:

Variable Description
Host The execution file is a host script.
Oracle Reports The execution file is an Oracle Reports file.
PL/SQL Stored Procedure The execution file is a PL/SQL stored procedure.
Java Stored Procedure The execution file is a Java stored procedure.
Java Concurrent Program The execution file is a program written in Java.
Multi Language Function The execution file is a function (MLS function) that supports running concurrent programs in multiple languages (as well as territories and numeric character settings).
SQL*Loader The execution file is a SQL script.
SQL*Plus The execution file is a SQL*Plus script.
Spawned The execution file is a C or Pro*C program.
Immediate The execution file is a program written to run as a subroutine of the concurrent manager. We recommend against defining new immediate concurrent programs, and suggest you use either a PL/SQL Stored Procedure or a Spawned C Program instead.
Request Set Stage Function PL/SQL Stored Function that can be uesd to calculate the completion statuses of request set stages.

Execution File Name

Enter the operating system name of your execution file. Some operating systems are case sensitive, so the name entered here should match the file name exactly.

Do not include spaces or periods (.) in the execution file name, unless the execution method is PL/SQL stored procedure or Request Set Stage Function.

The maximum size of an execution file name is 60 characters.

Subroutine Name

Enter the name of your C or Pro*C program subroutine here. Do not use spaces or periods (.) in this field.

Only immediate programs or spawned programs using the Unified C API use the subroutine field.

We recommend against defining new immediate concurrent programs, and suggest you use either a PL/SQL Stored Procedure or a Spawned C Program instead.

Stage Function Parameters

The Stage Function Parameters button opens a window that allows you to enter parameters for the Request Set Stage Function. This button is only enabled when you select Request Set Stage Function as your Execution Method.

Stage Function Parameters Window

Stage Function Parameters Window

the picture is described in the document text

List the Parameters that your custom Stage Function uses.

Parameter

Enter a name for the Parameter. This name will be displayed in the Stage Functions Parameter window of the Request Set form.

Short Name

Enter a short name that will be used by the function to reference the parameter.

Related Topics

Concurrent Programs

Concurrent Programs Window

Concurrent Programs Window

the picture is described in the document text

Use this window to define and modify your concurrent programs.

Prerequisites

Build the execution file for your concurrent program.

Use the Concurrent Program Executables window to define a concurrent program executable for your operating system program.

Concurrent Programs Block

The combination of application name plus program name uniquely identifies your concurrent program.

Program

You see this longer, more descriptive name when you view your requests in the Requests window. If this concurrent program runs through Standard Request Submission, you see this name in the Submit Requests window when you run this program.

Short Name

Enter a brief name that Oracle E-Business Suite can use to associate your concurrent program with a concurrent program executable.

Application

The program's application determines what ORACLE username your program runs in and where to place the log and output files.

Enabled

Indicate whether users should be able to submit requests to run this program and the concurrent managers should be able to run your program.

Disabled programs do not show up in users' lists, and do not appear in any concurrent manager queues. You cannot delete a concurrent program because its information helps to provide an audit trail.

(Executable) Executable: Name

Select the concurrent program executable that can run your program. You define the executable using the Concurrent Program Executables window. You can define multiple concurrent programs using the same concurrent program executable. See: Concurrent Program Executables.

(Executable) Executable: Options

Some execution methods, such as Oracle Reports, support additional execution options or parameters. You can enter such options in this field. The syntax varies depending on the execution method.

If you define a concurrent program with the bitmapped version of Oracle Reports, you can control the orientation of the bitmapped report by passing the ORIENTATION parameter or token. For example, to generate a report with landscape orientation, specify the following option in the Options field:

 ORIENTATION=LANDSCAPE

Do not put spaces before or after the execution options values. The parameters should be separated by only a single space. You can also specify an orientation of PORTRAIT.

You can control the dimensions of the generated output with the PAGESIZE parameter. A specified <width>x<height> in the Options field overrides the values specified in the report definition. For example:

 ORIENTATION=LANDSCAPE PAGESIZE=8x11.5

The units for your width and height are determined by your Oracle Reports definition. You set the units in your Oracle Reports menu under Report => Global Properties => Unit of Measurement.

If the page size you specify with the PAGESIZE parameter is smaller than what the report was designed for, your report fails with a "REP-1212" error.

(Executable) Executable: Method

The execution method your concurrent program uses appears here.

Valid values are:

Variable Description
Spawned Your concurrent program is a stand-alone program in C or Pro*C.
Host Your concurrent program is written in a script for your operating system.
Immediate Your concurrent program is a subroutine written in C or Pro*C. Immediate programs are linked in with your concurrent manage and must be included in the manager's program library.
Oracle Reports Your concurrent program is an Oracle Reports script.
PL/SQL Stored Procedure Your concurrent program is a stored procedure written in PL/SQL.
Java Stored Procedure Your concurrent program is a Java stored procedure.
Java Concurrent Program Your concurrent program is a program written in Java.
Multi Language Function A multi-language support function (MLS function) is a function that supports running concurrent programs in multiple languages (as well as territories and numeric character settings). You should not choose a multi-language function in the Executable: Name field. If you have an MLS function for your program (in addition to an appropriate concurrent program executable), you specify it in the MLS Function field.
SQL*Loader Your concurrent program is a SQL*Loader program.
SQL*Plus Your concurrent program is a SQL*Plus or PL/SQL script.
Request Set Stage Function PL/SQL Stored Function that can be used to calculate the completion statuses of request set stages.

You can switch between Spawned and Immediate, overriding the execution method defined in the Concurrent Program Executable window, only if either method appears when the executable is selected and both an execution file name and subroutine name have already been specified in the Concurrent Program Executable window. See: Concurrent Program Executables.

(Executable) Priority

You can assign this program its own priority. The concurrent managers process requests for this program at the priority you assign here.

If you do not assign a priority, the user's profile option Concurrent:Priority sets the request's priority at submission time.

(Request) Type

If you want to associate your program with a predefined request type, enter the name of the request type here. The request type can limit which concurrent managers can run your concurrent program.

(Request) Incrementor

For use by Oracle E-Business Suite internal developers only. The incrementor function is shown here.

(Request) MLS Function

The MLS function, if any, used by the program.

The Multilingual Concurrent Request feature allows a user to submit a request once to be run multiple times, each time in a different language. If this program utilizes this feature, the MLS function can be used to determine which installed languages are needed for the request.

Beginning with Release 12.1, MLS functions can support multiple territories and numeric character sets as well as multiple languages.

See:

Oracle E-Business Suite Developer's Guide

Note: If your program has an MLS function associated with it and the "Use in SRS" box (below) is not checked, then the MLS function will be ignored.

(Request) Use in SRS

Check this box to indicate that users can submit a request to run this program from a Standard Request Submission window.

If you check this box, you must register your program parameters, if any, in the Parameters window accessed from the button at the bottom of this window.

(Request) Allow Disabled Values

If you check the Use in SRS box, you can also check this box to allow a user to enter disabled or outdated values as parameter values.

Many value sets use special table columns that indicate whether a particular value is enabled (using ENABLED_FLAG, START_DATE_ACTIVE, and END_DATE_ACTIVE columns). These value sets normally allow you to query disabled or outdated values but not enter them in new data. For Standard Request Submission, this means that a user would not normally be allowed to enter disabled values as report parameter values when submitting a report, even if the report is a query-only type report.

(Request) Run Alone

Indicate whether your program should run alone relative to all other programs in the same logical database. If the execution of your program interferes with the execution of all other programs in the same logical database (in other words, if your program is incompatible with all programs in its logical database, including itself), it should run alone.

You can enter any specific incompatible programs in the Incompatible Programs windows.

(Request) Enable Trace

Turns on SQL tracing when program runs.

(Request) Restart on System Failure

Use this option to indicate that this concurrent program should automatically be restarted when the concurrent manager is restored after a system failure.

(Request) NLS Compliant

This box is checked if the program allows for a user to submit a request of this program that will reflect a language and territory that are different from the language and territory that the users are operating in.

For example, users can enter orders in English in the United Kingdom, using the date and number formats appropriate in the United Kingdom, then generate invoices in German using the date and number formats appropriate to their German customers.

If this box is left blank then a user can associate any installed language with the request, but the territory will default to the territory of the concurrent manager environment.

Note that this option should be set only by the developer of the program. The program must be written as NLS Compliant to utilize this feature. See: the Oracle E-Business Suite Developer's Guide.

Note that this option should be set only by the developer of the program. The program must be written as NLS Compliant to utilize this feature.

(Request) Recalculate Default Parameters

Parameters used in Standard Request Submission can have default values that are generated dynamically, such as by SQL statements, from profile option values, or using the current date or time. Check this box if the default parameter values should be recalculated upon resubmission or copying a request for this program.

For more information, see Recalculation of Dynamic Default Parameters in Standard Request Submission.

(Output) Format

Select the output format from the following:

(Output) Save

Indicate whether to automatically save the output from this program to an operating system file when it is run. This value becomes the default for all requests submitted for this program. The output of programs with Save set to No is deleted after printing.

If this is a Standard Request Submission program, users can override this value from the Submit Requests window.

(Output) Print

If you enter No, your concurrent program's output is never sent to the printer.

(Output) Columns / Rows

Enter the minimum column and row length for this program's report output. Oracle E-Business Suite uses this information to determine which print styles can accommodate your report.

(Output) Style

The print style you select depends on your system and printer setup. Print styles include:

Your list is limited to those styles that meet your program's columns and row length requirements.

(Output) Style Required

If your program requires a specific print style (for example, a checkwriting report), use this check box to enforce that print style.

(Output) Printer

If you want to restrict your program's output to a single printer, enter the name of the printer to which you want to send your output. If your program has minimum or maximum columns or rows defined, your list of values is limited to those printers that can support your program's requirements.

Users cannot override your choice of printer from the Submit Requests or Requests windows.

Business Events Region

Concurrent programs can be integrated with the Business Event System in Oracle Workflow. Business events can be raised at key points of the life cycle of a request to run a concurrent program. Users can subscribe to the business events and create their own business processes interacting with the concurrent programs.

Here you specify the points at which business events are enabled. The possible points are:

Possible parameters for each event are:

REQUEST_ID 
REQUESTED_BY 
PROGRAM_APPLICATION_ID 
CONCURRENT_PROGRAM_ID 
STATUS 
COMPLETION_TEXT 
TIME_STAMP

Concurrent Programs Buttons

Variable Description
Copy to... Choose this button to create another concurrent program using the same executable, request and report information. You can elect to copy the incompatibility and parameter details as well.
Session Control Choose this window to specify options for the database session of the concurrent program when it is executed.
Incompatibilities Choose this button to open the Incompatible Programs window.
Parameters Choose this button to open the Concurrent Program Parameters window.

Copy to Window

Create another concurrent program using the same executable, request and report information as the current program. You can optionally copy the incompatibility and parameter details information as well.

Related Topics

See: Incompatible Programs Window

Concurrent Program Parameters Window

Concurrent Program Executables

Session Control Window

Use this window to specify options for the database session of the concurrent program when it is executed.

Consumer Group

Optionally specify the resource consumer group for the concurrent program.

See: Resource Consumer Groups in Oracle E-Business Suite, Oracle E-Business Suite Maintenance Guide.

Rollback Segment

Optionally specify a rollback segment to be used with the concurrent program. This rollback segment will be used instead of the default and will be used up until the first commit.

Important: If you specify a rollback segment here, your concurrent program must use the APIs FND_CONCURRENT.AF_COMMIT and FND_CONCURRENT.AF_ROLLBACK to use the specified rollback segment. See: the Oracle E-Business Suite Developer's Guide.

Optimizer Mode

Optionally specify an optimizer mode. You can choose ALL_ROWS, FIRST_ROWS, Rules, or Choose. You would specify an optimizer mode only for a custom program that may not perform well with the default cost-based optimizer (CBO) and needs tuning. You can use a different optimizer mode until your program is tuned for CBO.

Target Node

If you are on a PCP/RAC environment, optionally specify the target node on which requests for this program will run. When requests for this program are submitted, they run on this node if possible.

If no specification is made for the concurrent program, a request will be picked up by any manager able to run it.

If the target node is down, any available manager will pick up the request for processing and log a message to FND_LOG_MESSAGES.

Target Instance

Optionally specify a Real Application Cluster (RAC) instance on which the program will run. When requests for this program are submitted, they run on this instance if possible.

Incompatible Programs Window

Incompatible Programs Window

the picture is described in the document text

Identify programs that should not run simultaneously with your concurrent program because they might interfere with its execution. You can specify your program as being incompatible with itself.

Application

Although the default for this field is the application of your concurrent program, you can enter any valid application name.

Name

The program name and application you specify must uniquely identify a concurrent program.

Your list displays the user-friendly name of the program, the short name, and the description of the program.

Scope

Enter Set or Program Only to specify whether your concurrent program is incompatible with this program and all its child requests (Set) or only with this program (Program Only).

Type

Enter Domain or Global. If you choose Domain, the incompatibility is resolved at a domain-specific level. If you choose Global, then this concurrent program will be considered globally incompatible with your concurrent program, regardless of which domain it is running in.

Related Topics

Concurrent Programs Window

Concurrent Program Parameters Window

Defining Program Incompatibility Rules

Modifying an Incompatible Programs List

Concurrent Program Parameters Window

Concurrent Program Parameters Window

the picture is described in the document text

Enter and update the program parameters that you wish to pass to the program executable. Program parameters defined here should match the variables in your execution file.

Conflicts Domain Parameter

Enter the parameter which will hold the value of the conflict domain of the program. For information on conflict domain parameters, see Concurrent Conflict Domains.

Enter the parameter which will hold the value of the conflict domain of the program.

Security Group

This field is for HRMS security only. See: Customizing, Reporting, and System Administration in Oracle HRMS.

Sequence

Choose the sequence numbers that specify the order in which your program receives parameter values from the concurrent manager.

Enabled

Disabled parameters do not display at request submission time and are not passed to your execution file.

Argument Detail

You specify information about your parameter almost exactly as you define a flexfield segment.

(Validation Information) Value Set

Enter the name of the value set you want your parameter to use for validation. You can only select from independent, table, and non-validated value sets.

The maximum size of your value set is 240 characters.

Important: If you are using a value set of dates, this value set should have a format type of either Standard Date or Standard DateTime if you are using the Multilingual Request feature.

(Validation Information) Default Type

If you want to set a default value for this parameter, identify the type of value you need.

Valid types include:

Variable Description
Constant The default value can be any literal value.
Profile The default value is the current value in the user profile option defined in the Default Value field. Use the profile option name, not the end-user name. You do not need to include $PROFILE$.
SQL Statement The default value is determined by the SQL statement you defined in the Default Value field.
Segment The default value is the value entered in a prior segment of the same parameter window.

(Validation Information) Default Value

You can enter a default value for the parameter. This default value for your parameter automatically appears when you enter your parameter window. You determine whether the default value is a constant or a context-dependent value by choosing the default type.

Your default value should be a valid value for your value set. Otherwise you see an error message when you enter your parameter window on the Run Request window and your default value does not appear.

Valid values for each default type include:

Variable Description
Constant Enter any literal value for the default value.
Profile The default value is the current value of the user profile option you specify here. Enter the profile option name, not the end-user name.
Segment The default value is the value entered in a prior segment of the same flexfield window. Enter the name of the segment whose value you want to copy.
SQL Statement The default value is determined by the SQL statement you enter here. Your SQL statement must return exactly one row and one column in all cases.

(Validation Information) Required

If the program executable file requires an argument, you should require it for your concurrent program.

(Validation Information) Enable Security

If the value set for this parameter does not allow security rules, then this field is display only. Otherwise you can elect to apply any security rules defined for this value set to affect your parameter list.

(Validation Information) Range

Choose either Low or High if you want to validate your parameter value against the value of another parameter in this structure. Parameters with a range of Low must appear before parameters with a range of High (the low parameter must have a lower number than the high parameter). For example, if you plan two parameters named "Start Date" and "End Date," you may want to force users to enter an end date later than the start date. You could assign "Start Date" a range of Low and "End Date" a range of High. In this example, the parameter you name "Start Date" must appear before the parameter you name "End Date."

If you choose Low for one parameter, you must also choose High for another parameter in that structure (and vice versa). Otherwise you cannot commit your changes.

(Window Information) Display

Indicate whether to display this parameter in the Parameters window when a user submits a request to run the program from the Submit Requests window.

You should provide a default type and value for any non-displayed parameter.

(Window Information) Display Size

Enter the field length in characters for this parameter. The user sees and fills in the field in the Parameters window of the Submit Requests window.

You should ensure that the total of the value set maximum sizes (not the display sizes) for all of your parameters, plus the number of separators you need (number of parameters minus one), does not add up to more than 240. If your program values' concatenated length exceeds 240, you may experience truncation of your data in some forms.

(Window Information) Description Size

Enter the display length in characters for the parameter value description. Your window may show fewer characters of your description than you specify here if there is not enough room (determined by the sum of your longest prompt plus your display size for this parameter plus seven). However, your window does not display more characters of the description than you specify here.

(Window Information) Prompt

A user sees the prompt instead of the parameter name in the Parameters window of the Submit Requests window.

(Window Information) Concatenated Description Size

Enter the display length in characters for the parameter value description. The user sees the parameter value in the Parameter Description field of the Submit Requests and View Requests forms. The Parameter Description field concatenates all the parameter values for the concurrent program.

Tip: We recommend that you set the Concatenated Description Size for each of your parameters so that the total Concatenated Description Size for your program is 80 or less, since most video screens are 80 characters wide.

(Window Information) Token

For a parameter in an Oracle Reports program, the keyword or parameter appears here. The value is case insensitive. For other types of programs, you can skip this field.

Related Topics

Concurrent Programs

Incompatible Programs Window

Data Groups Window

Data Groups Window

the picture is described in the document text

Note: Creation of custom data groups is not supported. This section is provided for reference only.

A data group is a list of Oracle E-Business Suite and the ORACLE usernames assigned to each application.

An ORACLE username allows access to an application's tables in an ORACLE database. All data groups automatically include an entry for Application Object Library.

Each responsibility within Oracle E-Business Suite is assigned a data group.

During the installation or upgrading of Oracle E-Business Suite, a standard data group is defined, pairing each installed application with an ORACLE username (note: a standard data group is defined for each set of books, or ledger). You cannot change or delete the predefined values for Application or ORACLE username in a Standard data group. However, you may:

Data Groups Block

Modify an existing data group here.

You cannot change or delete the predefined values for Application or ORACLE username in a Standard data group. However, you may modify the Tool ORACLE username and description, or add new Application-ORACLE username pairs to a Standard group.

Data Group

A data group is uniquely identified by its name.

Once saved, data group names cannot be edited.

Application-ORACLE ID Pairs Block

Pair applications with ORACLE usernames.

When you copy a data group, each application, its assigned ORACLE username, and, if present, its Tool ORACLE username and description, appear in this zone automatically. All data groups automatically include an entry for Application Object Library.

Application

Within each data group, an application can be listed only one time.

Oracle ID

Select the ORACLE ID you want to assign to an application. An application uses an ORACLE ID to access tables in the database. Each ORACLE ID allows access to a predefined set of tables in the database.

Copy Applications From...

Use this button to copy applications from an existing data group.

Related Topics

Overview of Concurrent Programs and Requests

Concurrent Conflicts Domains Window

Concurrent Conflicts Domains Window

the picture is described in the document text

Concurrent conflicts domains ensure that incompatible concurrent programs are not allowed to run simultaneously using related information.

For example, a conflict domain could be a range of numbers. Two concurrent programs could be incompatible if they used the same range of numbers, but compatible if they used different ranges of numbers.

Concurrent managers use concurrent conflicts domains to determine which concurrent programs cannot run at the same time. For example:

To define a conflict domain:

  1. Enter a unique Domain name. The name you enter here may be used as a value for a parameter in the Submit Requests window.

  2. Enter a unique Short Name for your domain. Limit the Short Name to 8 characters.

  3. Optionally, you can provide a description for your domain.

Related Topics

Overview of Oracle E-Business Suite DBA Duties, Oracle E-Business Suite Maintenance Guide

Concurrent Programs HTML UI

Search for Concurrent Programs

Use this page to search for defined concurrent programs.

From this page you can create a new concurrent program or update an existing one.

Create Concurrent Program

The following are prerequisites to defining a concurrent program:

The combination of application name plus program name uniquely identifies your concurrent program.

Update Annotation

Optionally enter an annotation for the Integration Repository for the concurrent program.

Enabled

Indicate whether users should be able to submit requests to run this program and the concurrent managers should be able to run your program.

Disabled programs do not show up in users' lists, and do not appear in any concurrent manager queues. You cannot delete a concurrent program because its information helps to provide an audit trail.

Program

You see this longer, more descriptive name when you view your requests in the Requests window. If this concurrent program runs through Standard Request Submission, you see this name in the Submit Requests window when you run this program.

Application

The program's application determines what ORACLE username your program runs in and where to place the log and output files.

Short Name

Enter a brief name that Oracle E-Business Suite can use to associate your concurrent program with a concurrent program executable.

Program Type

Available options are:

Executable

Enter the following:

Name

Select the concurrent program executable that can run your program. You define the executable using the Concurrent Program Executables window. You can define multiple concurrent programs using the same concurrent program executable.

Parameters

Parameters for the concurrent program are listed here. To add a parameter, click on the Create button.

Incompatibilities

Identify programs that should not run simultaneously with your concurrent program because they might interfere with its execution. You can specify your program as being incompatible with itself.

Conflict Domain Parameter

Enter the parameter which will hold the value of the conflict domain of the program.

For information on conflict domain parameters, see Concurrent Conflict Domains.

Run Alone

Indicate whether your program should run alone relative to all other programs in the same logical database. If the execution of your program interferes with the execution of all other programs in the same logical database (in other words, if your program is incompatible with all programs in its logical database, including itself), it should run alone.

You can enter any specific incompatible programs in the Incompatible Programs windows.

Application

Although the default for this field is the application of your concurrent program, you can enter any valid application name.

Name

The program name and application you specify must uniquely identify a concurrent program.

Your list displays the user-friendly name of the program, the short name, and the description of the program.

Scope

Enter Set or Program Only to specify whether your concurrent program is incompatible with this program and all its child requests (Set) or only with this program (Program Only).

Type

Choose the type of incompatibility, either Domain or Global.

For information on incompatibility types, see Incompatible and Run Alone Programs.

Request

Enter the following:

Request Settings

Enter the following:

Type

If you want to associate your program with a predefined request type, enter the name of the request type here. The request type can limit which concurrent managers can run your concurrent program.

Incrementor

For use by Oracle E-Business Suite internal developers only. The incrementor function is shown here.

MLS Function

The MLS (Multi-Lingual Support) function, if any, used by the program.

The Multilingual Concurrent Request feature allows a user to submit a request once to be run multiple times, each time in a different language. If this program utilizes this feature, the MLS function determines which installed languages are needed for the request.

Beginning with Release 12.1, multiple territories and numeric character settings are also supported.

See the Oracle E-Business Suite Developer's Guide for more information.

Activity Summarizer

For internal use only.

The Activity Summarizer is a PL/SQL subprogram summarizing about the purgable data in application tables for a concurrent program of type "Purge". It returns a list of table names and rows to be purged. Oracle developers register the PL/SQL procedure as summarizer procedure for the concurrent program.

Refresh Portlet

For internal use only.

Concurrent programs that produce data for a portlet can call a function to refresh the portlet's data. The value for Refresh Portlet indicates when the function should be called.

Allow Multiple Pending Requests

If this box is checked, multiple pending requests are allowed; otherwise, only one pending request is allowed.

Use in SRS

Check the SRS (Standard Request Submission) box to indicate that users can submit a request to run this program from a Standard Request Submission window.

If you check this box, you must register your program parameters, if any, in the Parameters window accessed from the button at the bottom of this window.

Allow Disabled Values

If you check the Use in SRS box, you can also check this box to allow a user to enter disabled or outdated values as parameter values.

Many value sets use special table columns that indicate whether a particular value is enabled (using ENABLED_FLAG, START_DATE_ACTIVE, and END_DATE_ACTIVE columns). These value sets normally allow you to query disabled or outdated values but not enter them in new data. For Standard Request Submission, this means that a user would not normally be allowed to enter disabled values as report parameter values when submitting a report, even if the report is a query-only type report.

Restart on System Failure

Use this option to indicate that this concurrent program should automatically be restarted when the concurrent manager is restored after a system failure.

NLS Compliant

The NLS (National Language Support) box is checked if the program allows for a user to submit a request of this program that will reflect a language and territory that are different from the language and territory that the users are operating in.

For example, users can enter orders in English in the United Kingdom, using the date and number formats appropriate in the United Kingdom, then generate invoices in German using the date and number formats appropriate to their German customers.

If this box is left blank then a user can associate any installed language with the request, but the territory will default to the territory of the concurrent manager environment.

Note that this option should be set only by the developer of the program. The program must be written as NLS Compliant to utilize this feature. See: Oracle E-Business Suite Developer's Guide.

Recalculate Default Parameters

Parameters used in Standard Request Submission can have default values that are generated dynamically, such as by SQL statements, from profile option values, or using the current date or time. Check this box if the default parameter values should be recalculated upon resubmission or copying a request for this program.

For more information, see Recalculation of Dynamic Default Parameters in Standard Request Submission.

Output Preferences

Enter the following:

Save

Indicate whether to automatically save the output from this program to an operating system file when it is run. This value becomes the default for all requests submitted for this program. The output of programs with Save set to No is deleted after printing.

If this is a Standard Request Submission program, users can override this value from the Submit Requests window.

Print

If you enter No, your concurrent program's output is never sent to the printer.

Format

Select the output format from the following:

The format that you select here is used by the concurrent manager to determine how to display your report output. You must ensure that the output format you choose matches the format generated by your report, unless the report is an Oracle Reports report in which case the format you select, determines the output generated.

Columns / Rows

Enter the minimum column and row length for this program's report output. Oracle E-Business Suite uses this information to determine which print styles can accommodate your report.

Style

The print style you select depends on your system and printer setup. Print styles include:

Your list is limited to those styles that meet your program's columns and row length requirements.

Style Required

If your program requires a specific print style (for example, a checkwriting report), use this check box to enforce that print style.

Onsite Setting

The following fields are typically specific to the installation.

General

Enter the following:

Priority

You can assign this program its own priority. The concurrent managers process requests for this program at the priority you assign here.

If you do not assign a priority, the user's profile option Concurrent:Priority sets the request's priority at submission time.

Printer

If you want to restrict your program's output to a single printer, enter the name of the printer to which you want to send your output. If your program has minimum or maximum columns or rows defined, your list of values is limited to those printers that can support your program's requirements.

Users cannot override your choice of printer from the Submit Requests or Requests windows.

Template

The default layout template for the program. Values for this field are available only if the concurrent program has been registered as a data definition with XML Publisher and templates have been loaded to the Template Manager. For more information on XML Publisher and the Template Manager, see the Oracle XML Publisher documentation..

At the time of request submission, the default template is presented to the user. The user can override this value when submitting the request.

Retain for

This field indicates how many days the system should retain data for a request of this concurrent program after the request completes. The system will retain this data for this period even if the "Purge Concurrent Request and/or Manager Data" program is run during this time.

Security Group

This field is for HRMS security only. See: Customizing, Reporting, and System Administration in Oracle HRMS.

Log Level for Failure

The log level is used in diagnostics. If a request to run this concurrent program fails, the failure may be recorded in a log file with the specified log level.

Enable Trace

Turns on SQL tracing when program runs.

Enable Time Statistics

Enables the collection of timed statistics, such as CPU and elapsed times, by the SQL trace facility, as well as the collection of various statistics in the dynamic performance tables.

Delete Log File

By default, a log file is created for each concurrent request. If such log files are not necessary for requests for this concurrent program, you can specify that the log file is automatically deleted for each request of this program.

Target Settings

If you are on a PCP/RAC environment, optionally specify the target node on which requests for this program will run. If no specification is made for the concurrent program, the request will be picked up by any manager able to run it.

If the target node is down, any available manager will pick up the request for processing and log a message to FND_LOG_MESSAGES.

Session Controls

Use this region to specify options for the database session of the concurrent program when it is executed.

Consumer Group

Optionally specify the resource consumer group for the concurrent program. See: Resource Consumer Groups in Oracle E-Business Suite, Oracle E-Business Suite Maintenance Guide.

Rollback Segment

Optionally specify a rollback segment to be used with the concurrent program. This rollback segment will be used instead of the default and will be used up until the first commit.

Important: If you specify a rollback segment here, your concurrent program must use the APIs FND_CONCURRENT.AF_COMMIT and FND_CONCURRENT.AF_ROLLBACK to use the specified rollback segment. See: Oracle E-Business Suite Developer's Guide.

Optimizer Mode

Optionally specify an optimizer mode. You can choose ALL_ROWS, FIRST_ROWS, Rules, or Choose. You would specify an optimizer mode only for a custom program that may not perform well with the default cost-based optimizer (CBO) and needs tuning. You can use a different optimizer mode until your program is tuned for CBO.

Statistics

This region provides statistics on earlier requests for a defined concurrent program.

Summary information is collected when a request is completed, and stored in the table fnd_conc_prog_onsite_info.

Concurrent Program - Add Parameter

Enter and update the program parameters that you wish to pass to the program executable. Program parameters defined here should match the variables in your execution file.

General

Enter the following:

Enabled

Disabled parameters do not display at request submission time and are not passed to your execution file.

Sequence

Choose the sequence numbers that specify the order in which your program receives parameter values from the concurrent manager.

Parameter

Enter the parameter name. The value is case insensitive.

Validation

Enter the following:

Value Set

Enter the name of the value set you want your parameter to use for validation. You can only select from independent, table, and non-validated value sets.

The maximum size of your value set is 240 characters.

Important: If you are using a value set of dates, this value set should have a format type of either Standard Date or Standard DateTime if you are using the Multilingual Request feature.

Default Type

If you want to set a default value for this parameter, identify the type of value you need.

Valid types include:

Variable Description
Constant The default value can be any literal value.
Profile The default value is the current value in the user profile option defined in the Default Value field. Use the profile option name, not the end-user name. You do not need to include $PROFILE$.
SQL Statement The default value is determined by the SQL statement you defined in the Default Value field.
Segment The default value is the value entered in a prior segment of the same parameter window.

Default Value

You can enter a default value for the parameter. This default value for your parameter automatically appears when you enter your parameter window. You determine whether the default value is a constant or a context-dependent value by choosing the default type.

Your default value should be a valid value for your value set. Otherwise you see an error message when you enter your parameter window on the Run Request window and your default value does not appear.

Valid values for each default type include:

Variable Description
Constant Enter any literal value for the default value.
Profile The default value is the current value of the user profile option you specify here. Enter the profile option name, not the end-user name.
Segment The default value is the value entered in a prior segment of the same flexfield window. Enter the name of the segment whose value you want to copy.
SQL Statement The default value is determined by the SQL statement you enter here. Your SQL statement must return exactly one row and one column in all cases.

Required

If the program executable file requires an argument, you should require it for your concurrent program.

Enable Security

If the value set for this parameter does not allow security rules, then this field is display only. Otherwise you can elect to apply any security rules defined for this value set to affect your parameter list.

Range

Choose either Low or High if you want to validate your parameter value against the value of another parameter in this structure. Parameters with a range of Low must appear before parameters with a range of High (the low parameter must have a lower number than the high parameter). For example, if you plan two parameters named "Start Date" and "End Date", you may want to force users to enter an end date later than the start date. You could assign "Start Date" a range of Low and "End Date" a range of High. In this example, the parameter you name "Start Date" must appear before the parameter you name "End Date".

If you choose Low for one parameter, you must also choose High for another parameter in that structure (and vice versa). Otherwise you cannot commit your changes.

If your value set is of the type Pair, this field is display only. The value defaults to Pair.

Display

Enter the following:

Display

Indicate whether to display this parameter in the Parameters window when a user submits a request to run the program from the Submit Requests window.

You should provide a default type and value for any non-displayed parameter.

Token

For a parameter in an Oracle Reports program, the keyword or parameter appears here. The value is case insensitive. For other types of programs, you can skip this field.

Description Size

Enter the display length in characters for the parameter value description. Your window may show fewer characters of your description than you specify here if there is not enough room (determined by the sum of your longest prompt plus your display size for this parameter plus seven). However, your window does not display more characters of the description than you specify here.

Display Size

Enter the field length in characters for this parameter. The user sees and fills in the field in the Parameters window of the Submit Requests window.

You should ensure that the total of the value set maximum sizes (not the display sizes) for all of your parameters, plus the number of separators you need (number of parameters minus one), does not add up to more than 240. If your program values' concatenated length exceeds 240, you may experience truncation of your data in some forms.

The default is the name of the parameter.

Prompt

A user sees the prompt instead of the parameter name in the Parameters window of the Submit Requests window.

Concatenated Description Size

Enter the display length in characters for the parameter value description. The user sees the parameter value in the Parameter Description field of the Submit Requests and View Requests forms. The Parameter Description field concatenates all the parameter values for the concurrent program.

Tip: We recommend that you set the Concatenated Description Size for each of your parameters so that the total Concatenated Description Size for your program is 80 or less, since most video screens are 80 characters wide.

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:

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:

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 Maintenance Guide

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:

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:

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:

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.

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.

Priority Levels for Work Shift Definitions
Priority Work Shift Definition Example
1 Specific date and range of times April 15, 2018 8:00am-5:00pm
2 Specific date and no range of times April 15, 2018
3 Range of days and range of times Monday-Friday 8:00am-5:00pm
4 Range of days and no range of times Monday-Friday
5 Range of times and no date and no range of days 8:00am-5:00pm
6 Standard work shift. No date, days, or time defined. Standard work shift is 365 days a year, 24 hours a day.

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.

Modifying Process Workload Over Time

the picture is described in the document text

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:

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:

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:

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

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 Maintenance Guide

Managing Concurrent Processing Files and Tables, Oracle E-Business Suite Maintenance Guide

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 Window

Defining Specialization Rules

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

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

Using more than one rule

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

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

Specialization Rule Logic - Examples

Include Rule Example 1
Include Rules Result
Include X Run only program X
Include Rule Example 2
Rule or Action Result
Include X Run program X
OR ... or
Include User Sam Run requests by User Sam
Net result Run everyone's requests for program X, and run all of Sam's requests.
Exclude Rule Example 1
Rule Result
Exclude 37 Do not run program 37
Exclude Rule Example 2
Rule or Action Result
Exclude 37 Do not run program 37
AND ...and
Exclude User Sam Do not run requests by User Sam
Net result Do not run anyone's requests for program 37, and do not run any of Sam's requests.
Include and Exclude Rule Example 1
Rule or Action Result
Include User Sam Run only requests by User Sam
AND ...and
Exclude 37 Do not run program 37
Net result Run all of Sam's requests except requests to run program 37.
Include and Exclude Rule Example 2
Rule or Action Result
Include X ( Run program X
OR ...or
Include User Sam Run requests by User Sam )
---------- AND ...and
Exclude 37 ( Do not run program 37
AND ...and
Exclude User Mary Do not run requests by User Mary )
Net result Run program X except when requested by Mary, and run all of Sam's requests except requests to run program 37.

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

Additional Examples Using Rule Actions
Rule Action Type Example Explanation
INCLUDE Combined Rule Oracle Project Accounting - Tim's Budgets Manager only reads requests to start programs defined by the Combined Rule "Tim's Budgets".
INCLUDE ORACLE ID APPS2 Manager only reads requests to start programs that connect to the APPS2 (a single install in a multiple install schema) Oracle ID.
INCLUDE Program Oracle Project Accounting - Sales Forecast Manager only reads requests to start the concurrent program named "Sales Forecast".
INCLUDE Request Type Oracle Inventory - Overnight Reports Manager only reads requests to start programs belonging to the request type "Overnight Reports".
INCLUDE User Tim Manager only reads requests to start programs submitted by the application user "Tim".
EXCLUDE Combined Rule Oracle General Ledger - Month End Reports Manager reads all requests to start programs except those defined by the Combined Rule "Month End Reports".
EXCLUDE ORACLE ID APPS2 Manager reads all requests to start programs except those that connect to the APPS2 Oracle ID.
EXCLUDE Program Application Object Library - Purge Audit Tables Manager reads all requests to start programs except requests for the program named "Purge Audit Tables".
EXCLUDE Request Type Oracle Purchasing - Weekend Programs Manager reads all requests to start programs except those belonging to the request type "Weekend Programs".
EXCLUDE User Margaret Manager reads all requests to start programs except those submitted by the application user "Margaret".

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 Window

Combined Specialization Rules Window

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

Specialization Rule Example with a Single Include Action
Action Result
INCLUDE Program - Oracle Assets, No entry for Name field The manager only reads requests to run concurrent programs for the application "Oracle Assets".
Specialization Rule Example with Two Include Actions
Action Net Result
INCLUDE Program - Oracle Assets, No entry for Name field
OR
INCLUDE Program - Oracle Payables, No entry for Name field
The manager only reads requests to run concurrent programs for the application ”Oracle Assets”, or for the application ”Oracle Payables”.
The use of multiple Include actions expands the manager's ability to read requests beyond that of a single Program (single Include action).
Specialization Rule Example with a Single Exclude Action
Action Result
EXCLUDE Oracle ID - APPS2 The manager reads requests to run concurrent programs that connect to any Oracle ID, except those programs that connect to Oracle ID “APPS2".
Specialization Rule Example with Two Exclude Actions
Action Net Result
EXCLUDE Oracle ID - APPS2
AND
EXCLUDE Program - Oracle Payables, No entry for Name field.
The manager reads requests to run concurrent programs that connect to any Oracle ID, except programs that connect to Oracle ID “APPS2", and programs for the application "Oracle Payables".

Simplifying your work

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

Specialization Rule Example
Action Net Result
INCLUDE Program - Oracle Sales and Marketing, No entry for Name field
OR
INCLUDE Request Type - Sales Forecasts
The manager only reads requests to run concurrent programs for the application “Oracle Sales and Marketing", or programs whose request type is “Sales Forecasts".

In this example, both rules are not necessary when programs belonging to the request type “Sales Forecasts" all connect to the Oracle ID “OSM". There is no need for the second Type Include rule.

Exclude rules override Include rules

Example 1 with Include and Exclude Rules
Action Net Result
INCLUDE Program - Oracle Payables, No entry for Name field.
AND
EXCLUDE Program - Oracle Payables Invoice Aging Report
The manager reads all requests for concurrent programs for the application “Oracle Payables", but does not read requests to run the Oracle Payables program “Invoice Aging Report".
Example 2 with Include and Exclude Rules
Action Net Result
INCLUDE Program - Signon Audit Forms
AND
EXCLUDE Request Type - Signon Audit Reports
If the System Administrator program Signon Audit Forms belongs to the Request Type “Signon Audit Reports", the manager will not read requests to run the program, even though it has been specifically identified by an Include rule. The Exclude rule overrides the Include rule.

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

Example for a Specific Oracle ID
Action Net Result
INCLUDE Program - Oracle Payables Invoice Aging Report
AND
EXCLUDE Oracle ID - APPS2
The manager only reads requests to run the Oracle Payables program “Invoice Aging Report" when the program does not connect to the Oracle ID “APPS2". The Exclude action overrides the Include action.
However, when the Invoice Aging Report runs against another Oracle ID, for example, “APPS", then this manager will read requests to run the program.

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.

Example of Distinguishing a Program from a Request Type
Action Net Result
INCLUDE Request Type - Oracle General Ledger Reports
AND
EXCLUDE Program - Oracle General Ledger Account Analysis
If the Account Analysis program belongs to the request type Oracle General Ledger “Reports", then this manager will run every program in the request type Oracle General Ledger Reports, except the program Account Analysis.

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:

Example of Excluding Programs
Action Net Result
INCLUDE Program - Oracle General Ledger, No entry for Name field
AND
EXCLUDE Program - Oracle General Ledger Consolidation Audit
AND
EXCLUDE Program - Oracle General Ledger Consolidation Rules
The manager reads requests for any concurrent programs for the application “Oracle General Ledger", except for the programs "Consolidation Audit" and “Consolidation Rules".

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.

Example of a Manager Running Specific Programs
Action Net Result
INCLUDE Program - Oracle Payables Invoice Aging Report
OR
INCLUDE Program - Oracle Purchasing Receipt Accruals
The manager only reads requests to run the Oracle Payables Invoice Aging Report, or the Oracle Purchasing Receipt Accruals program.

Tip: If you only wanted these two reports run during the night you can define the manager's work shift to run from 2:00am-6:00am (02:00-06:00).

Tip: When you first submit the requests to run the programs, you can define a resubmission interval, for example, 1 month, to resubmit the programs to run every month.

Specializing according to Application User

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

Example for Restricting Requests to a Specific User
Action Result
INCLUDE User - Markus Kalkin The manager only reads requests submitted by the application user "Markus Kalkin".
Example for Restricting Requests by a User and for Other Programs
Action Net Result
INCLUDE User - Markus Kalkin
OR
INCLUDE Program - Oracle Inventory Process Demand Interface
OR
INCLUDE Program - Oracle Inventory Summarize Demand Histories
The manager reads both requests submitted by user Markus Kalkin and requests to run the Oracle Inventory programs "Process Demand Interface" and "Summarize Demand Histories".

Tip: If you want specific programs submitted by a specific user to "jump ahead" of other requests waiting to be run, you can define and specialize a manager as in the example above, and set the user profile option Concurrent:Priority for the user to a high priority (Concurrent:Priority sets the priority of requests submitted by the user).

Related Topics

Specializing Managers to run only certain programs

Defining Specialization Rules

Defining Combined Specialization Rules

Concurrent Managers Window

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.

Example of an Include Action
Action Result
Include Program X Run only program X
Example of a Combined Specialization Rule with Include Lines
Action Result
Include Program X Run program X
AND ...and
Include User Sam Run requests by User Sam
Net result Run only Sam's requests for program X
Example of an Exclude Action
Action Result
Exclude Program 37 Do not run program 37
Example of a Combined Specialization Rule with Exclude Lines
Combination Rule Exclude Lines Result
Exclude Program 37 Do not run program 37
Exclude Program 37 Do not run program 37
AND ...and
Exclude User Sam Do not run requests by User Sam
Net result Do not run anyone's requests for program 37, and do not run Sam's requests
Example 1 of a Combined Specialization Rule with Include and Exclude Lines
Action Result
Include User Sam Run requests by User Sam
AND ...and
Exclude Program 37 Do not run program 37
Net result Run all of Sam's requests except requests to run program 37
Example 2 of a Combined Specialization Rule with Include and Exclude Lines
Action Result
Include Program Application General Ledger ( Run General Ledger Programs
AND ...and
Include User Sam Run requests by User Sam)
---------- AND ...and
Exclude Program 37 ( Do not run program 37
AND ...and
Exclude Program 38 Do not run program 38)
Net result Run Sam's requests for programs from the application General Ledger, except programs 37 and 38

Related Topics

Specializing Managers to run only certain programs

Defining Specialization Rules

Using Combined Rules

Differences Between Specialization and Combined Rules

Concurrent Managers Window

Combined Specialization Rules Window

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.

Example with a Single Exclude Rule
Rule Result
EXCLUDE Oracle ID - APPS The manager reads requests to run concurrent programs that connect to any Oracle ID, except those programs that connect to Oracle ID “APPS".

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.

Example with a Single Include Rule
Rule Result
INCLUDE Oracle ID - APPS2 The manager only reads requests to run concurrent programs that connect to Oracle ID “APPS2".

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.

Example using multiple Exclude actions
Rules Net Result
EXCLUDE Program - Oracle Sales & Marketing, No entry for Name field
AND
EXCLUDE Program - Oracle Inventory, No entry for Name field.
The manager reads all requests to run concurrent programs except requests for programs for the application “Oracle Sales & Marketing", and requests for programs for the application “Oracle Inventory".

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.

Example using multiple Include actions
Rules Net Result
INCLUDE Program - Oracle Payables, No entry for Name field
AND
INCLUDE Program - Oracle Payables Confirm Receipt Batch
The manager only reads requests to run a single program, Confirm Receipt Batch, and only if that program is from the application "Oracle Payables".

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.

Example of Exclude and Include in a Combined Rule
Rules Net Result
INCLUDE Program - Oracle Payables Invoice Impor
AND
EXCLUDE Oracle ID - APPS2
The manager reads requests to run the Oracle Payables Invoice Import program, but will not run the program when it connects to the Oracle ID “APPS2". The Exclude action overrides the Include action.

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.

Example for one program submitted by one user
Rules Net Result
INCLUDE User - Sheryl
AND
INCLUDE Program - Oracle Project Accounting Distribute Usage Costs
The manager only reads requests submitted by Sheryl to run the Distribute Usage Costs program.

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.

Example of restricting the programs run for a specific user
Rules Result
INCLUDE User - Sheryl
AND
EXCLUDE Program - Oracle Project Accounting Expenditure Status
The manager only reads requests submitted by Sheryl, excluding requests to run the Oracle Project Accounting program Accounting Expenditure Status.

Specifying Oracle ID and excluding a program from a request type

Example of specifying an Oracle ID and excluding a program from a request type
Rules Net Result
INCLUDE Request Type - Oracle Project Accounting Expenditure Reports
AND
INCLUDE Oracle ID - APPS2
AND
EXCLUDE Program - Oracle Project Accounting Expenditure Status
The manager only reads requests to run programs belonging to the Oracle Project Accounting request type “Reports", run against the Oracle ID “APPS2", excluding the program Expenditure Reports.

Related Topics

Specializing Managers to run only certain programs

Defining Combined Specialization Rules

Differences Between Specialization and Combined Rules

Concurrent Managers Window

Combined Specialization Rules Window

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:

Specialization Rules and Combined Specialization Rules: Results of Actions
Rule Action Effect of Multiple Actions Relationship to Other Rules
Specialization Rule INCLUDE With each additional Include rule, the manager can read MORE REQUESTS. Each rule establishes an OR condition. OR...INCLUDE...
Specialization Rule EXCLUDE With each additional Exclude rule, the manager is excluded from, and reads, FEWER REQUESTS. Each rule establishes an AND condition. AND...EXCLUDE...
Combined Rule Specialization Line EXCLUDE With each additional Exclude line, the manager is excluded from, and reads, FEWER REQUESTS. Each line within a rule establishes an AND condition. AND...EXCLUDE...
Combined Rule Specialization Line INCLUDE With each additional Include line or additional requirement, the manager reads FEWER REQUESTS. Each line within a rule establishes an AND condition. AND...INCLUDE...

Related Topics

Specializing Managers to run only certain programs

Examples - Using Specialization Rules

Defining Combined Specialization Rules

Using Combined Rules

Concurrent Managers Window

Combined Specialization Rules Window

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:

Variable Description
Quick For concurrent programs that take a relatively short time to run.
Overnight For concurrent programs that take a long time to run, which you typically schedule to run during the late night or early morning hours.
Month-End Reports For concurrent programs that generate reports you run at the end of each month.
For example, if you run ten report programs at the end of each month, you could define a request type called “Month-End Reports" and assign it to your ten report programs.
Then you can use specialization rules to define a concurrent manager that only runs requests of type “Month-End Reports". This way, you do not have to specify your ten different report programs when you define your concurrent manager. You can also easily assign the ten programs to more than one manager.

Related Topics

Overview of Concurrent Processing, Oracle E-Business Suite Maintenance Guide

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:

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:

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.

Internal Manager Control Functions
Control Function Description
Activate concurrent manager Activates the Internal manager and all other managers, except managers that were deactivated individually using "Deactivate concurrent manager".
Verify concurrent manager status Manually executes the process monitoring (PMON) cycle.
Deactivate concurrent manager Deactivates the Internal manager and all other managers.
Terminate requests and deactivate manager All running requests (running concurrent programs) are terminated, and all managers are deactivated.

The following table describes control functions for any other manager.

Control Functions for Other Concurrent Managers
Control Function Description
Activate concurrent manager If the manager is defined to work in the current work shift, it starts immediately. Cancels "Deactivate concurrent manager" and "Terminate requests and deactivate manager".
Restart concurrent manager Internal manager rereads the manager's definition, and the rules for concurrent program incompatibilities. You should restart a manager when you: - Change work shift assignments - Modify the number of target processes - Modify specialization rules - Change concurrent program incompatibilities
Deactivate concurrent manager Deactivates the manager. All requests (concurrent programs) currently running are allowed to complete before the manager shuts down. A manager will not restart until you select the manager and choose "Activate concurrent manager".
Terminate requests and deactivate manager All running requests (running concurrent programs) handled by the manager are terminated. Once deactivated, a manager will not restart until you select the manager and choose "Activate concurrent manager".

Controlling Managers using CONCSUB

You can use CONCSUB to start, stop, and verify managers and other services from the command line. These queue control requests are submitted the same way as other requests submitted through CONCSUB. Before using this utility for queue control, you should become familiar with the CONCSUB utility and its parameters. See: Submitting Concurrent Requests (CONCSUB) for more information.

The following parameters are used in queue control:

Variable Description
queue control request application name Always 'FND'.
queue control request name Required. The name of your request.
manager application short name Required. The application short name of your concurrent manager.
manager short name Required. The short name of your concurrent manager.

Example:

CONCSUB SCOTT SYSADMIN 'System Administrator' SYSADMIN CONCURRENT \
FND ACTIVATE FND STANDARD 

This command will submit an ACTIVATE request for the Standard manager.

Valid queue control requests are:

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.

Control Functions from the Administer Concurrent Managers Form and from the Operating System
From the Administer Concurrent Managers Form From the Operating System (not all arguments shown)
Activate concurrent manager STARTMGR (syntax may vary with platform)
Verify concurrent manager status CONCSUB FND VERIFY
Deactivate concurrent manager CONCSUB FND DEACTIVATE
Terminate requests and deactivate manager CONCSUB FND ABORT

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:

The STARTMGR command takes up to ten optional parameters.

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 as the sysmgr parameter, and will prompt you for the password. You could enter a username/password pair, but this method may be insecure. Alternatively, you could pass an Oracle E-Business Suite username as an appmgr parameter and the system will prompt you for the related password. (You could enter a username/password pair for appmgr here too, but this method may be insecure.) 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 ICM for concurrent requests can be accessed using several navigation paths, including:

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

          logfile=/dbfiles/apps_inst/apps/adsdemo/logs/appl/conc/log/LA0375_0903.mgr
          PRINTER=noprint
           mailto=applmgr
          restart=N
             diag=N
            sleep=30
             pmon=4
           quesiz=1

The Internal Concurrent Manager log file has the default location $APPLCSF/$APPLLOG where $APPLLDM is unset or set to 'single'. However, if the variable $APPLLDM is set to 'product' or another scheme value, then the location for the log file is $APPLCSF/system/$APPLLOG.

For more information on schemes, see: Log and Output File Names and Locations.

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 'Responsibility application shortname'
 'Responsibility name' 'Username' [WAIT={Y|N|n}] CONCURRENT
 'Program application shortname'  PROGRAM 

Parameters

Variable Description
username The ORACLE username that connects to Oracle Application Object Library data. Alternatively, an Oracle E-Business Suite username for a user with the System Administrator responsibility. You will be prompted for the password.
You can pass in a <username>/<password> pair but this method may be insecure.
Responsibility application shortname The application shortname of the responsibility. For the System Administrator responsibility, the application shortname is SYSADMIN.
Responsibility name The name of the responsibility. For the System Administrator responsibility, the responsibility name is System Administrator.
Username The application username of the person who submits the request. For example, SYSADMIN is the username of the System Administrator.
WAIT={Y|N|n} Set WAIT to Y if you want CONCSUB to wait until the request you submitted completes before CONCSUB returns you to the operating system prompt.
Set WAIT to N (the default value) if you do not want CONCSUB to wait.
You can also enter an integer value of n seconds for CONCSUB to wait before it exits.
When used, WAIT must be entered before CONCURRENT.
Program application shortname The application shortname of the program. For the DEACTIVATE, ABORT, and VERIFY programs, the application shortname is FND.
PROGRAM To submit the Shutdown All Managers concurrent request, use the program DEACTIVATE.
To submit the Shutdown Abort Managers concurrent request, use the program ABORT.
To submit the Verify All Managers Status concurrent request, use the program VERIFY.

Example Syntax using CONCSUB

CONCSUB <Username> SYSADMIN 'System Administrator'
 SYSADMIN  CONCURRENT FND DEACTIVATE 
CONCSUB <Username> SYSADMIN 'System Administrator'
 SYSADMIN  CONCURRENT FND ABORT 
CONCSUB <Username> SYSADMIN 'System Administrator'
 SYSADMIN  CONCURRENT FND VERIFY 

Enter the password when prompted.

Using CONCSUB to shut down your managers

Use CONCSUB to shut down the concurrent managers:

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. The shell script, customized for specific operating system, starts.

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

    CONCSUB <Username> SYSADMIN 'System Administrator' \
     SYSADMIN WAIT=Y CONCURRENT FND DEACTIVATE 
    

    Enter the password when prompted.

  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 username>"  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 the specified password is successfully authenticated.

CONCSUB Apps:User SYSADMIN 'System Administrator' SYSADMIN/password
 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 to ensure it stays off the process list.

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:

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 Oracle Real Application Clusters (Oracle 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.

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.

With parallel concurrent processing in a networked environment, concurrent managers run on multiple workstations. A single database server can run a single instance of Oracle; or a cluster of database servers can run multiple Oracle instances using Oracle 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. Beginning with Release 12.2, GSM is always activated. 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.

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.

Restarting a Request

The Internal Concurrent Manager (ICM) will only restart a request that a failed manager was running if the following conditions are met:

  1. The ICM got the database lock for the manager that was running the request.

  2. The phase of the request is Running (phase_code = 'R').

  3. The program for this request has "Restart on System Failure" set.

  4. In addition to the all of the above three requirements, at least one of the following requirements must be met:

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. 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. Beginning with Release 12.2, GSM is always used in concurrent processing, so parallel concurrent processing is also activated.

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.

You may assign a primary and a secondary node to each concurrent manager. 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, then the Internal Concurrent Manager will be restarted on an 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 from that node become 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

Administer Concurrent Managers Window

the picture is described in the document text

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:

Variable Description
Terminate When you terminate requests and deactivate the Internal Concurrent Manager, all running requests (running concurrent programs) are terminated, and all managers are deactivated.
Managers previously deactivated on an individual basis are not affected.
You can terminate requests and deactivate individual managers. All running requests (running concurrent programs) handled by the manager are terminated.
Once deactivated, a manager does not restart until you select the manager and choose the Activate button.
Deactivate When you deactivate the Internal Concurrent Manager, all other managers are deactivated as well. Managers previously deactivated on an individual basis are not affected.
You can deactivate individual managers. Once deactivated, a manager does not restart until you select the manager and choose the Activate button.
When you deactivate a manager, including the Internal Concurrent Manager, all requests (concurrent programs) currently running are allowed to complete before the manager(s) shut down.
Verify This choice appears only when you select the Internal Concurrent Manager.
The Internal Concurrent Manager periodically monitors the processes of each concurrent manager. You can force this process monitoring or PMON activity to occur by choosing the Verify button.
Another result of selecting this choice is that the Internal Concurrent Manager rereads concurrent program incompatibility rules.
Restart This choice appears only when you select an individual manager.
When you restart a concurrent manager, the manager rereads its definition.
You should restart a manager when you have made the following changes using the Define Concurrent Manager form, and you wish those changes to take effect:
  • Change work shift assignments

  • Modify the number of Target Processes

  • In a parallel concurrent processing environment, change node or system queue information

Fixed This choice appears only when a manager has been down due to an underlying issue beyond the concurrent manager startup threshold and the Internal Concurrent Manager has stopped attempting to restart it. After the underlying problem has been fixed, this choice is available so that you can indicate that it has been fixed and the ICM should try to restart the concurrent manager again.
Activate When you activate the Internal Concurrent Manager, you activate all other managers as well, except those managers that were deactivated on an individual basis.
You cannot activate the Internal Concurrent Manager from the PC client. The Internal Concurrent Manager is only activated from the server.
You can also activate an individual concurrent manager that is currently deactivated, so long as the Internal manager is active. If the manager is defined to work in the current work shift, then the Internal manager starts it immediately.

Reviewing a Specific Manager

View details of a concurrent manager's operation

Variable Description
Processes You can view the details of the processes of a given concurrent manager. Processes that are currently active, migrating, or terminating, as well as processes that have been terminated or deactivated, are displayed.
Requests For a selected manager you can view all running and pending requests handled by the manager.

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.

Variable Description
Suspend Suspend the operations of the service.
Resume Resume the operations of the service.

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 Maintenance Guide

Concurrent Processes Window

Concurrent Processes Window

the picture is described in the document text

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:

Variable Description
Active Currently running manager processes display as "Active".
Deactivated Manager processes that are no longer running display as "Deactivated".
These processes were deactivated by you choosing the Deactivate button in the Administer Concurrent Managers block, or by the Internal Concurrent Manager deactivating a concurrent manager at the end of that manager's work shift.
Migrating Managers that are migrating between primary and secondary nodes display as "Migrating".
In a parallel concurrent processing environment, concurrent managers run on either the primary or secondary node assigned to them. Managers migrate to the secondary node if the primary node or the database instance on the primary node is unavailable. Managers migrate back to the primary node once it becomes available.
Terminating Manager processes that are being terminated display as "Terminating".
These processes were terminated by you choosing the Terminate button in the Administer Concurrent Managers block, or by a user selecting "Terminate" in the Concurrent Requests form.
Terminated Manager processes that have been terminated display as "Terminated".
These processes were terminated by you choosing the Terminate button in the Administer Concurrent Managers block, or by a user selecting "Terminate" in the Concurrent Requests form.

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).

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:

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.

Variable Description
Request Log Choose this button to view the log file of the process associated with the running request.
Internal Manager Log Choose this button to view the Internal Concurrent Manager's log file.
Manager Log Choose this button to view the log file of the concurrent manager who started running the request.

Concurrent Requests Window

Concurrent Requests Window

the picture is described in the document text

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

Request Diagnostics Window

the picture is described in the document text

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

Concurrent Managers Window

the picture is described in the document text

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:

Variable Description
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.

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: Custom data groups are no longer supported by Oracle E-Business Suite. Do not create new data groups. Instead, use the Standard data group.

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, Oracle E-Business Suite Maintenance Guide.

(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 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.

Variable Description
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.

Specialization Rules Window

Specialization Rules Window

the picture is described in the document text

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:

Work Shifts Window

Work Shifts Window

the picture is described in the document text

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.

Environment Window

Environment Window

the picture is described in the document text

Use this window to set values for environment variables for a concurrent manager, or JVM parameters for a Java service. These values are read and used by the Service Manager when starting each service.

For concurrent managers, if any variable is added or changed, then the concurrent manager must be restarted for the changes to take effect.

For Java services, the window has a single column for JVM Parameter values. These values are used when the JVM is started.

Note: The environment variable values and JVM parameters are limited to 512 characters.

Variable

Enter an environment variable for a concurrent manager.

Value

Enter a value for the environment variable.

Work Shifts Window

Work Shifts Window

the picture is described in the document text

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

Combined Specialization Rules Window

the picture is described in the document text

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:

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.

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:

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

Concurrent Request Types Window

the picture is described in the document text

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

Viewer Options Window

the picture is described in the document text

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:

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 Maintenance Guide

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

Nodes Window

Nodes Window

the picture is described in the document text

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

Setting Up, Starting, and Shutting Down Concurrent Managers

Oracle E-Business Suite concurrent managers run processes in the background on a server machine. You must set up and start the concurrent managers for each product group before you can use your Oracle E-Business Suite products. Refer to Managing Application Tier Services, Oracle E-Business Suite Maintenance Guide for more information on the adcmctl script for starting and stopping concurrent managers. The instructions in this section apply whether you are installing or upgrading.

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

Setting Up Concurrent Managers

For UNIX

Keep the following in mind when you start the concurrent managers:

Parameter values set in startmgr override any other values. Command line values override environment and default values, and so on. Another section in this manual contains more information on editing the startmgr script.

You can change directory privileges while the managers are running, and the changes will be effective immediately. You can change environment variables and startup parameters while the managers are running, but your changes will not take effect until the concurrent managers are restarted. To put changes into effect, shut down the managers, make the necessary modifications, and restart the managers.

For Windows

On Windows platforms, the OracleConcMgr<SID> service (where <SID> is the database <SID> and the value of the LOCAL variable) spawns the concurrent manager programs. The OracleConcMgr<SID> service is initially created by the Rapid Install program. If you need to recreate the service, use one of the following two methods:

Method 1

From the command prompt:

C:\> cd %COMMON_TOP%\admin\install 
C:\> adsvcm.cmd <NT User> <NT Password> 

where NT User is the user that runs the concurrent manager service, and NT Password is the password of the user that runs the service.

Method 2

Invoke the GUI program ccmsetup.exe (located in %FND_TOP%\bin), and choose the option to create the service.

Parameters

The following entries describe the concurrent manager startup parameters, which are read by the concurrent manager service and passed to the concurrent manager programs. The GUI program ccmsetup.exe (located in %FND_TOP%\bin) should be used to create and set these parameters in the Windows registry. Note that the registry settings override defaults. These parameters can also be used by the adcmctl.cmd script (see Managing Application Tier Services, Oracle E-Business Suite Maintenance Guide for more information).

Database Connection

Variable Description
Schema Name The APPS schema name should be set to the APPS user ID.
Password This is the password to the Oracle E-Business Suite account in the database.
TNS Aliasname This is the database <SID>.

Server Startup

Variable Description
Use this Account Check the "Use this Account box" to specify the OS account ( <NT User> and <NT Password>) that runs the CCM service. If you do not check this box, the system account launching the service will not have permission to access network resources.

Startup Options

Variable Description
Sleep Number of seconds (integer) the internal concurrent manager waits between times it looks for Queue Controlled (in statuses Deactivate/Abort/Verify/Activate) requests. The default value is 60.
Restart This parameter is used in the event of abnormal termination. Its value is the number of minutes (integer) the internal concurrent manager (ICM) has to be up/active/running before it exits abnormally in order for it to be automatically restarted. The ICM must be active for at least as long as the time specified by this parameter; that is, the duration between startup and termination must be greater than the duration specified by this parameter. The default value is N. The default value prevents the manager from restarting after abnormal termination.
Queue Size Number of pmon cycles (integer) the internal concurrent manager waits between times it checks for normal changes in concurrent manager operation. Normal changes include the start or end of a work shift and changes to concurrent manager definitions entered in the Concurrent Managers form. The default value is 1.
PMON cycle Number of sleep cycles (integer) the internal concurrent manager waits between times it checks for concurrent managers that have failed while running a concurrent request. The default value is 20.
Printer Name Name of the printer to which the concurrent managers send request output, where the requests are submitted from within a concurrent program if the submitting program (parent request) does not have a printer associated with it.
Enable Distributed Concurrent Processing Check this box to enable distributed concurrent processing.

Shutdown

Variable Description
Deactivate/ Normal Shuts down the concurrent managers using normal shutdown methods.
Terminate/Abort Processes When shutting down the concurrent managers, aborts the concurrent managers.

Note: This option is currently disabled. Checking this box will have no effect.

File Logging

Variable Description
Activation Log The name of the log file generated upon startup of the Internal Concurrent Manager. Defaults to CM_<SID>.log.
Deactivation Log The name of the log file generated upon shutdown of the Internal Concurrent Manager. Defaults to CS_<SID>.log.
Record Diagnostic Messages Checking this box will cause concurrent managers to produce diagnostic output regularly. Note that leaving this box unchecked prevents large log files.
Save Log History Checking this box prevents log files from being overwritten when the concurrent manager is started.

Starting the Concurrent Managers

Before starting the concurrent managers, you must start the Oracle E-Business Suite TNS listener on all nodes. The TNS listener must be started by the applmgr user.

For UNIX

You can start the concurrent managers from by running the script startmgr from the operating system command line. To start the concurrent manager from the operating system prompt, use the following syntax:

$ startmgr \
 sysmgr="<APPS username>" \
 mgrname="<name>" \
 PRINTER="<printer>" \
 mailto="<userid1 userid2...>" \
 restart="N|<minutes>" \
 logfile="<filename>" \
 sleep="<seconds>" \
 pmon="<cycles>" \
 quesiz="<cycles>" \
 diag="Y|N" 

All parameters are optional. You can pass parameters to the script in any order. These parameters can also be used by the adcmctl.sh script (see Managing Application Tier Services, Oracle E-Business Suite Maintenance Guide for more information).

Parameters

The following entries describe the concurrent manager startup parameters. The default values apply if you do not specify different values in the startmgr script, on the command line when you run startmgr, or in your environment.

Variable Description
sysmgr APPS schema name should be set to the APPS schema user ID. You will be prompted for the password if you omit the parameter entirely and use the default value. The default value is $FNDNAM. Alternatively, you could pass the user ID and password as <APPS username>/<APPS password> but this method may be insecure.
mgrname Name of the internal concurrent manager (alphanumeric characters only). The default value is std.
PRINTER Name of the printer to which the concurrent managers send request output, where the requests are submitted from within a concurrent program if the submitting program (parent request) does not have a printer associated with it.
mailto List of users who receive mail when the internal concurrent manager stops running. The default value is the user who starts managers.
restart This parameter is used in the event of abnormal termination. Its value is the number of minutes (integer) the internal concurrent manager (ICM) has to be up/active/running before it exits abnormally in order for it to be automatically restarted. The ICM must be active for at least as long as the time specified by this parameter; that is, the duration between startup and termination must be greater than the duration specified by this parameter. The default value is N. The default value prevents the manager from restarting after abnormal termination.
logfile The name of the internal concurrent manager's log file. The default value is <mgrname.mgr>.
sleep Number of seconds (integer) the internal concurrent manager waits between times it looks for Queue Controlled (in statuses Deactivate/Abort/Verify/Activate) concurrent requests. The default value is 60.
pmon Number of sleep cycles (integer) the internal concurrent manager waits between times it checks for concurrent managers that have failed while running a concurrent request. The default value is 20.
quesiz Number of pmon cycles (integer) the internal concurrent manager waits between times it checks for normal changes in concurrent manager operation. Normal changes include the start or end of a work shift and changes to concurrent manager definitions entered in the Concurrent Managers form. The default value is 1.
diag diag=Y tells all concurrent managers to produce diagnostic output regularly. The default value diag=N prevents large log files.

Example

$ startmgr sysmgr="<APPS username>" \
  mgrname="std" \
  PRINTER="hqseq1" \
  mailto="jsmith" \
  restart="N" \
  logfile="mgrlog" \
  sleep="30" \
  pmon="5" \
  quesiz="2"

For Windows

The OracleConcMgr<SID> service is launched from the Control Panel Services applet. It can also be launched from the command line using the following command:

C:\> net start OracleConcMgr<SID> 

Restarting the Concurrent Managers

You must restart the concurrent managers whenever you start the Oracle server database or change the concurrent manager startup parameters.

On UNIX platforms, concurrent managers append to their own log file if the log files exist when they restart. Therefore, the user who restarts the concurrent managers must either own the existing files, have write privilege for them, or delete them before restarting.

On Windows, the concurrent manager logs are overwritten when the concurrent managers are restarted. Checking the "Save Log History" option in the ccmsetup GUI tool saves the previous log files.

The concurrent managers delete temporary files when each concurrent process finishes. If the concurrent managers stop abnormally, however, they may not delete these files.

Tip: Delete temporary files only if they have not been accessed more recently than a few days ago. This helps to prevent the loss of files required by the operating system or the concurrent managers.

Ideally, delete temporary files during maintenance windows when the database is down and no applications programs are active.

Network Failure Recovery

As part of its shutdown process, the ICM determines if it's being forced to shutdown due to losing its database connection. This is done by looking for specific error messages ORA-3113, ORA-3114, or ORA-1041. If one of these error messages is detected, the ICM spawns the reviver process, which attempts to make a database connection. If unsuccessful, it sleeps for a period before trying again. This continues until either a successful connection is made or it receives a signal to shut itself down.

When a successful connection is made, the process kills the old ICM database session, and then starts a new ICM using the normal start manager script. Once the ICM is restarted, it starts up any other managers that had also shut down, and normal processing resumes.

Shutting Down the Concurrent Manager Service (Windows)

The OracleConcMgr<SID> service may be shut down from the Control Panel Services applet. It can also be stopped from the command line using the following command:

C:\> net stop OracleConcMgr<SID> 

Although you can shut down concurrent managers from Oracle E-Business Suite System Administrator's responsibility, this does not stop the concurrent manager service. You must still stop the concurrent manager service from the Windows Control Panel Services applet before you can restart the concurrent managers.

Note: The OracleConcMgr<SID> service may take several minutes to shut down because it needs to finish processing currently running requests.

Warning: Do not use the Task Manager to stop the concurrent manager service or other Applications processes unless you are advised to do so by Oracle Worldwide Support.

Removing the Concurrent Manager Service (Windows)

If you need to remove the concurrent manager service, ensure that it is not running.

To remove or delete the OracleConcMgr<SID> service, use one of the following 2 methods:

Method 1

At the command prompt, type:

C:\> cd %COMMON_TOP%\admin\install 
C:\> adsvcm.cmd -deinstall 

Method 2

Invoke the GUI program ccmsetup.exe, and choose the option to remove the service.

Once you have done this, you will need to reinstall the concurrent manager service in order to process concurrent requests.

Starting and Stopping the Concurrent Manager with the Concurrent Manager Operator User

Traditionally the operator starting and stopping the application services needed to know the APPS username and password in order to start the application services on an application tier that was running the Concurrent Manager. Starting with Release 12.1.3, it is possible to create an Oracle E-Business Suite user (FND User) with the responsibility ”Concurrent Manager Operator” and use this user's username and password start and stop the application services. The procedure is the following:

  1. Createa new user, for example, "CONCOPER", and assigning the ”Concurrent Manager Operator” responsibility to this user.

  2. On the application tier, update the following four variables in the AutoConfig context file, as listed in the following table:

    AutoConfig Variable Values
    AutoConfig Variable New Value
    s_cp_user CONCOPER (or the one you created)
    s_cp_password_type AppsUser
    s_cp_resp_shortname FND
    s_cp_resp_name Concurrent Manager Operator
  3. Run AutoConfig on the application tier(s).

Following this change, the application tier services can be started and stopped by calling adstrtal.sh and adstpall.sh with the -secureapps option and the script will prompt for the Oracle E-Business Suite user's username and password rather than the APPS username and password.

For example

[applmgr@app01]$ adstrtal.sh -secureapps 
Enter the Applications username: CONCOPER 
Enter the Applications password:

File Conventions

The following table lists the locations and file naming conventions for log, output, and temporary files. The location of product log and output files depends on whether you have set up a common directory.

Location and File Naming Conventions for Files on UNIX
File Type Location Filename
Internal Concurrent Manager Log $FND_TOP/$APPLLOG with Common Directory: $APPLCSF/$APPLLOG <mgrname>.mgr
Concurrent Manager Log $FND_TOP/$APPLLOG with Common Directory: $APPLCSF/$APPLLOG w<nnn>.mgr
Request Log Default: $<PROD>_TOP/$APPLLOG with Common Directory: $APPLCSF/$APPLLOG l<request ID>.req
Request Output Default: $<PROD>_TOP/$APPLOUT with Common Directory: $APPLCSF/$APPLOUT o<request ID>.out
Temporary $APPLTMP or $REPORTS60_TMP OF<abcd12345>.t where <abcd12345> is a random OS-generated string

You have several options for the directories used in storing log and output files; for more information, see: Log and Output File Names and Locations.

Parameters

The variable parameters have the following values:

Variable Description
mgrname For UNIX, the name specified with the mgrname parameter in the startmgr command. If no name is specified, the filename is std.mgr.
For Windows, the name specified with the mgrname parameter in the ccmsetup.exe program. If no name is specified, the filename is std.mgr.
nnn A sequence number between 1 and 999 is generated by the concurrent processing facility.
<PROD>_TOP The product's top environment variable, such as GL_TOP.
request ID The number that identifies the concurrent request.
USERNAME Up to eight characters (uppercase) of the application username of the user that requested the concurrent process.
<abcd12345> Naming convention in which <abcd> are random letters and <12345> designate the operating system process ID of the concurrent process that generated the file.

Directory Privileges

Oracle recommends that you start the managers from the applmgr login to ensure that they inherit the correct directory privileges. The user who starts the concurrent managers then owns the log and output files that the concurrent managers create.

For UNIX, any user who runs an environment file and has access to the startmgr script can start the concurrent managers.

Warning: Always start the concurrent managers from the applmgr login if you are using parallel concurrent processing on multiple nodes.

For UNIX

This section describes directory privileges for UNIX.

Setting the startmgr User ID with setuid in UNIX

To ensure that startmgr inherits the applmgr directory privileges, you can use the UNIX setuid facility to set startmgr to the applmgr login's UNIX user ID. The concurrent managers then inherit the applmgr privileges no matter which login runs startmgr. This allows you to start or restart concurrent managers using the Administer Concurrent Managers form, regardless of the originating UNIX login. Note that you must reset the user ID with setuid if you modify or copy startmgr. Refer to your online UNIX documentation for information on setuid.

Note: The use of the setuid command may cause unexpected behavior on certain platforms that employ dynamic linking of libraries. Please refer to the Oracle E-Business Suite Installation Update for your platform for any information regarding this problem.

Directory Privileges for Logins other than applmgr

If you do not set the startmgr script to the applmgr user ID and you start the managers from a login other than applmgr, that login needs to have these privileges:

You can verify that a login has the necessary privileges on a certain directory with this command:

$ ls -ld < directory> 

Here is an example:

$ ls -ld /usr/tmp
drwxrwxrwx 3 root 22880 Mar 10 11:05 /usr/tmp
       ^^^

The three letters marked in the sample response indicate that all users have read, write, and execute privilege for the directory.

Printing

This section contains printer reference material including information on how to create and register executable printing programs.

To register printers in the Printers window of Oracle E-Business Suite, your Oracle E-Business Suite System Administrator needs to know each printer's operating system name. Your installation update tells you where to find the printer names for your platform. Installation updates may also contain other information on setting up your printers.

Printing (for UNIX)

This section contains printer reference material specific to the UNIX operating system, including information on how to create and register executable printing programs.

Standard Print Subroutine

The standard printing subroutine that you can select in the Printer Drivers form uses Oracle Application Object Library routines to print reports. This requires fewer machine resources than printing through a customized executable program or a shell command such as lp or lpr.

When you use the subroutine, there may be options available through the descriptive flexfield at the bottom of the form. These options vary by platform and may include the following: mail Notify user by electronic mail when report finishes printing.

Check your installation update for any additional options available on your platform.

Executable Printing Programs

Oracle E-Business Suite supports the use of executable programs for printing. However, we recommend that you use executable programs only to provide features unavailable through Oracle E-Business Suite printer drivers, such as:

If you do not need to support special features such as these, print through the standard printing subroutine and printer drivers defined in the Oracle E-Business Suite database. This makes the most efficient use of machine resources.

Upgrading to Existing Executable Programs

Because printing through the standard printer subroutine uses machine resources more effectively than printing through executable programs, we recommend the following if you used executable printing programs in the previous release of Oracle E-Business Suite.

Writing an Executable Program

Executable printing programs can format report output through escape sequences or a printer programming language. Creating them requires a thorough knowledge of both printer operation and a computer programming language. Follow the guidelines in this section if you need to create an executable printing program.

Printer Styles

An executable program should be able to format report output for various print styles, including these:

Formatting Arguments

If the program handles formatting for various print styles internally, you can pass arguments from the printer drivers to the program to determine which print style to use.

If the program does not contain print style formatting commands, you can define the commands in a shell script that calls the program. You then define the shell script as the printing program in a printer driver and pass arguments that determine the print style from the driver to the script.

The printer driver that calls the executable program or shell script must be able to pass the following arguments:

Initialization and Reset

You do not have to add printer initialization and reset strings to your program if you can define these strings in the Printer Drivers form.

Character Mode Oracle Reports Commands

We recommend that you design your executable programs to work with the standard Oracle Reports print drivers. The following standard drivers are located in the $FND_TOP/$APPLREP directory:

The program should not misinterpret the commands for bold on, bold off, and page size that the standard drivers imbed in Oracle E-Business Suite reports. If necessary, you can create customized Oracle Reports drivers as described below.

Location of Program

When you have compiled and linked the source code or written a shell script, move the program to the $APPLBIN subdirectory under the top directory of your custom development area. Keep copies of the source file in your custom development area as a backup.

Creating Customized Character Mode Oracle Reports Print Drivers

The Oracle Reports print drivers set the font styles for italics, underlining, and bolding. If your executable printing program cannot use the standard Oracle Reports drivers, create a customized driver for each print style you will use with the program.

To create a customized driver, copy L.prt, P.prt, A.prt, or W.prt from $FND_TOP/$APPLREP to your custom development area. Modify a standard driver as needed for your executable printing program. Give the customized driver a new filename but keep the .prt extension. Then copy the customized driver to $FND_TOP/$APPLREP.

Tip: Use the executable program name and print style letter as the driver name. For example, use HPLJ3P.prt for portrait style printing with the executable program HPLJ3. When you print in portrait style with this program, the concurrent managers pass the HPLJ3P.prt driver to Oracle Reports as DESFORMAT=HPLJ3P.

Registering Executable Programs

When you have created your executable programs and, optionally, your shell scripts and Oracle Reports drivers, register them in the Printer Drivers form.

  1. Navigate to the Printer Drivers window and create a new printer driver name. Also add the user name, description, and platform.

  2. In the SRW Driver field, enter the name (without the .prt extension) of a standard or customized Oracle Reports driver. All drivers must be in the directory $FND_TOP/$APPLREP.

  3. Enter Program as the driver method.

  4. Enter No in the Spool File field.

  5. Enter No in the Standard Input field.

  6. In the program name field, enter the name of the executable program or the shell script that calls it. Include the full path name if this file is not in the $FND_TOP/bin directory.

  7. Add the arguments that Oracle E-Business Suite passes to the program or shell script. The driver must pass the following to the executable program:

Printing (For Windows)

This section contains printer reference material specific to the Windows operating system. It also explains how to create and register executable printing programs.

Operating System Names for Printers

To register printers in the Printers window of Oracle E-Business Suite, your Oracle E-Business Suite system administrator needs to know each printer's operating system name. For Windows, you can obtain the printer's name from the Printers folder in My Computer. If you register an invalid printer, the operating system's default printer will be used instead.

Standard Print Subroutine

The standard printing subroutine that you can select in the Printer Drivers form uses Oracle Application Object Library routines to print reports. This requires fewer machine resources than printing through a customized executable program DOS command such as PRINT.

Executable Printing Programs

Oracle E-Business Suite supports the use of executable programs for printing. However, we recommend that you use executable programs only to provide features unavailable through Oracle E-Business Suite printer drivers, such as:

If you do not need to support special features such as these, print through the standard printing subroutine and printer drivers defined in the Oracle E-Business Suite database. This makes the most efficient use of machine resources.

Upgrading Existing Executable Programs

Because printing through the standard printer subroutine uses machine resources more effectively than printing through executable programs, we recommend the following if you used executable printing programs in the previous release of Oracle E-Business Suite:

Writing an Executable Program

Executable printing programs can format report output through escape sequences or a printer programming language. Creating them requires a thorough knowledge of both printer operation and a computer programming language. Follow the guidelines in this section if you need to create an executable printing program.

Printer Styles

An executable program should be able to format report output for various print styles, including these:

Formatting Arguments

If the program handles formatting for various print styles internally, you can pass arguments from the printer drivers to the program to determine which print style to use.

If the program does not contain print style formatting commands, you can define the commands in a command file that calls the program. You then define the .cmd file as the printing program in a printer driver and pass arguments that determine the print style from the driver to the script.

The printer driver that calls the executable program or .cmd file must be able to pass the following arguments:

Initialization and Reset

You do not have to add printer initialization and reset strings to your program if you can define these strings in the Printer Drivers form.

Character Mode Oracle Reports Commands

We recommend that you design your executable programs to work with the standard Oracle Reports print drivers. The following standard drivers are located in the %FND_TOP%\%APPLREP% directory:

The program should not misinterpret the commands for bold on, bold off, and page size that the standard drivers imbed in Oracle E-Business Suite reports. If necessary, you can create customized Oracle Reports drivers as described in the next section.

Location of Program

When you have compiled and linked the source code or written a command file, move the program to the %APPLBIN% subdirectory under the top directory of your custom development area. Keep copies of the source file in your custom development area as a backup.

Creating Customized Character Mode Oracle Reports Print Drivers

The Oracle Reports print drivers set the font styles for italics, underlining, and bolding. If your executable printing program cannot use the standard Oracle Reports drivers, create a customized driver for each print style you will use with the program.

To create a customized driver, copy L.prt, P.prt, A.prt, or W.prt from %FND_ TOP%\%APPLREP% to your custom development area. Modify a standard driver as needed for your executable printing program. Give the customized driver a new filename but keep the .prt extension. Then copy the customized driver to %FND_ TOP%\%APPLREP%.

Tip: Use the executable program name and print style letter as the driver name. For example, use HPLJ3P.prt for portrait style printing with the executable program HPLJ3. When you print in portrait style with this program, the concurrent managers pass the HPLJ3P.prt driver to Oracle Reports as DESFORMAT=HPLJ3P.

For more information, see the Oracle Reports Developer documentation.

Registering Executable Programs

When you have created your executable programs and, optionally, your Oracle Reports drivers, register them in the Printer Drivers form.

Define a printer driver and corresponding print style for each print style that your executable program supports. Complete the following steps to register an executable program for a printer driver:

  1. Navigate to the Printer Drivers form and create a new printer driver name. Also add the user name, description, and platform.

  2. In the SRW Driver field, enter the name (without the .prt extension) of a standard or customized Oracle Reports driver. All drivers must be in the directory %FND_TOP%\%APPLREP%.

  3. Enter Program as the driver method.

  4. Enter No in the Spool File field.

  5. Enter No in the Standard Input field.

  6. In the Program Name field, enter the name of the executable program or the command file that calls it. Include the full path name if this file is not in the %FND_TOP%\bin directory.

  7. Add the arguments that Oracle E-Business Suite passes to the program or command file. The driver must pass the following to the executable program:

Related Topics

Overview of Printers and Printing

Printer Drivers Window

Managing Concurrent Processing with Oracle Applications Manager

The Oracle Applications Manager allows administrators to manage E-Business Suite systems from an HTML console. Oracle Applications Manager can be used for a wide variety of tasks such as administering services including concurrent managers, examining system configuration, managing Oracle Workflow, examining applied patches, and measuring system usage.

Oracle Applications Manager provides diagnostic features for Applications systems. The console displays errors recently reported by system components such as transaction managers or concurrent requests. For running processes such as forms or concurrent requests, system administrators can examine the database session details, including any currently executing SQL.

Oracle Applications Manager allows administrators to configure, monitor, and control concurrent processing. Combined with the Service Management feature, Oracle Applications Manager can be used to monitor and control concurrent managers, as well as other application tier services.

Using the Oracle Applications Manager, you can:

Service Instances

The Service Instances pages contain detailed information on the service instances for a particular service type, and display functions you can perform on the services.

Service types include, but are not limited to, the following:

The information and functionality available depends on the service type. Information may include the following:

Controlling Service Instances

You can select a service instance and use the drop down menu above the table to perform the actions listed below. Or you can use the drop down menu at the top right to perform a single action on all service instances.

Service Instances of a Request Processing Manager

This page shows you information on service instances for a request processing manager. This type of manager runs concurrent requests.

Navigation: Applications Systems > System Activity > (Services region) Request Processing Manager

The following information is displayed:

You can use the buttons at the top to perform the following on a selected service instance:

To create a new service instance, use the Create New button.

Start

You can start (activate) a service instance.

Stop

You can deactivate individual services. Once deactivated, a service does not restart until you select the service and choose the Start button.

When you deactivate a manager, all requests (concurrent programs) currently running are allowed to complete before the manager shuts down.

Restart

When you restart a manager, the processes are shut down and then brought back up.

Abort

You can abort or terminate individual services.

Concurrent Manager Service Status

For concurrent managers, the following information is shown:

General

Processes

Concurrent Requests

Processes

The Processes page shows information on the concurrent processes of a service instance. You navigate to this page from the Service Instances page for a service.

Navigation: Site Map - Administration > Service Status (under Application Services) > (Services region) [Service] > (B) View Processes

You navigate to this page from the Service Instances page for a service.

The following information is given for each process:

You can use the buttons to view the following:

This page can be added to the Support Cart.

Service Instances for a Service Manager

This page shows you information on service instances for a service manager. Service managers perform actions on behalf of the Internal Concurrent Manager (ICM). They are controlled automatically by the ICM as needed and cannot be manually controlled.

Navigation: Applications Systems > System Activity > (Services region) Service Manager

The following information is displayed:

You can use the buttons at the top to perform the following on a selected service instance:

Service Instances for the Internal Concurrent Manager

This page shows you information on the service instance for the Internal Concurrent Manager (ICM).

Navigation: Applications Systems > System Activity > (Services region) Internal Concurrent Manager

The following information is displayed:

You can use the buttons at the top to perform the following on the service instance:

Controlling Service Instances

You can select the service instance and use the drop down menu above the table to perform the actions below.

Stop

You can stop (deactivate) an individual service.

When you stop the Internal Concurrent Manager, all other managers are deactivated as well. Managers previously deactivated on an individual basis are not affected.

Any service that was active when the ICM was stopped will be restarted when the ICM is brought back up. Managers that were deactivated on an individual basis will not be brought back up with the ICM.

Stop All

Use this function to stop all services.

Stop Selective

Use this function to select which services you want to stop, and then stop only those services.

Abort

You can abort or terminate individual services.

When you abort (terminate) requests and terminate the Internal Concurrent Manager, all running requests (running concurrent programs) are terminated, and all managers are terminated. Managers previously deactivated on an individual basis are not affected.

Any service that was active when the ICM was aborted will be restarted when the ICM is brought back up. Managers that were deactivated on an individual basis will not be brought back up with the ICM.

Verify

The Internal Concurrent Manager periodically monitors the processes of each concurrent manager. You can force this process monitoring, or PMON activity, to occur by choosing the Verify action.

Status Overview

System Activity - Status Overview

This page displays a list of the system's application tier services and their statuses. It also lists the number of actual processes and target processes.

Navigation: Applications Dashboard > System Activity (drop-down menu)

You can select a service and use the View Details button to view more information on that service, as well as perform certain actions on them.

Click the View All button to see all services listed. Click the View Set button to view the listing in sets of ten.

Click on the Activity Monitors tab to see information on Database Sessions and Concurrent Requests.

Service Instances for the Conflict Resolution Manager

This page shows you information on service instances for the Conflict Resolution Manager (CRM).

Navigation: Applications Systems > System Activity > (Services region) Conflict Resolution Manager

The following information is displayed:

You can use the buttons at the top to perform the following on a selected service instance:

Controlling Service Instances

You can select a service instance and use the drop down menu above the table to perform the actions below. Or you can use the drop down menu at the top right to perform a single action on all service instances.

Verify

You can use the Verify option for the Conflict Resolution Manager to force it to "re-cache" its information on incompatibilities among concurrent programs. Concurrent programs may be defined to be incompatible with other programs; that is, they should not run simultaneously with each other because they might interfere with each other's execution.

The Conflict Resolution Manager will also re-cache its information on users. A user may be assigned a maximum number of requests that may be run simultaneously using the "Concurrent: Active Requests Limit" profile option. The Conflict Resolution Manager rebuilds its list of users when you choose Verify.

Service Instances for a Scheduler/Prerelease Manager

This page shows you information on service instances for a Scheduler/Prerelease Manager. The Scheduler checks for and manages requests with advanced schedules.

Navigation: Applications Systems > System Activity > (Services region) Scheduler/Prerelease Manager

The following information is displayed:

You can use the buttons at the top to perform the following on a selected service instance:

Controlling Service Instances

You can use the dropdown list to Verify a Scheduler/Prereleaser Manager.

Service Instances of an Internal Monitor

This page shows you information on service instances for an Internal Monitor. The purpose of an Internal Monitor is to monitor the Internal Concurrent Manager and restart it when it exits unexpectedly.

Navigation: Applications Systems > System Activity > (Services region) Internal Monitor

The following information is displayed:

You can use the buttons at the top to perform the following on a selected service instance:

To create a new service instance, use the Create New button.

Controlling Service Instances

You can select a service instance and use the drop down menu above the table to perform the actions below. Or you can use the drop down menu at the top right to perform a single action on all service instances.

Start

You can start (activate) a service instance.

Stop

You can deactivate individual services. Once deactivated, a service does not restart until you select the service and choose the Start button.

Abort

You can abort or terminate individual services.

Service Instances of a Transaction Manager

This page shows you information on the transaction manager. service instances.

Navigation: Site Map > Transaction Managers (under Application Services)

The following information is displayed:

You can use the buttons at the top to perform the following on a selected service instance:

To create a new service instance, use the Create New button.

Transaction Manager Diagnostics

The following features can help you diagnose transaction manager issues:

Set Debug Level

Use the drop-down list to set the debug level for the transaction manager. Choose one of the following options and click the Set Debug Level button. This will set the debug level for all Transaction Managers and will be enabled for future sessions.

Time Transaction Manager

If a transaction manager is performing poorly, use the Time Transaction Manager feature to help diagnose the source of the problem. The Time Transaction Manager test reports the time consumed by each activity involved in a single transaction.

To run the test, select a transaction manager and click the Time Transaction button. This will invoke the Time Transaction Manager launch page. Click the Run Test button. The test results page will display the following information:

From this screen, click Finish Test to return to the Service Instances page, or click Purge to purge the debug information for the session.

Controlling Service Instances

You can select a service instance and use the drop down menu above the table to perform the actions listed below. Or you can use the drop down menu at the top right to perform a single action on all service instances.

Start

Starts (activates) a service instance.

Stop

Deactivates individual services. Once deactivated, a service does not restart until you select the service and choose the Start button.

When you deactivate a manager, all transaction requests currently running are allowed to complete before the manager shuts down.

Restart

When you restart a transaction manager, its processes are shut down and then brought back up.

Abort

You can abort or terminate individual services.

OAM Generic Collection Service

The OAM Generic Collection Service is a generic service managed by Generic Service Management. It provides file uploading, signaling, purging, and other management for other service runtime processes such as the Forms Listener runtime process.

A running instance of the OAM Generic Collection service includes a main process which uses the java service cartridge API to consume the messages in the Generic Service Management Advanced Queue (AQ). After the service instance is started, it spawns four subprocesses:

There is only one OAM Generic Collection Instance running per application system per node.

The OAM Generic Collection Service takes these parameters:

Concurrent Processing Charts and Reports

Concurrent Processing Charts

Main Navigation Path: Site Map > Monitoring (subtab) > Performance (heading) > Concurrent Processing Charts (link)

Overview

Oracle Applications Manager offers a number of configurable charts for monitoring the performance of concurrent processing.

There are the following groups of charts:

In the Concurrent Requests group, there are several charts, such as "Current Requests by Status," "Running Requests per Application," and "Pending Requests per Responsibility". In the Concurrent Managers group, there are charts such as "Pending Requests per Manager". In the Utilization group, there is a chart that depicts how many running requests and available processes exist per manager.

To view a chart, click its name in the table. In some cases, the charts are interactive and you can drill down on a particular bar or segment to see more details.

To set up a chart, click the Chart Setting icon. On the Change Chart Settings page, you can modify the chart type, refresh interval, and data items of a chart.

Concurrent Processing Activity Reports

Navigation: Site Map - Monitoring > Concurrent Processing Reports (under Usage)

Launch the Concurrent Processing Activity Reports from this page. The concurrent processing statistics reports enable you to analyze historical trends relating to request runtimes, success rates, and individual user requests.

Concurrent Request Statistics by Program

Navigation: Site Map - Monitoring > Concurrent Processing Reports (under Usage) > Concurrent Request Statistics by Program

This report summarizes concurrent request statistics by program. These statistics can be useful when scheduling requests or balancing load across nodes (using specialization rules). This report is based on data in the fnd_concurrent_requests table, and is limited to the data in that table since the last time the table was purged using the "Purge Concurrent Request and/or Manager Data" concurrent program.

By default, the report displays data for the past week. Use the Search Criteria region to filter the results based on Application, Minimum Duration, and the reporting time period. The default sort order is by Total duration in descending order. All duration values are in minutes.

You can select a row for a concurrent program and click the Requests button to drill down to the Search Results page showing the list of requests.

Concurrent Request Statistics by Username

Navigation: Site Map > Concurrent Processing (under Activity) > Concurrent Request Statistics by Username

This report summarizes the concurrent request statistics by username. These statistics can be useful to determine the usage pattern of different users. The columns displayed in the report are:

By default, the report displays data for the past week grouped by username. Use the Search Criteria region to filter the results based on Username, Minimum Total Runtime, and the reporting time period.

You can select a row for a username and click the Requests button to drill down to the Search Results page showing the user's list of requests.

User Details

This page is accessed by drilling down on the Username field from those pages which display it.

The following contact information is displayed for the username (if available). Data is retrieved from the FND_USER table

Programs Usage Statistics Report

Navigation: Site Map > Monitoring > Concurrent Processing Reports (under Usage) > Programs Usage Statistics Report

This report provides a summary of statistics on concurrent programs. Summary information is collected when a request is completed, and stored in the table fnd_conc_prog_onsite_info.

Filter the display on this page by Application or Program name.

Note: Statistics recorded here are as of the Reset Date. The reset date can be viewed on the Program Runtime Statistics page.

The report includes the following fields:

By default, the report is ordered by Times Run in descending order. Click the View Details button to display the Program Runtime Statistics page for the selected program.

Program Runtime Statistics

The following fields are shown for the concurrent program selected from the Concurrent Program Statistics by Name page:

Viewing Concurrent Requests in Oracle Applications Manager

Oracle Applications Manager enables you to view details of concurrent requests. You can view concurrent requests by category or search for requests by specified criteria.

The Concurrent Requests pages can be accessed at:

Site Map > Monitoring > Concurrent Requests (under Current Activity)

Completed (Last Hour) Concurrent Requests

Choose either Table View or Chart View. The Chart View displays a graph of the completed requests by Status.

The Table View displays the following fields:

Also, you can click on "Show" under the Details column to see additional details for a request, such as

Use the buttons to perform the following:

Inactive Requests

The list of inactive requests is shown with the following information:

Also, you can click on "Show" under the Details column to see additional details for a request, such as

Use the Remove Hold button to remove a hold on the inactive request.

Use the buttons to perform the following:

Pending Requests

Choose either Table View or Chart View. The Chart View displays a graph of the completed requests by Status.

The Table View displays the following fields:

Also, you can click on "Show" under the Details column to see additional details for a request, such as

Use the buttons to perform the following:

Running Requests

Choose either Table View or Chart View. The Chart View displays a graph of the completed requests by Status.

The Table View displays the following fields:

Also, you can click on "Show" under the Details column to see additional details for a request, such as

Use the buttons to perform the following:

Concurrent Request Diagnostics

For completed, inactive, pending, and running requests, the following information is shown:

Request Status

Run Times

This portion of the screen shows run time statistics for running, completed, and pending requests. All times are displayed in seconds.

Waiting on Following Requests

This region of the page displays requests that are incompatible with the selected pending, running, or inactive request. Shown for each request are the following fields:

You can perform the following actions on the requests listed:

Internal Manager Environment

This page shows the environment variables and their values for the ICM environment. You can search for a particular variable using the filter.

Concurrent Processing Command-Line Utility (cpadmin)

The command-line utility cpadmin consolidates various existing utilities for concurrent processing into a single menu-based utility. This adadmin-style utility can be used for multiple tasks, including:

Manager Status

This option is used to view the status of concurrent managers and services.

Use this option to display running managers (with or without process IDs) or display all managers.

The same status information is shown in Administer Concurrent Managers form and OAM Concurrent Managers page.

Clean CP Tables

Use this option to clean up the concurrent processing tables. This utility replaces cmclean.sql.

Use this option when the Internal Concurrent Manager (ICM) fails to start due to corrupted/conflicted tables.

Note the following actions when choosing this option:

  1. Managers must be stopped first (the utility will verify this).

  2. Clean up inconsistencies in manager tables; remove corruption.

  3. Reset manager states for clean start-up.

  4. Clean and reset Advanced Queue tables for the Output Post-Processor and FNDSM Service Manager.

  5. Reset request conflicts for the Conflict Resolution Manager (CRM).

  6. Identify and clean orphaned requests.

This option is supported by Oracle for use on client systems.

Important: DO NOT USE the cmclean.sql script.

Set Manager Diagnostics

Turn diagnostics on or off for individual managers with this option. You can use this option to turn diagnostics on/off for specific managers without bouncing all services.

This option is available for:

  1. ICM

  2. CRM

  3. Output Post-Processor

  4. Request Processing Managers

  5. Transaction Managers

Each option will display the current diagnostic status (ON or OFF) of the running managers/services and allow you to change the status.

Manager Control

Use this option to send a request such as start, stop, or verify to an individual manager.

Use to send a control request to a manager or service.

  1. Displays current status of all managers and processes.

  2. Once manager or service is chosen, offers valid control options for that specific choice.

  3. Valid options for managers: activate, deactivate, verify, restart, abort, shut down.

  4. Valid options for services also include: suspend and resume. Any service can be programmed to respond appropriately to each option; but if one is not, then the service will not respond.

Rebuild Manager Views

Use when Manager Views must be rebuilt.

This option rebuilds the FND_CONCURRENT_WORKER_REQUEST and FND_CONCURRENT_CRM_REQUESTS views with the following steps:

  1. Managers must be stopped first. The utility verifies that these are stopped.

  2. Rebuilds FND_CONCURRENT_WORKER_REQUESTS.

  3. Rebuilds FND_CONCURRENT_CRM_REQUESTS.

Running this option is the same action as running FNDCPBWV.

Move Request Files

Change request log and output file locations with this option.

Use to update the concurrent processing tables for changing the following values for request LOG file, OUT file, or BOTH:

Important: The cpadmin utility changes only the concurrent processing database table values to support movement. The files must be manually moved by an administrator.

Analyze Request

Use this option to analyze a concurrent request.

Use when analyzing a request for any reason. This is non-destructive.

Managers need not be shut down for this option.

This option does the following:

  1. Checks manager's status.

  2. Analyzes request's status.

  3. Provides detailed report on concurrent program.

  4. Gives detailed report on request's current status.

Choose Request Log and Out File Directory Management Option

Use to display or change the option for log/out file directory management.

This option can be used to:

  1. Display the current APPLLDM scheme in use based on environment variable.

  2. Show each scheme available with a brief explanation allowing the user to choose a different option: date, mgrproc, orgid, product, reqidexp, reqidmod, reqidn, single, user.

Important: After this utility is successfully completed, a system administrator must run AutoConfig and restart the services. In particular, the concurrent managers must be restarted for the change to take effect.

Administrators should refer to the section Log and Output File Names and Locations for details of each scheme.

Running cpadmin

Complete the steps below to run the command-line utility and its maintenance tasks.

  1. Set the environment.

    You must set the environment in order to apply the environment variables that define your system. This task is common to many utilities. See Setting the Environment, Oracle E-Business Suite Maintenance Guide for the preparatory steps.

  2. From any directory, start cpadmin with this command:

    $ cpadmin.sh

    The utility starts and prompts you for the APPS password (required).

  3. Respond to prompts.

    Supply the information requested by cpadmin prompts. Prompts unique to an option are described with the option.

    When you complete the prompts, the Main Menu appears.

  4. Choose one of the tasks listed above.

  5. Exit the cpadmin utility.

Multilingual Support for Concurrent Requests

Users can submit a single concurrent request for a single concurrent program to be run multiple times, each time in a different language. Any output that is produced can be routed to different printers based on language. Users can also route completion notifications based on the language of the output.

For example, a user could submit a request for a Print Invoices program that would cause that program to run several times, each time in a different language, with each set of invoices printed on a different printer.

When submitting requests with multilingual support (MLS), separate requests are actually submitted; one request for each language. To distinguish these requests in the UI, such as the Monitor Requests page, the request names are prefixed with "<ISO language code>-<territory>".

Request Submission

A concurrent program can have a Multilingual Support (MLS) function associated with it. This function determines the set of languages over which the concurrent program will run. For example, the developer might associate a function with a Print Invoices program that would cause any request for that program to run in the preferred languages of the customers who have pending invoices.

If the concurrent program does not have an MLS function associated with it, then a user can choose when submitting the request the list of languages in which the program should run. The language of the current session is the default language.

If a concurrent program does have an MLS function associated with it, users will not be able to select languages for their requests. The associated MLS function determines the languages in which the request will run.

Note: A concurrent program with an associated MLS function should have the "Use in SRS" box checked. If the "Use in SRS" box is not checked then the MLS function will be ignored. See: Concurrent Programs Window.

Runtime Behavior

Multilingual requests behave similarly to request sets. A user submits a single request. When that request runs, it submits a child request for each language in its list of languages. The parent request remains in the Running/Waiting state until its child requests are completed. If any child request completes with error status, then the parent request completes with error status. If no children complete with error status, but one or more completes with warning status, then the parent completes with warning status. Finally, if all children complete with normal status, then the parent completes with normal status.

MLS Functions

Developers can create an MLS function for concurrent programs. The MLS function determines in which of the installed languages a request should run. For example, an MLS function for a Print Invoices program could require that any request for that program to run only in the preferred languages of the customers who have pending invoices. This restriction saves system resources by assuring that the request does not run in languages for which no output will be produced. This restriction also prevents user error by automatically selecting the appropriate languages for a request.

MLS functions are PL/SQL stored procedures, written to a specific API. When the concurrent manager processes a multilingual request for a concurrent program with an associated MLS function, it calls the MLS function to retrieve a list of languages and submits the appropriate child requests for each language. The concurrent program application short name, the concurrent program short name, and the concurrent request parameters are all available to the MLS function to determine the list of languages that the request should be run in.

Beginning with Release 12.1, MLS functions can also support multiple territories and numeric character settings (",." for example).

MLS functions are registered in the Concurrent Program Executable form. A registered MLS function can be assigned to one or more concurrent programs in the Concurrent Programs form.

Related Topics

Oracle E-Business Suite User's Guide

Oracle E-Business Suite Concepts Guide

Oracle E-Business Suite Developer's Guide

Multiple Organizations Reporting

The Oracle E-Business Suite organization model dictates how transactions flow through different organizations and how those organizations interact with each other. You can define multiple organizations and the relationships among them in a single installation of Oracle E-Business Suite. These organizations can be sets of books, business groups, legal entities, operating units, or inventory organizations.

Multiple organizations reporting improve reporting capabilities of Oracle E-Business Suite products by allowing reporting across operating units.

Understanding Operating Units

An operating unit is an organization that uses Oracle Cash Management, Order Management and Shipping Execution, Oracle Payables, Oracle Purchasing, and Oracle Receivables. An operating unit is associated with a legal entity and may be a sales office, a division, or a department. Information is secured by operating unit for these applications and each user sees information only for their operating unit. To run any of these applications, you choose a responsibility associated with an organization classified as an operating unit.

Note: The profile option MO:Operating Unit links an operating unit to a responsibility. You must set this profile option for each responsibility.

Running Reports

To run reports using multiple organizations reporting:

  1. Navigate to the Submit Requests page.

  2. Choose the report that you want to run.

    A list of available operating units displays.

  3. Choose the operating unit for this report.

  4. Continue scheduling and submitting the request as usual.

Related Topics

Oracle E-Business Suite Multiple Organizations Implementation Guide

The Output Post Processor

Concurrent processing uses the Output Post Processor (OPP) to enforce post-processing actions for concurrent requests. Post-processing actions are actions taken on concurrent request output. An example of a post-processing action is that used in publishing concurrent requests with XML Publisher. For example, say a request is submitted with an XML Publisher template specified as a layout for the concurrent request output. After the concurrent manager finishes running the concurrent program, it will contact the OPP to apply the XML Publisher template and create the final output.

The OPP runs as a service that can be managed through Oracle Applications Manager. One service instance of the OPP service is seeded by default. This seeded OPP service instance has one work shift with one process.

A concurrent manager contacts an available OPP process when a running concurrent request needs an OPP processing action. A concurrent manager uses a local OPP process (that, is, on the same node) by default, but will choose a remote OPP if no local OPP process is available.

There should always be at least one OPP process active in the system. If no OPP service is available, completed requests that require OPP processing will complete with a status of Warning.

An OPP service is multi-threaded and will start a new thread for each concurrent request it processes. You can control the number of simultaneous threads for an OPP service instance by adjusting the Threads per Process parameter for the instance. If all the OPP services have reached their respective maximum number of threads, the requests waiting to be processed remain in a queue to be processed as soon as threads become available. If request throughput has become slow, you may want to increase the number of threads per process for the OPP. It is recommended that you keep the number of threads per process between 1 and 20.

Delivery Options for Concurrent Request Output

Oracle XML Publisher offers a feature called Delivery Manager which delivers documents through e-mail, fax, and other delivery channels. This capability is present for single requests and request sets using the Forms-based request submission UI, and for single requests in the HTML-based request submission UI.

Users can direct the output of their concurrent requests to any of the channels that Delivery Manager supports. A user can use the Preferences Page to set the email server user and email server password, so that Delivery Manager can connect to the email server on the user's behalf to deliver the reports through email.

For more information on Delivery Manager and related setup in Oracle XML Publisher, see the Oracle E-Business Suite online help.

Note: Delivery options using the HTML-based request submission UI is not supported currently for request sets.

In the Forms-based Standard Request Submission (SRS) window, users can enter their delivery options in a Delivery Options window available from a button in the "Upon Completion ... region in the SRS window. In the HTML-based request submission UI, delivery options in the Delivery step.

The following delivery channels are possible:

Request Submission

At the time of request submission, a user can enter details for the chosen delivery option(s) as described below.

IPP Printer

E-mail

The email delivery option requires that an Simple Mail Transfer Protocol (SMTP) host and port be defined in the profiles FND: SMTP Host (FND_SMTP_HOST) and FND: SMTP Port (FND_SMTP_PORT), respectively. The profile values for these can be viewed and updated on the site and user level by a System Administrator, and can be viewed and updated by users themselves.

To add a recipient for the e-mail, the user must click the Add Another Row button and add recipients.

Fax

Printers that support faxing must be registered. See: Managing Delivery Options.

The Fax option here will list only those IPP printers that support faxing.

If different fax servers or languages are desired, additional rows can be used.

FTP

Both FTP and SFTP are supported. Secure FTP is indicated by checking the box "Secure FTP". Only password-authenticated SFTP is supported.

Additional rows can be used for sending output to additional servers.

WebDAV

Enter the following for WebDAV.

Additional rows can be used for sending output to additional servers.

Custom

This option can be used if a custom delivery type has been registered in the Create Delivery Option page.

Enter the following:

Additional rows can be used to specify more custom delivery commands.

Managing Delivery Options

Use the Manage Delivery Options page available under the System Administration responsibility to search for, register, update, or delete these options.

To search for a delivery option

You can search by delivery type.

You can search by the delivery name given by the user at the time of the delivery option creation.

To create (register) a delivery option of type IPP

  1. Enter a delivery name.

  2. Enter a delivery type. Choose 'IPP Printer'.

  3. Enter a host name an port. (Required)

  4. Enter a username and password.

    A system administrator can enter a default username and password which can be overridden by a user during request submission.

  5. Enter a printer name. (Required)

  6. Enter the number for sided printing.

    The lookup codes in the following table are used:

    Lookup Codes for Sided Printing
    Lookup Code Meaning
    1 One-sided printing
    2 Two-sided printing
  7. For the options Authentication, Encryption, Use Full URL, and Use Chunked Body, check the boxes as needed. These features are documented in the Delivery Manager documentation in the Oracle XML Publisher online help.

  8. If the IPP Printer supports faxing, then the Support Fax box should be checked. This option will be used to enable the LOV for the fax server in the SRS Fax tab.

To create (register) a delivery option of type Custom

  1. Enter a delivery name.

  2. Enter a delivery type. Choose 'Custom'.

  3. Provide a custom command, using the syntax {file} for the output filename.

To update a delivery option

You can update a delivery option definition except for the delivery name and delivery type. These fields are read-only.

You can select a delivery option to update from the search results table in the Search page.

To delete a delivery option

You can delete a delivery option by selecting the Delete icon for it in the Search page. A confirmation message will be shown before deletion.

Reviewing Requests, Request Log Files, and Report Output Files

This essay explains how you, as System Administrator, can view and change the status of concurrent requests, and how to view request log and report output files.

How To View Request Status and Output

Use any of the following methods to view the status and output of concurrent requests.

Use the Requests Window

Use the Requests window to view the status of concurrent requests, and to view request log and report output files.

The System Administrator and Oracle Alert Manager have a privileged version of the Requests window that provides you with more capabilities than your end users. For example, using the Requests window, you can view the status of and log files for all concurrent requests (not just your own), including requests that completed unsuccessfully. On some platforms, you can even view the log files of running requests.

Using the same window, you can view your own report output online. You cannot, however, view report output from other users' requests.

From the Requests window, you can also:

Run the Completed Concurrent Requests Report

You can run a report that lists parameters and any error messages associated with concurrent requests that have completed running. See: Completed Concurrent Requests Report.

Setting End User Report and Log File Access Privileges

The user profile option Concurrent:Report Access Level determines report output file and log file access privileges for your end users. As System Administrator, you can set this profile option to either "User" or "Responsibility."

All users can can review the log and report output files from requests that they submitted.

If you set the Concurrent:Report Access Level option to "Responsibility" at the User level, that user can also review the log and report output files from all requests submitted from the current responsibility.

If you set the Concurrent:Report Access Level option to "Responsibility" at the Responsibility level, any user of that responsibility can also view the log and report output files from all requests submitted by any other user of that responsibility.

Defining the Reports Viewer

The Oracle E-Business Suite Report File Viewer is used by default for viewing your text report files. You can also display text files in a browser or use another application such as Microsoft Word. You define your default viewer by setting a profile option.

Set the Viewer:Text Profile Option

If the Viewer:Text profile option is set to "Browser" then reports are sent to a web browser. If this profile option is left blank, the Report File Viewer is used instead.

If this profile option is left blank, a report or log file can still be viewed in a browser by first viewing it using the Report File Viewer, and then choosing "Copy File..." from the Tools menu.

Viewing HTML Report Output

You can view your reports with HTML output in a browser. Once an HTML report has been sent to a browser, it can be saved to the desktop by using the Save As functionality of the browser.

Note: HTML reports are displayed by the browser in the character set of the server. This character set may or may not match the character set on the client. Therefore, it may be necessary to convert the output to the client character set when saving the report. If the browser supports character set conversion with Save As, there will be a poplist in the Save As dialog box. The user can then choose an encoding which matches the client character set.

Online Report Review using Other Applications

You can set up your Online Report Review implementation to enable viewing output files in other applications, such as Microsoft Word or Excel. To do this you associate MIME types with file output formats.

Users can then set their preferred MIME types for particular output formats using profile options, or the users may be prompted to choose the appropriate MIME type for a file at runtime.

You can register more than one MIME type file format with each output format. In the Viewer Options window, you enter in the file format, the MIME type, whether you want to utilize the value of the FND: Native Client Encoding profile option, and a description. The description is displayed to the user in the Profile Values window and the Submit Request form.

If the Allow Native Client Encoding box for the associated MIME type has been checked in the Viewer Options window, the Report Viewer will convert the output file into the character set specified by the profile option FND: Native Client Encoding.

When the report is viewed, it is first sent to a browser. The browser then uses the associated MIME type to display the report.

Important: For printing, if users choose either HTML or PDF as the output type with Oracle Report programs, they must use appropriate printer drivers to handle the PDF and HTML file for printing their output. See: Overview of Printers and Printing.

Note: For PDF files, the Adobe Acrobat Reader application must have options set as described below:

See: Viewer Options Window

Changing the Status of Concurrent Requests and Request Sets

This essay explains how to change a request's phase and status, and how to change the priority of a Pending or Inactive request. It also discusses how to restart request sets and how to prioritize requests by placing request sets on hold.

Changing a Request's Phase and Status

A request is in one of four phases: Pending (waiting to be run), Running, Completed, or Inactive (unable to run). Within each phase, a request's condition is referred to as its status.

You can change the phase of a Pending, Running, or Inactive request by changing its status.

Pending and Inactive Requests

You may cancel Pending and Inactive requests. The request's phase and status becomes Completed - Cancelled.

You may place on hold Pending and Inactive requests. The request's phase and status becomes Inactive - On Hold. You can reverse this action by later selecting the request removing the hold.

Running Requests

You can terminate Running requests. The request's phase and status becomes Completed - Terminated.

Changing a Request's Status

You can change the status of a request, and its resulting phase, using the Requests window.

Changing the Priority of a Pending or Inactive request

Requests normally run according to start time, on “first-submitted, first-run" basis. However, a higher priority request starts before an earlier request.

As System Administrator, you can change the priority of any Pending or Inactive request using the Requests window.

Request Priority is associated with an application User

The priority of a user's requests defaults to the value you, as System Administrator, set for their Concurrent:Priority user profile option. Users cannot change the priority of their requests.

If a concurrent program has a defined priority, that priority overrides the user's profile option.

Related Topics

Overview of Concurrent Processing

Life cycle of a concurrent request

Concurrent Processing User Profile Settings

Managing Request Sets

This section discusses how to restart request sets and how to yield a request set to higher priority requests.

Restarting Request Sets

If a request set completes with a status of Error, the Restart button, on the Oracle Applications Manager - View Completed Requests page is enabled. The system also automatically captures, records, and saves the information of the first stage that fails so that when the user clicks on the Restart button the request set can restart from that point.

Once the stage has been identified, the request set program submits the stage program in resubmit mode. In this mode, the program looks at the same stage from the previous run and determines which programs need to be rerun, (only those that ended in error), and runs those programs. If this stage completes successfully or has a Warning status, the system proceeds to the next stage using the normal mechanism of restarting the request set program.

Note: Users may restart a request set multiple times. The logs for each stage and individual programs are maintained independent of the number of runs as each stage and program submission generates a new request. However, the logs and associated files for a request set are rewritten each time the set is restarted.

Holding Request Sets

In some circumstances, such as when a request set has a large number of stages and takes a long time to execute, administrators may want to yield a request set to higher priority requests. By utilizing the Hold Request Set feature, users can place a running request set on hold and effectively control the execution of request set stages.

The Hold and Remove Hold buttons are available on the OAM View Running Requests page. To hold a request set, simply select the request set and click the Hold button. Click Remove Hold when you want the request set to continue executing.

Managing Concurrent Processing Files and Tables

This section explains how to maintain the number of log and output files the operating system retains, and how to manage Application Object Library database tables that store information about concurrent requests and concurrent manager processes.

The database tables that are affected by running the Purge Concurrent Request and/or Manager Data program are:

FND_CONCURRENT_REQUESTS

This table contains a complete history of all concurrent requests.

FND_RUN_REQUESTS

When a user submits a report set, this table stores information about the reports in the report set and the parameter values for each report.

FND_CONC_REQUEST_ARGUMENTS

This table records arguments passed by the concurrent manager to each program it starts running.

FND_DUAL

This table records when requests do not update database tables.

FND_CONCURRENT_PROCESSES

This table records information about Oracle E-Business Suite and operating system processes.

FND_CONC_STAT_LIST

This table collects runtime performance statistics for concurrent requests.

Maintenance Suggestions

Your MIS department and application users should agree on an archiving and file retention policy that is appropriate for your organization. To avoid running out of space on your disk drives, you should periodically delete Oracle E-Business Suite log files and output files.

Tip: You can run the program "Purge Concurrent Request and/or Manager Data" once and automatically resubmit the program for you at specific time intervals.

There are some sample guidelines for when to run the Purge Concurrent Requests and/or Manager Data program. Adopt these guidelines according to your user community's usage of Oracle E-Business Suite.

Purging removes Audit data

When you purge concurrent request information, you lose audit details. The Signon Audit Concurrent Requests report uses this audit information.

Concurrent Processing User Profile Settings

This essay explains the user profile option settings relevant to submitting concurrent requests.

Setting Concurrent Processing Options

End users can control certain runtime options for their concurrent requests. For example, you can choose a specific date on which to start a request.

If a user does not explicitly enter these options at the time of the request, concurrent processing options default to their user profile values.

As System Administrator, you set user profile values for your end users with the System Profile Values window. Both you and your end users can set some of your own profile values using the Personal Profile Values form.

Changing Concurrent Processing Options for submitted requests

You or your users can use the Requests window to change the concurrent processing options for a submitted request up until the time it starts running.

The following table lists the concurrent processing user profile options and an explanation of each:

Concurrent Processing User Profile Options
User Profile Option Explanation
Concurrent: Hold Requests "Yes" places concurrent requests on hold. "No" starts programs according to the request's priority and start time.
Concurrent: Multiple Time Zones "Yes" ensures that requests are scheduled immediately regardless of the time zone your client is running in.
Concurrent: Report Access Level Viewing a request's output/log files online and reprinting reports can be accessed according to: "Responsibility" - by anyone using the responsibility that submitted the request "User" - by only the user who submitted the request.
Concurrent: Report Copies The number of output copies that print for each report.
Concurrent: Request Priority Requests normally run according to start time, on a "first-submitted, first-run" basis. Priority overrides request start time. A higher priority request starts before an earlier request. Priorities range from 1 (highest) to 99 (lowest). The standard default is 50.
Concurrent: Request Start Time The date and time requests are available to start running. If the start date and time is at or before the current date and time, requests may be run immediately.
Concurrent: Save Output "Yes" saves concurrent program outputs in a standard file format. Some concurrent programs do not generate an output file.
Concurrent: Sequential Requests "Yes" forces requests to run one at a time (sequentially) according to the requests' start dates and times. "No" means requests can run concurrently when their concurrent programs are compatible.
Concurrent: Wait for Available TM You can specify the maximum number of seconds that the client will wait for a given transaction manager (TM) to become available before moving on to try a different TM.
Concurrent: URL Lifetime This profile option determines the length of time in minutes a URL for a request ouput is retained before it is deleted from the system.
Printer The printer which prints your reports.

Updating Concurrent Request Profile Options

Most concurrent user profile options may be set by the System Administrator at all four levels: site, application, responsibility, and user. The user profile Concurrent:Report Access Level may not be set at the application level.

Your users can change the default values for most of the concurrent processing profile options. However, they cannot set Concurrent: Request Priority, or Concurrent: Report Access Level.

Related Topics

Overview of Concurrent Processing

Purge Concurrent Request and/or Manager Data Program

Use this program to delete:

Report Options

Report options are:

Entity

Variable Description
All Purges records from database tables that record history information for concurrent requests, history information for concurrent managers, and purges request log files, manager log files, and report output files from the operating system.
Manager Purges records from database tables that record history information for concurrent managers, and purges manager log files from the operating system.
Request Purges records from database tables that record history information for concurrent requests, and purges request log files and report output files from the operating system.

Mode

Variable Description
Age Enter the number of days for which you want to save concurrent request history, log files, and report output files. The purge program deletes all records older (in days) than the number you enter.
For example, if you enter "5", then all concurrent request history, log files, and report output files older than five days is purged.
Count Enter the number of (most recent) records for which you want to save concurrent request history, log file, and report output files. The purge program starts from the most recent records, retains the number you enter, and purges all remaining records.
For example, if you enter "5", then the five most recent concurrent request history records, request log files, manager log files, report output files are saved, and all remaining records are purged.

Mode Value

Enter a value to define the number of days for Mode=Age or the number of records for Mode=Count. The valid values are 1 - 9999999.

Oracle ID

Enter the Oracle ID that concurrent programs connect to for which you want to purge concurrent request records, and associated log files and report output files. Oracle ID has relevance when the Entity is either "Request" or "All".

For example, if you enter AP1, then the program purges all request records, log files, and report output files associated with requests to run programs that connect to the AP1 Oracle ID.

User Name

Enter the application username whose concurrent request records and associated log files and report output files you wish to purge. Username has relevance when the Entity is either "Request" or "All".

For example, if you enter JSMITH, then the program purges all request records, log files, and report output files associated with requests submitted by user JSMITH.

Select the application associated with the responsibility for which you want to purge concurrent request records, and associated log files and report output files. Responsibility Application is used with the Responsibility option, and has relevance when the Entity is either "Request" or "All".

Responsibility

Select the responsibility for which you want to purge concurrent request records, and associated log files and report output files. Responsibility has relevance when the Entity is either "Request" or "All".

For example, if you select the System Administrator responsibility, then the program purges all request records, log files, and report output files associated with requests submitted by users operating under the System Administrator responsibility.

Program Application

Select the application for which you want to purge concurrent request records, and associated log files and report output files. Program Application has relevance when the Entity is either "Request" or "All".

For example, if you select Oracle Payables, then the program purges all request records, log files, and report output files associated with requests to run Oracle Payables programs.

Program

Select the program for which you want to purge concurrent request records, and associated log files and report output files. Program has relevance when the Entity is either "Request" or "All".

For example, if you select Program X, then the purge program purges all request records, log files, and report output files associated with requests to run Program X.

Manager Application

Select the application associated with the concurrent manager for which you want to purge concurrent request records, and associated log files and report output files.

Manager Application is used with the Manager option, and has different effects when Entity is set to "Request, and when Entity is set to "Manager" or "All".

Manager

Select the concurrent manager for which you want to purge concurrent request records, and associated log files and report output files.

Manager is used with the Manager Application option, and has different effects when Entity is set to "Request," and when Entity is set to "Manager" or "All".

Report

Select whether you want a report listing the number of records purged by the Purge Concurrent Request and/or Manager Data program.

Variable Description
No Run the program but do not generate a report.
Yes Run the program and generate a report.

Purge Other

Select whether you want to delete records from the FND_DUAL table.

Variable Description
No Do not delete records from FND_DUAL.
Yes Delete records from FND_DUAL.

Related Topics

Overview of Concurrent Processing

Life cycle of a concurrent request

Reviewing Requests, Request Log Files, and Report Output Files