HP Serviceguard Toolkit for Oracle E-Business Suite User Guide

NOTE: For more information on configuring for an external entry point, see Oracle Metalink note
380489.1.
For example, by using the configuration shown in Figure 1 (page 7), the Web entry point and
external URLs on node sg-serv1 and sg-serv2 are changed from containing sg-serv1 and
sg-serv2 to ebsapps.
To validate the correct setting you can check the AutoConfig configuration XML file and search for
the following tags inTable 1 (page 6)
Table 1 AutoConfig configuration XML file tags to modify for the new EBS Web entry point
Reference configuration examplePurposeTag
http://ebsapps.ebs.com:800The external URL
that end users will
use to access the
system
externURL
ebsappsThe hostname
which users will
connect to
Webentryhost
http:// ebsapps.ebs.com:8000/`OA_HTML`/AppsLoginThe URL that end
users will use to
login to the system
login_page
Concurrent processing
In the EBS APPS tier configuration section we discussed how the interactive Web and Forms
workload is handled within the Serviceguard cluster to provide a highly availability 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 (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, a single defined copy of the concurrent manager means introducing a single
point of failure and, so a solution is required to minimize downtime in the face of unexpected
failures.
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 are already running on alternative nodes. They are ready to
continue batch operations in 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, allow a
more fluid allocation of concurrent managers to nodes. In EBS Release 12, concurrent managers
are not bound to any explicit concurrent processing 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 if required.
For example, in Figure 1 (page 7), concurrent processors are defined on both the nodes of 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 runs on the same node as the other
6 Configuring EBS and SGeEBS