This is the eleventh in a series of posts regarding installing BI Apps 11.1.1.10.2 on Oracle Linux 7.2. For your reference, here is a list of URLs for each of the posts that make up this series:
In this post, I will be discussing how to install OBIA 11.1.1.10.2 silently (i.e. without a GUI).
General Assumptions and Conventions Used
I will assume that readers of this blog have read the prior blog entries in this series before continuing. Specifically, I will assume that the four OBIA zip files (V270271-01.zip, V270274-01_1of2.zip, V270274-01_2of2.zip, V270276-01.zip) have been downloaded from eDelivery and placed in /u01/sw/obia, Java and WebLogic have been setup, OBIEE and ODI have been installed, the latest version of OPatch has been applied, and the OBIA RCU has been executed. Also, it is important to note that there are three main components of the OBIA installation:
Installation of software binaries
Application of platform patches
Updating ATGLite, FSM and BIACM/BIACM_IO
As a result, this blog entry has been organized accordingly. Finally, we will assume that environment variables such as $TMP, $MW_HOME and $JAVA_HOME - which are referenced in this blog - have been established (which they were in an earlier blog entry in this series).
Installation of OBIA binaries
Unzipping the installation files
The first step is to unzip the OBIEE installation zip files to a temporary location. The temporary location we will use is $TMP/bieeinst. Please issue the following commands from the terminal in order to create this temporary directory and unzip the files there: $ umask 027 $ mkdir -p $TMP/biainst $ cd /u01/sw/obia $ unzip -q '*.zip' -d $TMP/biainst
Configuring a response file
In order to install OBIA from the command line, you will need a response file (similar to OBIEE). I have generated a response file called obia1111102Install.rsp and have posted it on my GitHub account. For the purposes of this blog series, we will download this file and store it in /u01/sw/scripts. This particular response file has already been altered to suite the installation detailed by this blog series. If you want to choose different installation paths or enter different values, the response file does contain documentation to help you do that. However, please note that this blog series will assume that the file is used as is. Just like with the OBIEE and ODI response file, there's not much you would want to change in this response file. In fact, the OBIA response file only contains two parameters, and they are solely about paths. If you wanted to use different paths, you should look at changing the following two parameters found in the file: MW_HOME (which points to the Middleware Home directory - $MW_HOME) and ORACLE_HOME (which will point to the spot where the OBIEE binaries are installed (and is usually $MW_HOME/Oracle_BI1). Here are the parameter settings I used: ORACLE_HOME=/u01/app/obia11g/product/11.1.1/mwhome_1/Oracle_BI1 MW_HOME=/u01/app/obia11g/product/11.1.1/mwhome_1 Here is a screenshot of the relevant portion of the response file:
Running the installer
Now that the installation files have been unzipped and the response file created/downloaded, we can now launch the installer. In order to do do, please issue the following commands from the terminal: $ cd $TMP/biainst/biappsshiphome/Disk1 $ umask 027 $ ./runInstaller -jreLoc $JAVA_HOME -silent -response /u01/sw/scripts/obia1111102Install.rsp -invPtrLoc /u01/app/oraInventory/oraInst.loc -printtime -waitforcompletion This process will take several minutes to complete. When done, the output to the terminal should resemble the following screenshot:
A line towards the bottom of the output will indicate that "Oracle Business Intelligence Shiphome, Oracle Business Intelligence Applications Shiphome completed successfully" if the installation was indeed successful.
Applying OBIA platform patches
Directory and file preparation Before the platform patches can be applied, there is some preparation work that needs to be done. Firstly, we need to make a temporary work directory for the patches to function. Theoretically, you could put this work directory anywhere, but I like to put it underneath the $TMP/biainst directory that we created at the beginning of this blog entry. Regardless, please make note of this location as you will need it later on. To create the work directory underneath $TMP/biainst, issue the following command from the terminal: $ mkdir $TMP/biainst/work Secondly, when we unzipped all of the OBIA zip files earlier, they were extracted to $TMP/biainst. It turns out that this causes the contents of one of the zip files (V270276-01.zip) to be put in the wrong location (slightly). The contents of this file (which are actually three new zip files) should be placed in $TMP/biainst/biappsshiphome/linux64 and not in $TMP/biainst. As a result, these files need to be moved. To do so, please issue the following commands from the terminal: $ mkdir $TMP/biainst/biappsshiphome/linux64 $ mv $TMP/biainst/*.zip $TMP/biainst/biappsshiphome/linux64 Configure/Create apply_patches_import.txt The OBIA Platform Patches are applied via a PERL script called APPLY_PATCHES.pl (located in $MW_HOME/Oracle_BI1/biapps/tools/bin). As an input, this utility requires changes to a parameter file called apply_patches_import.txt (which is also located in $MW_HOME/Oracle_BI1/biapps/tools/bin). Please open this file in your text editor and set the following parameters/values which have been given paths appropriate to the environment that has been setup in this blog series (please note that if you elected to change some paths during your installation, you may need to change the below parameters to something different): JAVA_HOME=/u01/app/obia11g/product/11.1.1/mwhome_1/Oracle_BI1/jdk INVENTORY_LOC=/u01/app/oraInventory ORACLE_HOME=/u01/app/obia11g/product/11.1.1/mwhome_1/Oracle_BI1 MW_HOME=/u01/app/obia11g/product/11.1.1/mwhome_1 COMMON_ORACLE_HOME=/u01/app/obia11g/product/11.1.1/mwhome_1/oracle_common WL_HOME=/u01/app/obia11g/product/11.1.1/mwhome_1/wlserver_10.3 SOA_HOME= ODI_HOME=/u01/app/obia11g/product/11.1.1/mwhome_1/Oracle_ODI1 SKIP_BITECH_PATCHES=false WINDOWS_UNZIP_TOOL_EXE= WORKDIR=/u01/app/obia11g/tmp/biainst/work PATCH_ROOT_DIR=/u01/app/obia11g/tmp/biainst In addition, I have posted the apply_patches_import.txt file that I used to my GitHub account for your reference. Please note though that unlike with other files used in this blog (such as the response files) which did not exist and need to be created, this file will already exist - it just needs to be changed. Minor tweak to APPLY_PATCHES.pl One last thing that I found I needed to do before executing APPLY_PATCHES.pl was to make a minor tweak to it. On line 270 of the file, a variable called PATCHES_UNZIP_LOC is set, and it is set by default to "${AUTO_WORK}${DIRSEP}patches". This did not work for me - largely because I did not have a "patches" directory setup in my directory structure. As a result, I changed this line to read: "${AUTO_WORK}${DIRSEP}". Please open up this file ($MW_HOME/Oracle_BI1/biapps/tools/bin/APPLY_PATCHES.pl) in your text editor and make this same change. Here is a screenshot showing the change:
Executing APPLY_PATCHES.pl Now we are ready to execute APPLY_PATCHES.pl. In order to do so, please issue the following commands from the terminal: $ cd $MW_HOME/Oracle_BI1/perl/bin $ ./perl $MW_HOME/Oracle_BI1/biapps/tools/bin/APPLY_PATCHES.pl $MW_HOME/Oracle_BI1/biapps/tools/bin/apply_patches_import.txt This will take quite some time. Here is a screenshot showing the output from a successful running of this process:
Please check that all of the above patches where applied to your environment. You should have patches applied under BIAPPSSHIPHOME Patching Report, Oracle Common Patching Report, ODI Patching Report and Weblogic Patching Report. The only section where there are no patches being applied is SOA Patching Report. Please note that If one of the sections of patches did not get applied (which commonly happens with the Weblogic patching section, so much so that it has been called out as a separate step in the OBIA documentation - see step #5 located here), then you will either need to apply those patches manually, or rollback and try again. However, if you have followed my instructions to this point, you should get output similar to the above and will not need to perform any additional steps. Updating ATGLite, FSM and BIACM/BIACM_IO The last thing that needs to be done before we can claim that OBIA 11.1.1.10.2 has been installed correctly is to run several processes to update several components that make up the Fusion Middleware/OBIA ecosystem. These components have already been installed, but require an update in order to allow the configuration process (which we will get to in a future blog entry) to execute and complete successfully. These components are called:
ATGLite (which utilizes the BIACOMP schema that was setup via the OBIA RCU: FMW_BIACOMP)
FSM (which again utilizes the BIACOMP schema that was setup via the OBIA RCU: FMW_BIACOMP)
BIACM (which yet again utilizes the BIACOMP schema that was setup via the OBIA RCU: FMW_BIACOMP)
and BIACM_IO (which utilizes the BIACM_IO schema that was setup for us during the OBIA RCU process: FMW_BIACM_IO)
The mechanism that drives these updates is called Patch Set Assistant and is located in $MW_HOME/Oracle_BI1/bin/psa. Furthermore, we will be using a series of four response files to update each of these four components in order to conduct the update solely from the command line (i.e. No GUI). ATGLite As mentioned, before we run Patch Set Assistant to update ATGLite from the command line, we need to create a response file and put it in /u01/sw/scripts. I have posted a response file called psaupdate_ATGLite.rsp to my GitHub account. Please feel free to use it as is. If you would like to make changes, here are the parameter names that you would most likely want to change: ATGLITE.databaseType = Oracle Database ATGLITE.databaseConnectionString = 192.168.186.6:1521/obaw ATGLITE.schemaConnectionString = 192.168.186.6:1521/obaw ATGLITE.schemaUserName = FMW_BIACOMP ATGLITE.cleartextSchemaPassword = fmw4DB # ATGLITE.encryptedSchemaPassword = ATGLITE.dbaUserName = sys as sysdba ATGLITE.cleartextDbaPassword = admin4$DB # ATGLITE.encryptedDbaPassword = You will note that ATGLite.encyrptedSchemaPassword and ATGLite.encryptedDbaPassword are commented out (with a # at the beginning of the line). If you want to use encrypted passwords in this file, then you will need to get the encrypted version of those passwords for use here. The best way to do that is to run through PSA once via the GUI and generate the response file using the GUI. However, doing so may make your response files a bit less portable, and if you wanted to use them to drive more than one installation, using clear text for both passwords makes things this a bit more portable. This is why I have opted to use clear text passwords in my response file. Once the file has been created in/downloaded to /u01/sw/scripts, issue the following command from the terminal to launch PSA to update ATGLite: $ $MW_HOME/Oracle_BI1/bin/psa -response /u01/sw/scripts/psaupdate_ATGLite.rsp If successful, your output should resemble the following:
Note the final line in the output indicates that the upgrade finished successfully. FSM The remaining updates will be following a similar process to the update of ATGLite - the only difference being the response file. Here is a response file named psaupdate_FSM.rsp which I have posted to my GitHub account. If you would like to make changes, here are the parameter names in the response file that you would most likely want to change: FSM.databaseType = Oracle Database FSM.databaseConnectionString = 192.168.186.6:1521/obaw FSM.schemaConnectionString = 192.168.186.6:1521/obaw FSM.schemaUserName = FMW_BIACOMP FSM.cleartextSchemaPassword = fmw4DB # FSM.encryptedSchemaPassword = FSM.dbaUserName = sys as sysdba FSM.cleartextDbaPassword = admin4$DB # FSM.encryptedDbaPassword = Once the file has been created in/downloaded to /u01/sw/scripts, issue the following command from the terminal to launch PSA to update FSM: $ $MW_HOME/Oracle_BI1/bin/psa -response /u01/sw/scripts/psaupdate_FSM.rsp If successful, your output should resemble the following:
Note the final line in the output indicates that the upgrade finished successfully. BIACM Here is a response file named psaupdate_BIACM.rsp which I have posted to my GitHub account. If you would like to make changes, here are the parameter names in the response file that you would most likely want to change: FSM.databaseType = Oracle Database FSM.databaseConnectionString = 192.168.186.6:1521/obaw FSM.schemaConnectionString = 192.168.186.6:1521/obaw FSM.schemaUserName = FMW_BIACOMP FSM.cleartextSchemaPassword = fmw4DB # FSM.encryptedSchemaPassword = FSM.dbaUserName = sys as sysdba FSM.cleartextDbaPassword = admin4$DB # FSM.encryptedDbaPassword = ATGLITE.databaseType = Oracle Database ATGLITE.databaseConnectionString = 192.168.186.6:1521/obaw ATGLITE.schemaConnectionString = 192.168.186.6:1521/obaw ATGLITE.schemaUserName = FMW_BIACOMP ATGLITE.cleartextSchemaPassword = fmw4DB # ATGLITE.encryptedSchemaPassword = ATGLITE.dbaUserName = sys as sysdba ATGLITE.cleartextDbaPassword = admin4$DB # ATGLITE.encryptedDbaPassword = BIACM.databaseType = Oracle Database BIACM.databaseConnectionString = 192.168.186.6:1521/obaw BIACM.schemaConnectionString = 192.168.186.6:1521/obaw BIACM.schemaUserName = FMW_BIACOMP BIACM.cleartextSchemaPassword = fmw4DB # BIACM.encryptedSchemaPassword = BIACM.dbaUserName = sys as sysdba BIACM.cleartextDbaPassword = admin4$DB # BIACM.encryptedDbaPassword = Once the file has been created in/downloaded to /u01/sw/scripts, issue the following command from the terminal to launch PSA to update BIACM: $ $MW_HOME/Oracle_BI1/bin/psa -response /u01/sw/scripts/psaupdate_BIACM.rsp If successful, your output should resemble the following:
Note the final line in the output indicates that the upgrade finished successfully. BIACM_IO Here is a response file named psaupdate_BIACMIO.rsp which I have posted to my GitHub account. If you would like to make changes, here are the parameter names in the response file that you would most likely want to change: BIACM_IO.databaseType = Oracle Database BIACM_IO.databaseConnectionString = 192.168.186.6:1521/obaw BIACM_IO.schemaConnectionString = 192.168.186.6:1521/obaw BIACM_IO.schemaUserName = FMW_BIACM_IO BIACM_IO.cleartextSchemaPassword = fmw4DB # BIACM_IO.encryptedSchemaPassword = BIACM_IO.dbaUserName = sys as sysdba BIACM_IO.cleartextDbaPassword = admin4$DB # BIACM_IO.encryptedDbaPassword = Once the file has been created in/downloaded to /u01/sw/scripts, issue the following command from the terminal to launch PSA to update BIACM_IO: $ $MW_HOME/Oracle_BI1/bin/psa -response /u01/sw/scripts/psaupdate_BIACMIO.rsp If successful, your output should resemble the following:
Note the final line in the output indicates that the upgrade finished successfully.
Summary
In this entry of my OBIA 11.1.1.10.2 blog series, we installed OBIA 11.1.1.10.2, applied the OBIA Platform Patches, and updated ATGLite, FSM, BIACM and BIACM_IO. While we still have the configuration of OBIEE and OBIA to do, where we are at right now is a really good milestone because all of the software has been installed to the application server successfully. As a result, I highly recommend stopping now to take backups/snapshots and to reboot the server. I would also recommend doing the same for your database server (or at least a backup of the schemas - a reboot of the database server is not necessary). This is because the configuration of OBIEE and OBIA will not only alter the file system on your OBIA application server, but will also make changes to the schemas that were setup by the OBIEE and OBIA RCUs. As a result, if you do experience a failure, it may be simpler to restore from backup than to try to back out all of the changes.
Looking ahead
In my next blog entry, I will show how to run the configuration script for OBIEE.