Understand Oracle Fusion Application topology

Oracle fusion application is based on a large group of components like weblogic servers, databases, identity modules and so one. I’ll try in this article to explain how they are used and for what purpose.

Authentication and user management

fusion_securiteA first group of technical components is used for user management and user authentication by managing the SSO token over the different weblogic applications.

The entry point for any user http request is an OHS server (understand apache) where the WebGate plugin intercept the requests to transfer them to the OAM component. OAM stands for Oracle Access Manager. It is in charge of validating the access rights for the users and to the modules.

OAM is using a Directory to reference users. Oracle provides OID (Oracle Internet Directory) to store identities. This is basically an LDAP server. When using an already existing company directory the interface can be made by OVD (Oracle Virtual Directory) to manage the interface.

During installation, some applicative accounts needs to be create in the directory, so the use of OID + OVD for normal users seems to be a classical usage.

The Database level is composed of 2 different DB, one for OAM and one for OID.




Weblogic basic vocabulary

Weblogic is an application server made to run Java applications like tomcat, websphere… A weblogic domain is a instance or a group of weblogic instances working together. In a domain, you have an administration server (the first one) and different managed server. Administration and managed servers are basically different JVM running the components.

Multiple managed server can be group in a cluster for load balancing or high availability.

Administration Server managed the managed server (seems logical isn’t it?) running the application, it can also be used as a standalone server running application itself. The administration server basically runs the /console application to managed the domain’s servers.

fusion_domainAs an example here, we have a weblogic Domain named COMMONHOST1 where we have 1 Administration Server owning the Admin console (/console) + Enterprise Manager (/em)

You also see different Managed servers (SOA, ESS, Setup…) each containing one or multiple webapplications

Each managed server can be deployed on a same server, in this case, different port will be used for listening.

 Fusion Application weblogic general organization

Fusion application is split into different weblogic domains by functional entities.

  • The first needed entity is the COMMON Domain, then you have different entities depending on the software you are installing.
  • It seems that generally a restricted HCM domain is needed to manage users.
  • A Bi Domain is also something coming with all applications.
  • Then you have different domains for the different applications you install (SCM domain, Financials Domain, CRM Domain…)


Each domain can be configured to run as a cluster on different machine for failover capabilities like shown in the previous picture where you have two hosts configured with the same domains.

Even if you have only one server, the managed server will be configured as a cluster with one node. Addition of future node will be added easier.

Fusion Application common services

Some services are common to all the domains, they are managed servers used for technical operations and communication :


  • SOA : Service Oriented Architecture  service is required for web-services communication between all domain and integration with external applications.
  • ESS : Enterprise Scheduler Server used to managed process / jobs scheduling
  • SES : Secure Enterprise Search used by modules to delegate search.
  • Admin Server : also named Fusion Application Control is used to manage the domain. (has seen previously)

Fusion Application Database layer


The Database layer is based on a unique Oracle DB owning all the schemas for all the fusion domains. Only the OID, IAM db are independent.

The use of a RAC instance depends on you need of high availability of scalability.

When installing the Fusion Db, all the schemas for all the fusion applications are deployed, even if you need only SCM or any other. The empty db is about 30GB once installed.

Fusion application end user front end layer


A load balancer will route the traffic to the right OHS service, sso.mydomain.com will be redirected to the authentication service. The other url will be route to the right managed server (usually on the same server but on different port).

When installed in cluster on multiple servers, the load balancer will load balance between the different node.

Fusion Application environment type

As seen previously the number of web application server (managed server) to use to deploy a fusion application is really large and it makes the application really memory consuming.

The usual recommendation is separate the Authentication and User Management part from the others components. This is not mandatory and it can share the fusion app web and db tiers. But this split recommendation makes sense if you want to share this environment with different fusion applications installed separately.

The DB node should be separated from the application layer, this is always a good technical recommendation but, more over, in a licensing perspective it is the best to do.

The Application server layer can be installed on a machine, eventually on a cluster of machine for scalability and failover  , but depending on the fusion application it can be recommended to spread the different domains between multiple physical servers for performance considerations.

As example, standard Oracle recommendations for App server tier is 96GB of memory per node, DB tiers is 48GB per node.

Fusion Application installation process

There are 3 main steps to install a fusion application

  • install the Security components (OHS, OID, IAM)
  • install the Database server
  • install the Application server

Database server

  • Install the provisioning tool
  • Create the provisioning (setting all the installation parameters)
  • Install the database
  • Execute RCU (create all schemas) – exists only on Linux and Windows version

Application server

  • Install the provisioning tool
  • Create the provisioning ( at this set, all the setting are made)
    • when you choose the application to install, at this point you have a good view of the topology that will be deployed. Different domains & managed servers to be created.
  • Run Installation
    • Pre-verify step checks all the dependency and environment
    • Install step copy all the required files to proceed installation
    • Pre-configure step modify the configuration files right after installation
    • Configure step creates weblogic domains and deploys the application into the managed servers
    • Configure secondary step create the multi host configuration
    • Post configuration step starts service and finish the configuration like security that can only be made where service is up.
    • Validate terminate the installation by validating the installed components.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.