Siebel Deployment Planning Guide > High Availability Deployment Planning > How Service Failures Affect the Siebel Deployment >

Components Involved in Service Failures

This topic identifies major architectural components in a Siebel deployment that might be affected when a service failure occurs.

This topic is part of How Service Failures Affect the Siebel Deployment.

Siebel Web Clients

Client hardware failure and browser failures are the most common causes of Siebel Web Client failure. Operating system failures can also cause this, but are rare.

When the Siebel Web Client fails, user sessions are lost even though the sessions might continue running on the Siebel Server for a time. The user session is lost because when the Siebel Web Client fails, the Siebel session cookie usually is also lost. Without the cookie, the user cannot be routed back to the existing user session on the Siebel Server. Therefore, the user usually has to log in again and start a new user session.

Siebel Application Interface

An Siebel Application Interface instance might fail because of hardware or software issues. When the Siebel Application Interface fails, Siebel Web Clients cannot access Siebel applications, because requests must go through the Siebel Application Interface first. Existing connections from the Siebel Application Interface to Siebel Servers are also lost.

If Siebel Application Interface are set up for high availability, for example if there are multiple instances of Siebel Application Interface, then subsequent requests can be routed to another working Siebel Application Interface. Usually when this occurs, the function of affected Siebel Web Client user sessions is not noticeably affected.

Siebel Servers

Siebel Servers might fail because of hardware or software issues. If the hardware platform fails, or the Siebel Server software fails, then all of the Siebel Server components are lost.

In other cases, individual Siebel Server components might fail. In turn, component failure can cause related user sessions or user requests to fail. The major groups of Siebel Server components are as follows:

• Application Object Managers. When Application Object Manager processes terminate unexpectedly, user sessions hosted by the Application Object Manager are lost. Users must log in to the Siebel application again. If users return to the same Siebel Server, then SCBroker tries to route the user request to a running Application Object Manager process.

  If there is only one Application Object Manager process and it has failed, then the request is directed to a different Siebel Server, unless there is only one Siebel Server.

• Batch-mode server components going through SRBroker. Most batch-mode server components receive server requests through SRBroker. An example is Workflow Manager. When a batch-mode component fails, the current server request fails.
• Synchronous server requests. An error is returned to the requesting component.
• Asynchronous server requests. An error is logged but not returned to the requesting component. Subsequent requests for the failed batch-mode component are attempted against a different instance of the component on the same Siebel Server or on a different Siebel Server.

  If no instance of the batch-mode component is available, then the request is logged to the S_SRM_REQUEST table to be processed later.

• Direct Object Manager requests. Examples of direct Object Manager requests are those to Siebel Product Configuration Object Manager. Some components, such as Siebel Product Configurator, have a native failover mechanism.
• Other server components with location restrictions. There are specialized server components that do not communicate through SRBroker. Siebel Remote Server is an example. Typically, requests to these components can only be processed by a specific Siebel Server. Therefore, if the server fails, then requests to that server fail, until the server is restarted.

Siebel Database

Access to the Siebel database can fail due to a number of factors:

• Database server hardware failure
• Database server running out of resources
• Disk failure
• Network failure

The impact on the Siebel deployment is either temporary or long term. For example, a temporary networking interruption, or a quick database server reboot, would result in a temporary disruption in service. A long-term interruption might occur when there is database corruption or a major server malfunction.

In general, user sessions are lost when there is a Siebel database service interruption. Users must log in to the application again. Application Object Manager sessions continue to try to connect to the database. After the database is running (assuming the connection retry count has not been exceeded), the connection succeeds. Users might not notice that there was an outage, unless they were currently working at the time of the database failure. In this case, users get database error messages.

If the interruption is temporary, then the interactive server components and most of the batch-mode server components try to reconnect with the Siebel database. If the interruption is long-term, then the Siebel deployment must be shut down and restarted once the database service is restored.

NOTE:  It is strongly recommended not to collocate a Siebel Server or other components with the Siebel database on the same server hardware. Such a deployment can affect performance of either component, and might in some cases lead to Siebel Server failure or extend interruptions of availability. For example, where a Siebel Server and the Siebel database are collocated, if the server computer is rebooted, then the Siebel database instance might not be up by the time this Siebel Server is up, so a connection could not be made. Siebel Server failure could result. However, if the Siebel Server and the Siebel database are on separate servers, as recommended, then the Siebel database is unaffected by rebooting the server computer where Siebel Server is installed, and is available as soon as the Siebel Server is ready to connect.