Concurrent Manager Processes Architechture

The current Concurrent Processing architecture with Global Service Management
consists of the following processes and communication model, where each process
is responsible for performing a specific set of routines and communicating with
parent and dependent processes.

Internal Concurrent Manager (FNDLIBR process) - Communicates with the Service
Manager.

The Internal Concurrent Manager (ICM)  starts, sets the number of active processes,
monitors, and terminates all other concurrent processes through requests made to
the Service Manager, including restarting any failed processes.  The ICM also
starts and stops, and restarts the Service Manager for each node.  The ICM will
perform process migration during an instance or node failure.  The ICM will be
active on a single node.  This is also true in a PCP environment, where the ICM
will be active on at least one node at all times.

Service Manager (FNDSM process) - Communicates with the Internal Concurrent Manager,
Concurrent Manager, and non-Manager Service processes.

The Service Manager (SM) spawns, and terminates manager and service processes (these
could be Forms, or Apache Listeners, Metrics or Reports Server, and any other process
controlled through Generic Service Management).  When the ICM terminates the SM that
resides on the same node with the ICM will also terminate.  The SM is ‘chained’ to
the ICM.  The SM will only reinitialize after termination when there is a function it
needs to perform (start, or stop a process), so there may be periods of time when the
SM is not active, and this would be normal.  All processes initialized by the SM
inherit the same environment as the SM.  The SM’s environment is set by APPSORA.env
file, and the gsmstart.sh script.  The TWO_TASK used by the SM to connect to a RAC
instance must match the instance_name from GV$INSTANCE.  The apps_ listener must
be active on each CP node to support the SM connection to the local instance.  There
should be a Service Manager active on each node where a Concurrent or non-Manager
service process will reside.

Internal Monitor (FNDIMON process) - Communicates with the Internal Concurrent
Manager.

The Internal Monitor (IM)  monitors the Internal Concurrent Manager, and restarts any
failed ICM on the local node.  During a node failure in a PCP environment the IM will
restart the ICM on a surviving node (multiple ICM's may be started on multiple nodes,
but only the first ICM started will eventually remain active, all others will
gracefully terminate).  There should be an Internal Monitor defined on each node
where the ICM may migrate.

Standard Manager (FNDLIBR process) - Communicates with the Service Manager and any
client application process.

The Standard Manager is a worker process, that initiates, and executes client requests
on behalf of Applications batch, and OLTP clients.

Transaction Manager - Communicates with the Service Manager, and any user process
initiated on behalf of a Forms, or Standard Manager request.  See Note 240818.1
regarding Transaction Manager communication and setup requirements for RAC.