An Oracle Applications system depends on a variety of services such as Forms Listeners, HTTP Servers, Concurrent Managers, and Workflow Mailers. Such services are composed of one or more processes that must be kept running for the proper functioning of the applications. Previously many of these processes had to be individually started and monitored by system administrators. Management of these processes was complicated by the fact that these services could be distributed across multiple host machines. Service Management helps to greatly simplify the management of these processes by providing a fault tolerant service framework and a central management console built into Oracle Applications Manager.
Service Management is an extension of concurrent processing, which provides a powerful framework for managing processes on multiple host machines. With Service Management, virtually any application tier service can be integrated into this framework. Services such as the Oracle Forms Listener, Oracle Reports Server, Apache Web listener, and Oracle Workflow Mailer can be run under Service Management.
With Service Management, the Internal Concurrent Manager (ICM) manages the various service processes across multiple hosts. On each host, Service Manager acts on behalf of the ICM, allowing the ICM to monitor and control service processes on that host. System administrators can then configure, monitor, and control services though a management console which communicates with the ICM.
Generic Service Management
Service Management provides a fault tolerant system. If a service process exits unexpectedly, the ICM will automatically attempt to restart the process. If a host fails, the ICM may start the affected service processes on a secondary host. The ICM itself is monitored and kept alive by Internal Monitor processes located on various hosts.
Service Management provides significant improvements in the manageability of Oracle Applications. System administrators can now use the central console in Oracle Applications Manager (OAM) to manage a variety of services that formerly had to be managed independently on separate hosts. The entire set of system services may be started or stopped with a single action. Service Management also provides a great benefit by automatically compensating for certain system failures.
Service processes are very much like concurrent manager and transaction manager processes. They must be kept running on a middle tier for the proper functioning of their respective products. The concurrent processing management feature has been built for concurrent managers and transaction managers, to provide fault tolerance, process distribution, and simplified configuration and control.
Benefits of Service Management
• The service processes will no longer need to be manually and individually started and monitored by Oracle Applications system administrators.
• Services can take advantage of the process distribution and fault tolerance capabilities that have been developed for concurrent processing.
• As with concurrent manager processes, system administrators can use work shifts to determine the number of processes that will be active for a service on a given node for a given time period.
To extend process management support to the various Applications services, the Internal Concurrent Manager must be able to start, monitor, and control processes on all Applications tiers. Every node of every tier will have an Oracle RPC-based Service Manager installed. The ICM will use the Service Manager to manage processes.
ServiceA service is a process or collection of processes that perform actions at the request of client processes. A concurrent manager is a type of service where the client submits a request for actions to be processed while the client continues to do other work. While active, a service must have one or more listener processes that wait to process requests from clients. An example of a listener is a concurrent manager process which periodically polls a queue for requests to process.
Service InstanceEach service controlled by service management may have multiple service instances.
Each instance may consist of one or more processes.
Concurrent:GSM Enabled Profile OptionThe Concurrent:GSM Enabled profile option should be set to Y to enable Service Management. It is set automatically to Y by AutoConfig. Disabling Service Management is not recommended as that may prevent necessary services from starting.
Service Management and Control ScriptsWith Service Management, the Apache Server, Forms Server, Forms Metrics Server, Forms Metrics Client, and Reports services can be managed through Oracle Applications Manager. When these services are enabled for Service Management, they can still be controlled using the control scripts listed below; for example, using adapcctl.sh (UNIX) or adapcctl (Windows).
These control scripts are generated by AutoConfig for the Forms Listener, Reports Server, and other Application Tier services, and synchronize with Service Management. If you start or stop a service using one of these scripts, Service Management is notified of the change. If the Service Management infrastructure is not running, the control scripts can be used to control individual services. The service status is synchronized with Service Management when the Internal Concurrent Manager (ICM) is restarted. Running one of these control scripts from the command line starts or stops the respective service synchronously and the FNDSVCRG program and the ICM handles the data collection.
The control scripts that can be managed by Service Management are:
• adapcctl.sh (Apache)
• adfrmctl.sh (Forms)
• adfmsctl.sh (Metrics Server)
• adfmcctl.sh (Metrics Client)
• adrepctl.sh (Reports)
Network Failure RecoveryAs part of its shutdown process, the ICM determines if it's being forced to shutdown due to losing its database connection. This is done by looking for specific error messages ORA-3113, ORA-3114, or ORA-1041. If one of these error messages is detected, the ICM spawns the reviver process, which attempts to make a database connection. If unsuccessful, it sleeps for a period before trying again. This continues until either a successful connection is made or it receives a signal to shut itself down. When a successful connection is made, the process kills the old ICM database session, and then starts a new ICM using the normal start manager script. Once the ICM is restarted, it starts up any other managers that had also shut down, and normal processing resumes.
Failover Sensitive WorkshiftsNodes can become overloaded when a middle-tier node fails and service instances on that node failover to their secondary nodes. The Load Distribution feature allows the System Administrator to control the allocation of resources during normal processing. The Failover Sensitivity feature allows Work Shifts to failover with fewer processes than on the original node. This lessens the impact on the existing resources allocated on the secondary node.
The number of failover processes is entered as part of the standard Work Shift settings in the Service Instance Definition. When failover occurs, the ICM uses the Failover Processes value in place of the normal running processes value as it iterates through service instances to perform queue sizing.
