concurrent manager workflow in oracle apps

Concurrent Manager has executes job defined by program executable as per schedule specified during concurrent request submission.

Concurrent manager has below managers helps to processes the concurrent request based on their defined functions

ICM - Internal concurrent manager

SM - Standard manager
CRM - Conflict resolution manager


1> ICM - Internal Concurrent manager

- TO start/stop/reset other concurrent managers

- Should be running prior to other managers

2> SM - Stanadard manager

- To execute concurrent requests which are not defined to run under any specific product manager
e.g. Inventory CRP Inquiry , Receivable Tax manager etc.

3> CRM - Conflict resolution manager

- Responsible to check concurrent programs definistion for incompatible rules
- ICM can be configured to take over CRM's job to resolve incompatiblities 


PMON cycle - Number of sleep cycle to check concurrent manager failure (20)

Queue Size - Number of PMON cycles that ICM waites to detect disable or new concurrent manager (1)

Sleep Time - Time in seconds ICM should wait before checking requests waiting for run (60)

Concurrent request flows through below phases and respective status based on availability of resources or previous stage execution results and in case any external / dependent results/deviations


Pending => Normal/Standby/Scheduled/Waiting/Inactive
Running => Normal/Paused/Resuming/Terminating
Completed => Normal/Error/Warning/Cancelled/Terminated/Disabled
Inactive => Disabled/On Hold/No Manager

Below specifies the general phases with status of a normal concurrent request 

Phase_code~(Manager)~ Status_code



Concurrent manager request workflow:

1> ICM instructs Standard manager (FNDSM) to start concurrent manager process

AOL : Application Object Library
e.g. FNDLIBR -> standard manager
INVLIBR -> Inventory manager

2> manager process connects to database and fetch info such as profile option , sleep seconds , cache size etc.

3> process saves information in FND_CONCURRENT_PROCESS table such as os pid , db name , instance name , db session identifier , logfile etc.

it also updates FND_CONCURRENT_QUEUE with sequence number of running process

4> concurrent manager process collects the info to queue FND_CONCURRENT_REQUEST

- to look for scheduled concurrent requests
- to read specialization rules

Specialization rule may change while manager are running so it gets auto bounced.

5> Build sql from step 4> is executed to get info from FND_CONCURRENT_REQUEST which retries the pending concurrent requests

6> Results are checked to verify if any pending requests waiting for execution 

7> if no pending concurrent requests then go to step 5>. Sleep seconds parameter from work shifts setting determines sleep time for concurrent process before it can query FND_CONCURRENT_REQUEST table again

8> if atleast one concurrent request is pending for execution then concurrent manager cache the rowid from FND_CONCURRENT_REQUEST table.
cache size specifies number of rowid that can be cached

9> The cache list of rowid is checked if any pending request from FND_CONCURRENT_REQUEST else go to step 5> to query table again

10> Next unprocessed rowid is picked from cache and processing starts

11> concurrent manager create exclusive row lock by select-for-update on status_code of FND_CONCURRENT_PROCESS to ensure consistency

12> if status_code of FND_CONCURRENT_PROCESS were locked successfully then process moves to step 9> to execute the pending rowid from cache size

No comments:

Post a Comment