Managing Concurrent Processing and Concurrent Programs

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.

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.

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.

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.

Concurrent:GSM Enabled Profile Option

The Concurrent:GSM Enabled profile option should be set to Y to enable Service Management. It is set automatically to Y by AutoConfig. Disabling Service Management is not recommended as that may prevent necessary services from starting.

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.

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

Concurrent Request Statistics by Name

Navigation: Site Map > Monitoring > Concurrent Processing Reports (under Usage) > Concurrent Program Statistics by Name

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.

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, Oracle E-Business Suite System Administrator's Guide - Configuration.

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

Multiple Organizations in Oracle E-Business Suite

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. Users can direct the output of their concurrent requests to any of the channels that Delivery Manager supports. 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.

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.

Managing Delivery Options

Use the Manage Delivery Options page available under the System Administration responsibility to search for, register, update, or delete these options. Currently, only the IPP printer delivery type is available.

To search for a delivery option

You can search by delivery type.

Note: Currently, the only delivery type available is IPP Printer 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

  1. Enter a delivery name.

  2. Enter a delivery type.

    Note: Currently, only IPP Printer registration is supported.

  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 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 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, Oracle E-Business Suite System Administrator's Guide - Configuration.

How to Modify Request Diagnostic Output

The Request Diagnostics window provides the user with request status information. This information consists of messages that explain the request's current status.

Collect Runtime Data

Set the profile option Concurrent:Collect Request Statistics to "Yes" to collect runtime statistics.

A concurrent request may be comprised of one or two processes: a Net8i shadow which consumes database server resources, and a front-end process such as a C executable. The time used by the CPU is collected for both of these types of processes.

Summarize and View Runtime Statistics

To review the statistics you must run the Purge Concurrent Request and/or Manager Data program to process the raw data and have it write the computed statistics to the FND_CONC_STAT_SUMMARY table. You can review the statistics on a request by request basis using the Diagnostics window from the Requests window.

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, Oracle E-Business Suite System Administrator's Guide - Configuration.

Note: For PDF files, the Adobe Acrobat Reader application must have options set as described below:

See: Viewer Options Window, Oracle E-Business Suite System Administrator's Guide - Configuration

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.

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, Oracle E-Business Suite System Administrator's Guide - Configuration.

The following table describes control functions for the Internal Manager.

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

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/password as the sysmgr parameter. Alternatively, you could pass an Oracle E-Business Suite username/password as an appmgr parameter. If no sysmgr or appmgr parameter is provided on the command line, startmgr will prompt you for the Oracle password.

See: Setting Up Concurrent Managers, Oracle E-Business Suite System Administrator's Guide - Configuration

Viewing the Internal Concurrent Manager startup parameters

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

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

Shutting down the Internal Concurrent Manager from the Operating System

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

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

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

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

Parameters

Variable Description
username/password The ORACLE username and password that connects to Oracle Application Object Library data. Alternatively, an Oracle E-Business Suite username and password for a user with the System Administrator responsibility.
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/Password> SYSADMIN 'System Administrator'
 SYSADMIN  CONCURRENT FND DEACTIVATE 

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

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

Using CONCSUB to shut down your managers

Use CONCSUB to shut down the concurrent managers:

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

Example - nightly shutdown using CONCSUB

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

See: Controlling the Internal Concurrent Manager from the Operating System

  1. Shell script customized for specific operating system starts.

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

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

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

  4. Script issues the command to backup the database.

  5. Script issues the command to startup the database.

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

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

  7. Shell script completes.

Hiding the password using CONCSUB

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

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

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

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

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

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

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

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.

FND_CONC_STAT_SUMMARY

This table contains the concurrent program performance statistics generated by the Purge Concurrent Request and/or Manager Data program. The Purge Concurrent Request and/or Manager Data program uses the data in FND_CONC_STAT_LIST to compute these statistics.

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.

Managing Parallel Concurrent Processing

This section describes how to manage parallel concurrent processing.

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

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

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

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

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

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

Defining Concurrent Managers

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

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

To each concurrent manager and each Internal Monitor Process, you may assign a primary and a secondary node. You may also assign primary and secondary system queue names, if a platform-specific queue management system is available on your platform. See: Concurrent Managers, Oracle E-Business Suite System Administrator's Guide - Configuration.

Administering Concurrent Managers

Target Nodes

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

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

Control Across Nodes

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

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

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

Starting Up Managers

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

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

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

Shutting Down Managers

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

Terminating Concurrent Processes

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

Migrating Managers

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

Related Topics

Concurrent Managers, Oracle E-Business Suite System Administrator's Guide - Configuration

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:

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

Managing Concurrent Programs and Requests

This section describes reports used in managing concurrent programs and reports. The following topics are covered in this chapter:

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, Oracle E-Business Suite System Administrator's Guide - Configuration

Organizing Programs into Request Sets, Oracle E-Business Suite System Administrator's Guide - Configuration

Concurrent Programs Report

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, Oracle E-Business Suite System Administrator's Guide - Configuration

Organizing Programs into Request Groups, Oracle E-Business Suite System Administrator's Guide - Configuration

Request Groups, Oracle E-Business Suite System Administrator's Guide - Configuration

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, Oracle E-Business Suite System Administrator's Guide - Configuration

Concurrent Program Details Report

Concurrent Programs, Oracle E-Business Suite System Administrator's Guide - Configuration

Purge Concurrent Request and/or Manager Data Program

Use this program to delete:

Use this program to compute performance statistics for each of the concurrent programs, if the Concurrent: Collect Request Statistics profile option is set to "Yes".

Report Options

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