Oracle Concurrent Manager helps in batch processing of tasks. It is essentially a job scheduling and execution system that handles the background processing of non-interactive, time-consuming tasks and reports.
A concurrent manager is itself a concurrent program that starts other concurrent programs running. When an application user submits a request to run a program, the request is entered into a database table that lists all of the requests
How it helps in batch processing:
Scheduling and Queuing:
When users submit requests to run programs (known as "concurrent programs"), these requests are entered into a database table. Concurrent Managers read these requests from the table and manage their execution.
Background Execution:
Concurrent Managers allow these programs to run in the background, freeing up the user's terminal and enabling them to continue with other interactive tasks.
Resource Management:
They manage the allocation of resources by controlling how many concurrent programs can run simultaneously through "target processes."
Specialization and Work Shifts:
Concurrent Managers can be specialized to run specific types of programs or operate within defined work shifts, allowing for optimized resource utilization and controlled execution.
Fault Tolerance and Performance:
In environments with Parallel Concurrent Processing, Concurrent Managers can be distributed across multiple nodes, enhancing performance by running processes in parallel and providing fault tolerance in case of node failures.
Incompatibility Rules:
The Internal Concurrent Manager (ICM), which acts as the "boss" of other managers, enforces incompatibility rules to prevent conflicting programs from running simultaneously.
Types of Concurrent Managers
There are many types of concurrent managers, each governing flow within each Oracle Apps areas. In addition there are "super" Concurrent Managers whose job is to govern the behavior of the slave Concurrent Managers. The main 3 concurrent managers are
- Internal Concurrent Manager
- Conflict Resolution Manager
- Standard Manager
1) The Internal Concurrent Manager (ICM) in Oracle Applications R12 is the central process that manages and monitors all other concurrent managers.
It acts as the "boss" and is responsible for starting, stopping, and resetting individual concurrent managers.
The ICM ensures that other managers are running and functioning correctly, and it can also restart failed managers.
More detailed explanation:
Centralized Control:
The ICM oversees the entire concurrent processing environment.
Manager of Managers:
It starts, stops, and resets other concurrent managers, such as the Standard Manager and Conflict Resolution Manager.
Monitoring and Recovery:
The ICM monitors the status of other managers and can restart them if they fail.
No User Requests:
The ICM does not directly process user requests like reports or other specific tasks.
Service Manager Interaction:
The ICM uses the Service Manager (FNDSM) to manage the lifecycle of other managers.
OS Process:
The ICM's operating system process is named FNDLIBR
2) The Conflict Resolution Manager (CRM) is a crucial component of the Concurrent Processing system. It ensures that incompatible concurrent programs do not run simultaneously, preventing data corruption or other issues.
The CRM achieves this by checking for incompatibility rules defined in concurrent program definitions and managing the execution of requests accordingly.
More detailed explanation:
What it does:
Incompatibility Checks:
The CRM's primary function is to examine concurrent program definitions for incompatibility rules.
Conflict Resolution:
It identifies if a program is defined as "Run Alone" or has other incompatibility rules and prevents other incompatible programs from starting until the first one completes.
Request Management:
The CRM manages the status of requests, ensuring they are processed in a way that avoids conflicts.
Key aspects of the CRM:
System Profile Option:
The system profile option "Concurrent: Use ICM" controls whether the CRM is enabled.
Concurrent Managers:
The CRM is one of the three main types of concurrent managers, along with the Internal Concurrent Manager (ICM) and Standard Manager.
Conflict Domains:
Incompatible programs are often associated with conflict domains, which define the specific data or resources that must be protected from simultaneous access.
Monitoring:
The CRM's activities can be monitored through various tools like operating system commands, forms, and SQL scripts.
How it helps:
Prevents Data Inconsistencies:
By preventing incompatible programs from running together, the CRM helps maintain data integrity.
Optimizes Resource Usage:
It ensures that resources are used efficiently by preventing conflicts and allowing for proper scheduling of requests.
Improves System Stability:
The CRM contributes to the overall stability of the Oracle Applications system by preventing issues that could arise from concurrent program conflicts.
In simpler terms:
Imagine you have two reports that cannot be run at the same time because they both try to update the same data. The Conflict Resolution Manager in Oracle Apps R12 would act like a gatekeeper, making sure that only one of these reports runs at a time, preventing any conflicts and ensuring data consistency.
3) The Standard Manager is a general-purpose manager that handles any concurrent requests that haven't been specifically assigned to another manager. Essentially, it acts as a default or safety net, ensuring that all concurrent requests can be processed, even if they don't fall under a specialized manager's purview.
More detailed explanation:
Default Manager:
The Standard Manager is designed to execute any concurrent request that doesn't have a specific manager assigned to it.
Continuous Operation:
It's active 24/7, 365 days a year, ensuring continuous processing of requests.
No Specialization:
It doesn't have any specific specialization, meaning it can handle any type of concurrent request.
Critical for Unassigned Requests:
If you don't define custom managers for specific tasks, the Standard Manager will handle those requests, ensuring that no requests are left unprocessed.
Example:
It's often used to run reports that are part of the standard Oracle E-Business Suite installation.
Process Name:
The Standard Manager's process name is FNDLIBR
Don't Alter:
It's generally not recommended to alter the definition of the Standard Manager, as this could prevent some programs from running if you haven't defined alternative managers to handle those requests, according to the Oracle Help Center. You can always create separate managers if you want certain concurrent programs to run on a different manager queue.
Key Role:
The Standard Manager is a cornerstone of the Concurrent Processing system, ensuring smooth and reliable background processing within the Oracle E-Business Suite.
- Transaction Manager
- Service Manager
- Internal Monitor
1) Transaction managers are background processes that handle the execution of various transactions, particularly within Oracle Inventory and Manufacturing modules.
They manage the flow of data from user interfaces or other sources into the Oracle database, ensuring transactions are processed efficiently and reliably.
More detailed explanation:
Key Functions:
Transaction Processing:
Transaction managers handle the execution of different types of transactions, such as material transactions, move transactions, and cost transactions.
Concurrency Control:
They manage the concurrent execution of multiple transactions, preventing conflicts and ensuring data integrity.
Background Processing:
Transactions are typically processed in the background by the transaction manager, allowing users to continue with their work without being blocked by long-running operations.
Scheduling and Monitoring:
Transaction managers can be scheduled to run at specific intervals and are monitored to ensure they are functioning correctly.
Integration with Other Modules:
They integrate with various Oracle Applications modules, including Inventory, Manufacturing, and Costing, to manage the flow of data and updates.
Types of Transaction Managers:
Material Transactions Manager: Processes inventory transactions.
Move Transactions Manager: Processes Work in Process (WIP) move transactions.
Resource Cost Transactions Manager: Processes WIP resource transactions.
Material Cost Transactions Manager: Processes costing transactions.
How they work:
Client Interaction:
A client program (e.g., a form) initiates a transaction by calling a specific function (e.g., FND_TRANSACTION.SYNCHRONOUS).
Message Passing:
The client program sends a message to the transaction manager via a pipe, containing the transaction details (program ID and parameters).
Transaction Execution:
The transaction manager retrieves the message, executes the specified program with the provided parameters, and updates the database.
Return Status:
The transaction manager sends a completion message back to the client, indicating the success or failure of the transaction.
Benefits of using Transaction Managers:
Improved Performance:
Transactions are processed in the background, allowing users to continue working without waiting for the completion of lengthy operations.
Reduced Database Load:
By handling transactions in batches, transaction managers can optimize database access and reduce overall load.
Enhanced Scalability:
The mechanism allows for a large number of clients to be serviced by a relatively small number of transaction manager processes.
Real-time Response:
Despite being processed in the background, many transactions can be processed with minimal delay, providing a near real-time user experience.
In summary, transaction managers in Oracle Apps R12 are essential for efficient and reliable transaction processing, ensuring smooth operations in various modules by handling background tasks and maintaining data integrity.
2) FNDSM, or Service Manager, acts as a middle-tier agent for the Internal Concurrent Manager (ICM).
It's responsible for managing concurrent manager processes and other GSM (Generic Service Management) services on a specific node.
The ICM uses FNDSM to start, stop, and monitor these services.
Role of FNDSM:
FNDSM is a crucial component in the Concurrent Processing architecture, acting as the local agent for the ICM on each application node.
Communication with ICM:
The ICM uses RPC (Remote Procedure Call) to communicate with FNDSM on the relevant node.
Startup and Shutdown:
The APPS TNS Listener starts FNDSM on demand when the ICM needs to manage services on a specific node. When the ICM shuts down, the FNDSM processes on all nodes also shut down.
Node-Specific Management:
Each application node registered in FND_NODES has its own FNDSM instance.
GSM Services:
FNDSM manages services like the Workflow Mailer and Output Post Processor (OPP).
Relationship with ICM:
The ICM relies on FNDSM to manage all concurrent managers and other services on each node.
Configuration:
The FNDSM environment is set by the APPSORA.env file, and it relies on the listener.ora and tnsnames.ora files for network configuration.
3) An Internal Monitor (FNDIMON) is a component used in Distributed Concurrent Processing to ensure the Internal Concurrent Manager (ICM) remains active.
It monitors the ICM and restarts it on the local node if it fails, preventing system downtime due to ICM issues.
More detailed explanation:
Purpose:
The primary function of the Internal Monitor is to safeguard the ICM, which is crucial for managing all other concurrent managers in the system.
By restarting the ICM on the same node if it fails, the Internal Monitor minimizes disruption to the overall processing environment.
How it works:
Internal Monitors are seeded on every registered node in Oracle Applications R12, ready to monitor the ICM.
When the ICM unexpectedly terminates (e.g., due to a node or database failure), the Internal Monitor on that node detects the failure.
The Internal Monitor then initiates the restart of the ICM on the same node.
If multiple Internal Monitors detect an ICM failure, only the first one to respond will successfully restart the ICM.
Key Considerations:
Distributed Concurrent Processing:
Internal Monitors are specifically designed for environments using Distributed Concurrent Processing where multiple application server nodes are involved.
Node Assignment:
When setting up your system, you decide which nodes will have Internal Monitors and can configure failover protection by assigning primary and secondary nodes.
Work Shifts:
Similar to concurrent managers, Internal Monitors can have assigned work shifts, and their activation and deactivation are managed by the ICM.
