Monday 20 February 2017

Oracle Client Install failing in Windows server during EPM installation

In this blog, I would be talking about Oracle client install failing during the EPM installation on a Windows server. This is specifically with regards to EPM Architect install. You will generally observe this error if you do an install on a Windows server, uninstall it and then try to do the install once again.

The below snapshot shows the Oracle Client install failing during the installation of Hyperion EPM.

Now this is the strange part. This install worked perfectly the first time but during the second run, we kept getting this weird issue of client install failing. Now let us check the Oracle DB client install logs. The path of this file is shown in the below snapshot.

The error in the log file is as shown in the below snapshot.

The error says: The Oracle home name specified on the command line corresponds to an existing Oracle home in the Central Inventory.
Now this is the fun part. While installing the Oracle database client, the installer makes an entry in the Inventory file which is present, not under EPM folder structure, but under the Program Files folder. The file is called as inventory.xml and the file path is as shown in the below snapshot.

The contents of the XML file is as shown in the below snapshot.

The fix for this error is to clear out these entries from the XML file. The file after deleting the entries is as shown in the next snapshot.
 
I now run the installer once again and the installation passes of successfully as shown in the next couple of snapshots.


In-place Hyperion Essbase Application log formatter using shell script – Law of unintended consequences

In this blog, I would be talking about designing an in-place Hyperion Essbase application log formatter using shell script. I actually wanted to try this out since it reduces the space complexity. In my previous blog, I had designed one that keeps the existing log as is and generates a second parsed log file. (http://exploitsinhyperion.blogspot.in/2017/01/essbase-log-file-parser-shell-script.html). In this one, I try to make changes to the existing log file.

This log formatter assumes that you are using a Linux/Unix box and you have some knowledge of shell scripting.
The below snapshot shows the Essbase application log file.

The file present in the backend is as shown in the below snapshot. The file is called REVENUE.log
A simple cat on this file is shown in the next snapshot.

The first thing that I do before running the parser is to stop the Essbase application. This is because the Essbase process (ESSSVR) would be holding a lock on this file and it would not be possible to manipulate the file in-place if this is open.

The application has now been stopped as shown in the next snapshot.
I now run the shell script to parse the Essbase application log in place. The shell script takes the full path of the Essbase application log file as a parameter and parses the same. The script running in debug mode is shown in the next snapshot.

The contents of the file after the script has run is as shown in the next snapshot.
I now start up the application and view the log file. Observe that the new records are not formatted in a single row. 
The previous records from the log file are however in a single row which makes it easy for other processes to manipulate the records.
A snapshot showing both parsed and non-parsed records existing in the same log file is shown below.
The next couple of snapshots show me testing the script a couple more times and each time it works as expected.



 
Understanding the law of unintended consequences:
Well, this was the unintended consequence of the script. When I finished running through the script, I tried to see if I can display the records which start at a particular start date. But it looks like the internal code that is used for date filtering is not able to read the contents in a straight line… Testing this use case is shown in the below snapshots…



The code that I have created is present below:

# Script designed by Sibin Jose for Hyperion Essbase log file parsing
# This script is designed to be in place

echo "Hyperion Essbase log parser"

if [ $# -eq 0 ]
then
 echo "Incorrect possitional parameters... Usage: log_parser.sh <PATH OF LOG FILE>"
exit 1
fi

export ESSBASE_LOG_FILE=$1
echo ${ESSBASE_LOG_FILE}

#export PARSED_ESSBASE_LOG_FILE=`echo ${ESSBASE_LOG_FILE} | sed 's/.log/_parsed.log/g'`
#echo ${PARSED_ESSBASE_LOG_FILE}


sed -i 's/^\[/#\[/g' ${ESSBASE_LOG_FILE}

tr '\n' ' ' < ${ESSBASE_LOG_FILE} > working_temp.log.txt

mv working_temp.log.txt ${ESSBASE_LOG_FILE}

sed -i 's/#\[/\n\[/g' ${ESSBASE_LOG_FILE}

#sed -i 's/###/\n/g' ${ESSBASE_LOG_FILE}

#sed -i 's/)/)\t/1' ${ESSBASE_LOG_FILE}


#tr '\n' ' ' | sed 's/###/\n/g' | sed 's/)/)\t/1'  > parsed_essbase_log.txt

echo "THe script has finished executing...Please check the folder for parsed_essbase_log.txt file"


Installing Hyperion EPM in a distributed environment in Oracle Virtualbox – Redeploying components to the Web server and accessing the environment

In this blog, which is the final one that covers the install of Hyperion EPM in a distributed environment in Oracle VirtualBox. In this blog, we would be configuring the web server once again and testing if we can access the environment.

Understanding why web server needs to be configured once again after all the servers in the distributed environment are configured. If you observed the above snapshots, you would have noticed that the Java web application are configured on different servers. This is the snapshot when we configured the foundation server at start:

Observe that only Foundation components like Workspace, EPMA and HSS are present initially.

This is the deployment of web apps to the Foundation server application server.

After this deployment, to ensure OHS knows the web apps exist, we need to configure it once again.

The configuration is as shown in the below snapshots.


  
After running the configuration, the next snapshots show us accessing the environment.


This concludes the install of Hyperion EPM in a distributed environment that was created using Oracle VirtualBox.

Thursday 16 February 2017

Installing Hyperion EPM in a distributed environment in Oracle Virtualbox – Essbase server components configuration

This is the seventh blogpost in a series of eight which covers the install of Hyperion EPM components in a distributed environment. The distributed environment has been created using Oracle VirtualBox and is made up of Windows Server 2012.

The link to the previous blog posts is present here:

The configuration of the Essbase server is as shown in the below snapshot:









Installing Hyperion EPM in a distributed environment in Oracle Virtualbox – Planning Server components configuration

This is the sixth blogpost in a series of eight which covers the install of Hyperion EPM components in a distributed environment. The distributed environment has been created using Oracle VirtualBox and is made up of Windows Server 2012.

The link to the previous blog posts is present here:


The configuration of the Planning server is as shown in the below screenshots.