Concurrent Managers
Concurrent Managers, typically, allow you to execute long running and data intensive application programs asynchronously.
Concurrent Processing
Concurrent
Processing is the running of batch type jobs interspersed
(concurrently) with typical transactional transactions without having
either impact the performance of the other.
In
Concurrent Processing, Concurrent Managers run Concurrent Programs from
Concurrent Program Libraries either on demand or on a set schedule that
is defined in terms of work shifts.
There
are many predefined libraries. Below Table 1.1 gives a few of the
libraries with their executable name and the Concurrent Manager
description that can run the immediate programs.
Table 1.1 Concurrent Manager Executable Descriptions
|
Executable
|
Concurrent Manager Description
|
ARLIBR
|
Receivables Tax Engine.
|
CYQLIB
|
Capacity Manager.
|
FNDCRM
|
Conflict Resolution Manager.
|
FNDIMON
|
Internal Monitor.
|
FNDLIBR
|
Applications Object Library (AOL) — The ICM and the Standard Manager are both members of this library.
|
FNDSCH
|
Scheduler Manager.
|
INVLIBR
|
Inventory Manager Library.
|
MRCLIB
|
Oracle MRP Library.
|
PALIBR
|
Oracle Project Accounting.
|
POXCON
|
Purchase Order Document Approval.
|
RCVOLTM
|
Receiving Transaction Manager.
|
Types of Concurrent Managers
Internal Concurrent Manager
The
Internal Concurrent Manager (ICM) is the controlling manager for all of
the others. When you start the Concurrent Managers, this is the only
one that you actually have direct control over. This manager in turn
starts all of the others depending on their schedules and work shifts.
It controls starting and stopping all other managers based on the
definition of their work shifts and it monitors for failures. If there
are failures, it cleans up after them. Its definition cannot be changed
after its startup. On starting, you can, by parameter passing, set its
values for sleep time, PM ON on cycle, and queue size.
Conflict Resolution Manager
The
Conflict Resolution Manager enforces all compatibility rules and based
on priorities and run rules, determines which jobs can run when if there
is a conflict in timing.
Scheduler Manager
The Scheduler Manager, a manager added in 11i, assists the ICM and the CRM in scheduling and conflict resolution.
Product Specific Concurrent Manager
There
are many product specific Concurrent Managers. The list includes
Inventory, MRP, and Projects, as well as any user-defined managers.
Utilizing these managers can help you off-load some of the processing
from the Standard Manager.
Standard Manager
The
Standard Manager is the manager that ships with the Oracle E-Business
Suite and accepts any and all requests and does not, as configured, have
any specialization rules.
Transaction Managers
Conventional
Concurrent Managers run batch type jobs that are typically long
running, involve large amounts of data, and run asynchronously.
Transaction Managers run synchronous processing of certain reports
requested from a client program but run as a server side program. A
Transaction Manager is owned by an application and associated with a
data group. Due to this association, and the fact that it runs immediate
programs, the Transaction Manager can only run programs contained
within its program library.
Checking the Status of a Manager
Applications Interface Method
Through
the Applications interface, Log into the sysadmin responsibility and
navigate to the Concurrent Manager Administration Page. shows the
navigation screen.
On this screen, check
to make sure that the nonzero numbers in the Target and Actual columns
match. Target is the number of processes that should be running for each
individual manager during the current work shift. The Actual column
shows the number of processes that are actually currently running. If
the number in the Target column is 0, that manager is not scheduled for
this work shift. If the number in the Target column is not 0, but the
number in the Actual column is 0, then you should have processes running
for the given manager, but do not.
SQL Script Method
A
less descriptive method to determine if the Concurrent Manager is
running on the system is to find the afimchk.sql script located in your
$FND_TOP/sql directory and run that script at a SQL prompt:
SQL>@$FND_TOP/sql/afimchk
Operating System Process Method
An
operating Concurrent Manager creates a library process at the OS level
on the Concurrent Manager host server. The ICM creates a process called
FNDLIBR. If you run the following command, you can get an idea of what
library processes you have running on your server.
ps -ef |grep LIBR
Oracle Application Manager Method
Oracle
Applications Manager in the 11i Suite, check on the status of your
Concurrent Managers, define new managers, start and stop managers, and
edit properties of current Concurrent Managers.
The
same Target and Actual columns are available and they provide the same
information as is available through the Concurrent Manager
Administration Page. You can drill out quickly and easily to requests
for each manager, the status for each manager, and the running and
pending request detail. Further, you can start and stop and activate and
deactivate any of the defined managers.
Starting Individual Managers
You
can activate or restart individual managers by changing their status in
the Administer Managers form. Restarting a manager forces the Internal
Manager to go out and reread that manager's definition. Activating a
manager undoes a previous command to deactivate it and allows the
Internal Manager to start it when its next scheduled work shift starts.
Deactivating Individual Managers
Deactivation
can take two different paths. You can either choose to deactivate a
manager and abort all requests that that manager is acting on or you can
choose to allow it to finish its active requests before it shuts down.
Terminated requests are marked for resubmission the next time that the
manager is activated. If a manager is explicitly deactivated, it has to
be explicitly activated and the Internal Manager has to be active at the
time of reactivation.
Concurrent Programs are designed in such a way that regardless of the reason for termination, there will be no data loss.
Verify a Manager's Status
Controlling Internal Manager
You
can control the Internal Manager from the command line of the OS by
using the STARTMGR command to start it or through the CONCSUB command
to deactivate, verify, or abort it. The utility can only be run on the
server on which the Concurrent Managers are running, but can be called
on that server from any other server on the same network.
STARTMGR
STARTMGR
starts the ICM, which in turn starts all Concurrent Managers defined
that should be running for that work shift. To successfully run this
command, you have to be logged into the server with a user ID that has
write privileges to the log directory and the out directory of every
application, otherwise, the Concurrent Manager will be unable to write
some or all of its files. STARTMGR has to be run anytime you have
shutdown the Concurrent Managers, after the server has been rebooted, or
after the database has been restarted.
$ startmgr sysmgr=" apps/apps" mgrname='std"
printer="lpr_finance" mailto="jdoe" restart=" N"
logfile="mymanagerlog" queuesize="15" pmon="10"
sleep="60"
Table 1.2: STARTMGR Command with 10 Optional Parameters
|
Parameter
|
Description
|
Default
|
Sysmgr
|
Apps schema user ID and password.
|
Apps/apps
|
Mgrname
|
Name of the ICM (used for locking purposes).
|
STD
|
Printer
|
Default printer to which you want output sent.
|
No default
|
mailto
|
List of usernames who need to be informed whenever the ICM terminates.
|
Applmgr
|
Restart
|
Should
the manager restart after a crash? Valid values are N (for no) or the
number of seconds that it should wait to restart after abnormal stop.
|
N
|
Logfile
|
User specified file to use for the manager's own log file (not to be confused by the logs for the requests).
|
Std.mgr
|
Sleep
|
Number of seconds for the ICM to wait between checking for new requests in the FND_CONCURRENT_REQUESTS table.
|
60
|
PMon
|
Number
of sleep cycles that the ICM or the CRM will wait before checking for
failed managers. This can be set lower than the default as the PMon
resources that are dedicated to this process does not require such a
long sleep interval.
|
20
|
Quesiz
|
Number
of PMon iterations that the Internal Concurent Manager will wait
while scanning for sudden changes in the number of actively running
Concurrent Manager workers.
|
1
|
Diag
|
Diagnostic output to be produced to aid in debugging. The default (N) provides better performance. Can also be set to Y.
|
N
|
These
commands start the ICM, which in turn starts up the CRM and the
Scheduler Manager, followed by any specialized managers depending on
their work shifts. FND_CONCURRENT_QUEUES and FND_CONCURRENT_QUEUE_SIZE
provide information to the ICM about each manager, its work shift, and
the target number of processes to be started (based on the value in the
MAX_PROCESSES column of the FND_CONCURRENT_QUEUE table). If you want to
verify that there is at least one Concurrent Manager process running on
your server, you can check the Task Manager on Windows for a FNDLIBR
process or ps -ef |grep FNDLIBR on a UNIX platform (ps -ef |grep FNDLIBR
will work on Windows as well, thanks to the running of MKS Toolkit).
FNDLIBR is the program library process that gets spawned when the ICM or
any generic Standard Manager is running on your system. CRM program
library process appears as FNDCRM.
Oracle Support will often have you check for the existence of FNDLIBR processes if it appears that your ICM did not start.
Once
the managers are started on the system, ICM will insert one row into
the FND_CONCURRENT_PROCESSES table for each running manager and one row
for itself and will update the RUNNING_PROCESSES column in the
FND_CONCURRENT_QUEUES table to reflect the actual number of running
processes. When the actual number in the RUNNING_PROCESSES column
matches the target number in the MAX_PROCESSES column, all managers that
are scheduled for the current work shift are running. Each entry in the
FND_CONCURRENT_PROCESSES table identifies the process ID (PID) of the
OS process as well as the process's status code.
CONCSUB
CONCSUB
is a utility for allowing the sysadmin username and password to have
the ability to submit concurrent requests at the OS level. This utility,
unlike many of the Applications utilities, is not menu driven. It runs
from the command line, submits a concurrent request, and returns you to
the command prompt once the concurrent request completes. You can check
the status of your concurrent request via the Concurrent Request form.
The CONCSUB command takes the following form:
CONCSUB applsys/pwd 'responsibility application
shortname' 'responsibility name' 'username' [wait=]
CONCURRENT 'Program application shortname' PROGRAM
Table below defines the parameters and their meaning.
1.3 CONCSUB Parameters and Their Meanings
|
Parameter
|
Meaning
|
Applsys/pwd
|
Oracle application username and password that connects to Applications Object Library.
|
Responsibility Application Short Name
|
Application shortname of the responsibility you want to run the request for.
|
Responsibility Name
|
Name of the responsibility for which you want to run the request.
|
Username
|
Username of the person who is submitting the request.
|
Wait
|
Do you want CONCSUB to wait before returning the OS command prompt?
N (default value) waits until the job completes.
Y returns you to the command prompt.
"n" is the number of seconds to wait before it exits.
If this parameter is used, it has to come before concurrent.
|
Program Application Short Name
|
Short name of the program (for deactivate, abort, and verify, the program application shortname is FND).
|
PROGRAM
|
The program to submit (e.g., DEACTIVATE, VERIFY, ABORT).
|
Example of a CONCSUB command:
Concsub applsys/apps SYSADMIN 'system Administraor'
SYSADMIN concurrent fnd deactivate
You
can use CONCSUB to shutdown Concurrent Managers before the sysadmin
reboots the server, before the database administrator shuts down the
database, or when you need changes to Concurrent Managers to take
effect.
Coming next how to ensure that terminated concurrent request freed up its process at DB and Os level...
~~~ Cheers
