In this post, I will explain how to install Oracle Fusion Middleware Forms and Reports 11g R2 for a high availability architecture on a Windows platform. For the Linux platform, it’s approximately the same, even though the node manager is a daemon.
In my first post, I‘ve described the advantages of the WebLogic cluster (part of Oracle Fusion Middleware high availability). Now, it’s time to take components such as forms and reports server and explain how to proceed for a basic installation in order to integrate these services into a 2 nodes WebLogic cluster.
The goal of this post is to demonstrate how to setup the environment described in the following schema:
In our case, we have 2 different servers (VMTESTFUSION01 and VMTESTFUSION02) on which we will install Oracle Fusion Middleware Forms & Reports Server 11gR2 (11.1.2) in a high availability configuration. In the schema presented above, we see that the WLS_REPORTS and WLS_REPORTS1 as well as WLS_FORMS and WLS_FORMS1 are in a WebLogic Cluster. Such setup provides all the advantages described in my previous post available here.
We can also observe in this schema that there are some systems components such as Oracle Base Instance and some Java Based components that are supported by the Oracle WebLogic Server (application tier).
In this post, I won’t discuss Oracle web server (OHS) and the load balancer component. But in a high availability architecture, OHS has to route the client requests to the WebLogic managed server as shown in the following schema:
In my next blog, I will demonstrate how to configure the Oracle HTTP Server (OHS) to be “cluster aware”.
Installation of Oracle Fusion Middleware Forms and Reports 11gR2 (11.1.2)
The following information provide the key concept to proceed to the server installation.
Common installation tasks on both servers:
The following are the basic steps in order to install components on both servers:
1. Install the Java JDK needed by Oracle WebLogic Server
2. Install WebLogic Server (10.3.5) which is compatible with Forms and Reports server 11gR2 (11.1.2)
- Install WebLogic binaries without domain
Advice: During the installation of WebLogic Server, do not choose to install the node manager because the configuration stage of Forms and Reports component will fail. A script is provided by Oracle to install a service on a windows platform and must be done manually after the installation. You can also disable the windows service before the configuration of the component of Oracle Fusion Middleware.
3. Install the Oracle Fusion Middleware binaries into the FMW_HOME created by the WebLogic Server installer. Install only the software, because the configuration stage is not the same on both servers. This avoids to make a cluster of forms and reports server between vmtestfusion01 and vmtestfusion02.
At this stage, we have installed the system component on the two servers. Now, we need to configure it and install the Java Appliance on WebLogic Server. This step configures the connection between both servers in order to establish a communication channel. On the first server, the configuration is standard and on the second server, the configuration must extend the WebLogic domain created on the first server.
Configuration of Oracle Fusion Middleware Forms and Reports 11gR2
1. Configuration on the first server (vmtestfusion01)
To configure the application tier on vmtestfusion01, start the oracle configuration script from the following folder
Configure it for creating a new domain and provide the information for your needs. Do not forget to include your server components in a weblogic cluster which will be expand by vmtestfusion02 node:
On the previous screen, we see that Oracle HTTP server was installed on the same server as the Oracle Fusion Middleware component. Normally, the web server is not installed on the same server in order to ensure service high availability. In fact, if the Oracle Fusion Middleware vmtestfusion01 fails and become unavailable, the oracle HTTP server needs to redirect the client requests to the other oracle WebLogic cluster node. This principle will be explained in another post.
Despite that it is not mandatory to use the same ports for each service on each server, it is strongly recommended by Oracle, and also by dbi services. Oracle allows to bypass the Automatic Port Configuration by specifying ports in a configuration file.
This file should have entries for the following services:
Once the ports are configured, complete the installation:
2. Configuration on the second server (vmtestfusion02)
Go to vmtestfusion02 server and call the Oracle Installer to configure the application on vmtestfusion02. The installer is in the following directories:
In order to be able to extend the cluster domain, it is mandatory to complete the information regarding the host, the port, and the user details.
At the next stage, you have to choose the component that will be available on the vmtestfusion02.
You should choose the same components as on the vmtestfusion01 server
Generic configuration on vmtestfusion01 and vmtestfusion02
The following steps are required regardless of the product being configured:
Set admin server listen address
In servers where multiple network cards exist, it is important to bind the Administration Server to the network card that you wish to use.
Create boot.properties file for auto-authentication
boot.properties file for the Administration Server on vmtestfusion01 and vmtestfusion02. The
boot.properties file enables the Administration Server to start without prompting you for the administrator username and password. You can do so for all managed server if you start it in the independent mode.
In a text editor, create a file called
boot.properties in the directory:
With the following lines:
Restarting the Administration Server encrypts the values:
At this stage, the Oracle Fusion Middleware Forms and Reports component is configured to work in a high availability architecture.
In this post I explained the key steps for setting up an Oracle Fusion Middleware configuration in a high availability environment.
Of course such a basic configuration can be improved in order to extend the possibilities provided by such an architecture. For instance, it would be great to configure a report queue for all jobs shared by both servers to execute user requests. It is also possible to share directories for the common report cache.