Concurrent Manager

Internal Concurrent Manager (ICM)
The Internal Concurrent Manager (ICM) can be considered the “brain” of concurrent processing. It is responsible for the following functionality:

-Starts all other processes like Conflict resolution manager,standard manager
-Executes “control requests” submitted by the administrator.
-Activate/Deactivate/Abort Concurrent Manager
-Terminate Concurrent Request
-Monitors processes, restarting any that failed.
-Sets the target number of processes for each service based on the current work shift.

Starting the ICM
-adcmctl.sh script
-TNS Apps Listener must be started before starting ICM

Shutting down the ICM
-Shutting down the ICM will stop all other services like Conflict resolution manager,standard manager
- Normal shutdown signals processes to exit after completing their current tasks.
- Abort will terminate service processes.
-ICM will not exit until all other processes have exited.
-Use adcmctl.sh to shutdown ICM.

Service Managers(FNDSM)
Service Managers are spawned on the middle-tier nodes of a GSM enabled system in order to act as an agent of the ICM. When the ICM sees that it needs An SM to perform some function, such as start a concurrent manager process, on a middle-tier node, it will make remote procedure control calls to the Apps listener on that node to start the Service manager. Once the Service Manager has been started and initialized, the ICM communicates directly to the SM through RPC, giving it information to manage the services on that node.

-The Service manager is spawned from the APPS TNS Listener
- The APPS TNS Listener must be started on every middle-tier node in the system, and started by the user that starts ICM (e.g. applmgr)
-TNS Listener spawns Service Manager to run as agent of ICM for the local node
-The Service Manager is started by ICM on demand when needed. If no management actions are needed on a node a Service Manager will not be started by ICM until necessary. When ICM exits its Service Managers exit as well.
-The Service Manager environment is set by APPSORA.env as defined in listener.ora
-The listener.ora and tnsnames.ora files must be configured properly for the listener to be able to spawn the Service Manager and for the ICM to be able to check the status of the Service Manager.

Internal Monitors(FNDIMON)
Internal Monitors are used specifically in Parallel Concurrent Processing to allow for Internal concurrent manager failover to other available middle tier nodes.

-Place an Internal Monitor on any node where the ICM can start in case of a failure.
-Internal Monitors are seeded on every registered node by default.
-If the ICM goes down, the Internal Monitor will attempt to start a new ICM on the local node.
-If multiple ICMs are started, only the first will stay active. The others will gracefully exit.

Concurrent Managers(FNDLIBR,INVLIBR)
Concurrent Managers provide asynchronous job processing by monitoring the FND_CONCURRENT_REQUESTS table on a continuous cycle. The job of a concurrent manager is to execute concurrent requests that are in Pending / Normal phase / status and that it is qualified to run according to its specialization rules.

Concurrent Manager Processes
- Act independently
- Select only requests that: (a) match the manager specialization rules, (b) are Pending/Normal, (c) have a requested start time <= sysdate
- Including a target implicitly excludes all other targets!
- This could lock out some critical programs, such as the Request Set Master program and Build Worker Request View program

Conflict Resolution Manager(FNDCRM)
Because concurrent requests may have constraints on when and how they run, the Conflict Resolution Manager (CRM) is needed to resolve request conflicts and imposes the constraints. A request may have the following types of constraints:

-Registered incompatibilities between programs
-Run Alone
-Single Threaded
-User Active Requests Limit

A constrained request is submitted with a status of Q (Pending Standby) which is ignored by all CMs. The CRM's job is to release the request by changing the status to I (Pending Normal) so that the CMs will process the request. To release a request, the CRM must make sure that no other incompatible requests have been released or running ahead of this. The CRM may revert a previously released requests status back to Q if higher priority request is to be released.

Transaction Managers
Transaction managers provide synchronous job processing by continually monitoring a DBMS pipe for requests to come through from a client-side application. The job of a transaction manager is to process this job immediately and send information back to the client using the pipe.

-Transaction Managers Provide Synchronous Job Processing
-A client makes a request for a specific transaction manager to run a program, and waits for the results of that program
-Product teams’ programs are linked directly into the transaction manager executables
- PO, CRP, INV, AR, and OE all ship transaction manager

Some important tables for Concurrent manager
FND_NODES
FND_CONCURRENT_PROCESSES
FND_CONCURRENT_REQUESTS
FND_CONCURRENT_QUEUES
FND_CONCURRENT_PROGRAMS
FND_EXECUTABLES
FND_CP_SERVICES
FND_CONCURRENT_QUEUE_SIZE
FND_CONCURRENT_QUEUE_CONTENT
FND_CONCURRENT_PROGRAM_SERIAL
FND_CONCURRENT_TIME_PERIODS
FND_CONCURRENT_PROCESSORS