Understanding the HP Serviceguard Extension for Oracle E-Business Suite (SGeEBS)

You can validate that this is set correctly by checking your AutoConfig configuration XML file and

looking for the following tags:

Table 1: AutoConfig configuration XML file tags to modify for the new EBS Web entry point

Concurrent processing

In previous sections we discussed how the interactive Web and forms workload is handled within the

Serviceguard cluster to provide a highly available environment. The other important component of the

APPS tier that also needs consideration is the concurrent processing manager which provides batch

and asynchronous processing capabilities.

For concurrent processing, SGeEBS draws upon standard Oracle availability techniques and

leverages EBS’s Parallel Concurrent Processing (or PCP) capabilities.

In a simple configuration where PCP is not deployed, a single server from within the set of available

servers allocated to EBS is chosen as the concurrent manager node and that system is responsible for

processing all batch and asynchronous requests. EBS allows the concurrent manager node to be

located either on its own dedicated server, on a DB tier server or any of the available APPS tier

servers. However, having a single defined copy of the concurrent manager means introducing a

single point of failure and hence a more fault resistant solution is required.

Parallel Concurrent Processor configurations remove the single point of failure by allowing multiple

concurrent processors to be defined within the same EBS instance. Defining multiple concurrent

processing nodes eliminates the potential for a single point of failure as concurrent processors can

either be quickly started, or already running on alternative nodes ready to continue batch operations

in the case of a failure.

Unlike earlier implementations where a concurrent manager was associated with a specific primary

and an alternate fallback concurrent processing node, EBS Release 12, or later versions, allows for a

more fluid allocation of concurrent managers to nodes. In EBS Release 12, concurrent managers can

be configured such that they are not bound to any explicit concurrent processing nodes and PCP

dynamically decides which manager will be executed on which available PCP node at runtime.

Serviceguard takes advantage of PCP functionality to enable the concurrent processing system to

failover to an alternative node should the need arise.

In Figure 1, concurrent processors are defined on both nodes in the two node Serviceguard cluster

using a PCP arrangement. The concurrent processor is managed as an integral part of the overall

applications tier so that it is running on the same node as the other applications tier services that is

concurrent manager is run on the same server at the same time as the Web and forms components.

Should an APPS tier server failure occur, the concurrent processing subsystem undergoes a failover

with the rest of the application tier services to the alternative node and is automatically restarted on

that server. Through PCP functionality, concurrent managers are now restarted on the alternate server

and batch and asynchronous job processing can now continue.

Tag Purpose Reference configuration example

externURL The external URL that end users will

use to access the system

http://ebsapps.ebs.hp.com:8000

Webentryhost The hostname which users will

connect to

Ebsapps

login_page The URL that end users will use to

http://ebsapps.ebs.hp.com:8000/OA_HTML/AppsLogin