Thursday, October 21, 2021

// // 1 comment

Unable to add/connect or expand Essbase server in EAS (Essbase Administration Services) console

Issue:

When we try to add/connect a new Essbase server or expand an existing Essbase server in EAS (Essbase Administration Services) console to see applications list etc., it keeps loading/rolling for long time and eventually Essbase server doesn’t get added or expanded being hanged, as shown below:

Adding new Essbase server:

Unable to add/connect or expand Essbase server in EAS (Essbase Administration Services) console

Expanding existing Essbase server:

Unable to add/connect or expand Essbase server in EAS (Essbase Administration Services) console


Investigation:

We check the easserver.log for the timestamp and noticed following error:

Log file path: E:\apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\EssbaseAdminServices0\logs\easserver.log

Error:

[2021-10-18T09:17:26.196-06:00] [EssbaseAdminServices0] [ERROR] [ESSEAS-24206] [oracle.epm.essbase.eas] [tid: 18] [userId: <anonymous>] [ecid: 00jBJTZ37vAB1FwDwFj8CW0002es0000Zt,0:1:4] [APP: EAS#11.1.2.0] Failed to handle request for com.essbase.eas.essbase.defs.ServerCommands.Connect. See below stack trace for more information. Possible cause for this exception is missing java archive for this request to handle. Check application server WEB-INF/lib folder or CLASSPATH, if the required java archive file is available.[[
com.essbase.eas.framework.server.defs.ApplicationException: java.net.SocketException: socket write error: Connection aborted by peer
.....
.....
Caused by: java.net.SocketException: socket write error: Connection aborted by peer


Solution that worked for us:

Note: We have Essbase component installed on Linux server and EAS service installed on Windows 20212 R2 server.

Error "socket write error: Connection aborted by peer" is usually caused by writing to a connection that had been aborted by the peer before getting the full response. It means that the other side aborted the connection. Since we are facing this error on client side (EAS console), then the Essbase server side must be the one aborting the connection. In most cases this can be caused either by the timeout issue (e.g. the response takes too much time or server is overloaded with the requests), or the client sent the SYN, but it didn't receive ACK (acknowledgment of the connection termination) from the other side.

We first checked with Network team to see if there is any network issue between the source (EAS server) and the target (Essbase server). But they confirmed it was all ok at Network end.

Then we decided to reboot our Essbase Linux server as the connection was getting aborted from that side.

Steps:
  • Stop Essbase and EAS services.
  • Reboot Essbase (Linux) server.
  • Start Essbase service and then EAS service.
  • Login to EAS console and try to add a new Essbase server or expand an existing Essbase server. It worked fine.

That's all for this post.
I hope this article has helped you. Your suggestions/feedback are most welcome.
Keep learning and Have a great day!!!

Share this post:
Read More

Saturday, July 31, 2021

// // 1 comment

Oracle Middleware Home, EPM Oracle Home and EPM Oracle Instance

In this post, we will see three important directories related to Oracle EPM installation and configuration:
  1. Oracle Middleware Home
  2. EPM Oracle Home
  3. EPM Oracle Instance
Oracle Middleware Home

In an Oracle EPM system, Oracle Middleware home consists of Oracle WebLogic Server home and EPM Oracle home. You can setup your Oracle Middleware home either on a local file system on the server or on a remote network shared location. 

When you do EPM installation and configuration first-time, you need to define Oracle Middleware Home, which will be then used for all further EPM product installations on that system. 

Oracle Middleware Home installation directory is referred as MIDDLEWARE_HOME with default location as Oracle/Middleware on your EPM system.  For example it could be:

MIDDLEWARE_HOME : E:\apps\OracleEPM\Middleware
Below is an example of MIDDLEWARE_HOME directory structure:

Oracle Middleware Home, EPM Oracle Home and EPM Oracle Instance


EPM Oracle Home

EPM Oracle Home resides within Oracle Middleware Home and contains following things:
  • Files/folders related to EPM applications/products installed on that EPM system
  • Files/folders related to common internal components used by these EPM applications/products .
You cannot change the EPM Oracle Home location, so before starting the installation and configuration of EPM applications on a system make sure you have allocated sufficient disk space to your EPM Oracle Home drive to accommodate all the EPM applications/products that you are going to install on that system. 

The default EPM Oracle home location is MIDDLEWARE_HOME/EPMSystem11R1. EPM Oracle home location is defined in the system environment variable called EPM_ORACLE_HOME. For example it could be:

EPM_ORACLE_HOME : E:\apps\OracleEPM\Middleware\EPMSystem11R1

In a distributed EPM environment setup, the EPM Oracle home directory structure must be the same on each machine of that EPM environment. For example, if the path for EPM Oracle home is E:\apps\OracleEPM\Middleware\EPMSystem11R1 on the first machine you configure, it must be E:\apps\OracleEPM\Middleware\EPMSystem11R1 on all the other machines in the deployment.

Below is an example of EPM_ORACLE_HOME directory structure:

Oracle Middleware Home, EPM Oracle Home and EPM Oracle Instance


EPM Oracle Instance

EPM Oracle Instance contains one or more EPM components like Oracle HTTP Server (OHS), Oracle Essbase Server, one or more Java web applications in one or more domains. 

Unlike EPM Oracle Home, EPM Oracle instance can reside anywhere; it need not to be within the Oracle Middleware home directory.

The default location for the EPM Oracle instance referred to as EPM_ORACLE_INSTANCE is MIDDLEWARE_HOME/user_projects/epmsystem1. For example it could be:

EPM_ORACLE_INSTANCE : E:\apps\OracleEPM\Middleware\user_projects\epmsystem_web

Java web applications are deployed to MIDDLEWARE_HOME/user_projects/domains/domainName for example it could be: E:\apps\OracleEPM\Middleware\user_projects\domains\EPMSystem.

For a distributed EPM environment, you need to create a new EPM Oracle instance on each machine of the environment. But if you are installing all EPM products on a single machine, then all EPM products are configured under a single EPM Oracle instance what you create for the first product configuration.

Below is an example of EPM_ORACLE_INSTANCE directory structure:

Oracle Middleware Home, EPM Oracle Home and EPM Oracle Instance

That's all for this post.
I hope this article has helped you. Your suggestions/feedback are most welcome.
Keep learning and Have a great day!!!

Share this post:
Read More

Monday, June 14, 2021

// // 1 comment

How to change temporary (temp) directory in Oracle Essbase Server

Recently we got a critical alert where /tmp directory on our Essbase Linux server (Version: 11.1.2.4.033) was utilizing more than 90% of total allocated space. When we checked, there were many temporary Outline(.otl) files created under the /tmp directory. Most of them were of few KBs size but couple of files were really huge-sized of around 2gb each causing this space crunch alert under /tmp directory. Below is some of those huge sized .otl files listed:
-rw-r----- 1 epmadmin sapsys 2049736704 May 22 12:39 0oKEzW.otl
-rw-r----- 1 epmadmin sapsys 1370583040 May 22 07:43 MsnP8R.otl
-rw-r----- 1 epmadmin sapsys 2049994752 May 22 12:53 spQfrr.otl
-rw-r----- 1 epmadmin sapsys 1360232448 May 22 07:43 wpWopg.otl
Temp directory mostly contains files that are required temporarily. Many Essbase activities use this to create lock files and for temporary storage of data. When an Essbase outline is opened, it creates such temp files. Other activities like HPCM application deployment to Essbase and FDMEE data load to Essbase, Metadata load to Essbase etc. also can create these temporary files. 

Usually, Essbase doesn't produce such huge sized temporary files. Mostly you will see the size in KBs only for such temp files. These temporary files are normally deleted automatically when the related operation is over. But on some occasions you will observe they are not automatically deleted.

We noticed that when these huge sized temporary files (around 2gb per file) are created under /tmp directory on Essbase Linux server, it not only causes /tmp directory go out of space with 100% utilization but also the following issues encountered at the same time:
  1. Essbase server gets hanged.
  2. FDMEE data load to Essbase gets failed.
  3. Unable to load Essbase applications in FDMEE 'Target Application' interface.
Apart from the above listed ones, there might be even more problems. All in all, these issues point towards 'Essbase server disconnection' at that particular point of time. 

So in order to fix it, as a temporary workaround, we moved all those huge-sized temporary .otl files from /tmp directory to some other location and it fixed all the issues. You can also delete these temp files, if not required.

In a Windows server, the temporary directory is set by the environment variable TEMP. In UNIX/LINUX server, the temporary directory is /tmp filesystem. As /tmp is a Linux/Unix OS Filesystem, it is not recommended to use OS file system for application usage because it may lead to even server crash if all /tmp space is consumed at any point of time. So the safe way out is to have a separate temp folder assigned for Essbase application usage other than OS /tmp directory.

Workarounds

As mentioned above, instant workaround is to move/delete these temporary files to clear up some space under /tmp directory.

But as a permanent fix, we decided to have a separate temp directory assigned to Essbase application, that we will discuss ahead.

Changing the Default Location for Essbase Temporary Files on Linux Platforms:

On Linux platforms, Essbase uses OS /tmp directory as the default location for creating temporary files.

To create temporary files in a different location, you must set the temp directory environment variable in opmn.xml and in setEnv.sh configuration files.

To set TEMP/TMP environment variable in opmn.xml

1- Find opmn.xml file on your Essbase server located at below path: /apps/oracle/epm/Middleware/user_projects/epmsystem_ess/config/OPMN/opmn/opmn.xml

2- In opmn.xml file, look for the following default entries:
<environment>
<variable id="TEMP" value="/tmp"/>
<variable id="TMP" value="/tmp"/>
</environment>
3- Change the default values of TEMP and TMP variables to your desired location as shown below and save the opmn.xml file :
<environment>
<variable id="TEMP" value="/apps/oracle/epm/Middleware/user_projects/epmsystem_ess/tmp"/>
<variable id="TMP" value="/apps/oracle/epm/Middleware/user_projects/epmsystem_ess/tmp"/>
</environment>

To set TMPDIR in setEnv.sh

1- Find setEnv.sh file on your Essbase server located at below path: /apps/oracle/epm/Middleware/user_projects/epmsystem_ess/bin/setEnv.sh

2- By default there will be no entry set for TEMPDIR in setEnv.sh (means your OS /tmp directory will be used to store temporary files). 
To change the default location, add the following entry at the end of setEnv.sh file and save it:
TEMPDIR="/apps/oracle/epm/Middleware/user_projects/epmsystem_ess/tmp"
export TEMPDIR
Note: You have to restart Essbase services to make these changes effective.

That's all for this post.
I hope this article has helped you. Your suggestions/feedback are most welcome.
Keep learning and Have a great day!!!

Share this post:
Read More

Thursday, May 20, 2021

// // 2 comments

Password Policies and Account Lockout Measure on EPM native 'ADMIN' and External Directory Users

As part of EPM Application audit and security control, most of us would have got this requirement to apply User account lockout measures on all EPM users whenever there is some specified number of consecutive failed login attempts.

Being no exception we too faced this question. Our security team had released following 'Account lockout' requirements to be implemented in EPM:
  • Account lockout after 6 or less consecutive failed login attempts.
  • Re-enable locked account after 30 minutes of lockout.
So we explored the available options in EPM that I have shared below.

We know there are mainly two types of users in EPM system:
  1. Hyperion Shared Services Native users (Admin etc.)
  2. External directory users (Microsoft Active Directory-MSAD, LDAP-enabled user directory, Oracle Internet Directory-OID etc.)
Lets see both one by one.

Hyperion Shared Services Native Directory users (Admin etc.)

There is no inbuilt account lockout and password policies setting for EPM Native Directory users including EPM Shared Services ‘Admin’ account. Therefore EPM Shared services 'Admin' account never gets locked after any number of unsuccessful login attempts (due to the obvious reason that if ADMIN gets locked in EPM then none can unlock it). 

On entering wrong password for EPM native ‘Admin’ account, it keeps throwing following error without being locked:
EPMCSS-00301: Failed to authenticate user. Invalid credentials. Enter valid credentials.

Password Policies and Account Lockout Measure on EPM native 'ADMIN' and External Directory Users

You can mitigate this risk for native 'Admin' user failed login attempts by creating a script or using any log analyzing tool to monitor Framework.log present on all Foundation servers (E:\apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\FoundationServicesN\logs\Framework.log) which records the messages for both successful and failed login attempts made by EPM native 'Admin' user.

External directory users (Microsoft Active Directory-MSAD or an LDAP-enabled user directory such as Oracle Internet Directory-OID)

There is no settings within EPM application (till EPM 11.2 release) which can be used to control password policies and account lockout measures for external directory users. 

For external directory users (MSAD, LDAP, OID etc.), password policies and Account lockout measure on failed login attempts can be enforced and controlled at external directory side setup only. So you can check with your external AD team and define password policies for external AD users to specify how many logon attempts to allow before locking out end users and how they will be unlocked. 

EPM System honors all locks controlled by the password policies for the external user directory. Whatever Account lockout policy is set there by your Active Directory (AD) team, EPM system will simply follow that.


That's all for this post.
I hope this article has helped you. Your suggestions/feedback are most welcome.
Keep learning and Have a great day!!!

Share this post:
Read More

Tuesday, May 18, 2021

// // Leave a Comment

EPM 11.1.2.4: EPMA is not compatible with Google Chrome and Microsoft Edge browsers

To get the context of the issue discussed in this blog, I would suggest you to first read following two posts:

EPM 11.1.2.4: Microsoft Edge and Google Chrome browsers support patching : Part-1
EPM 11.1.2.4: Microsoft Edge and Google Chrome browsers support patching : Part-2

In order to make EPM 11.1.2.4 environment compatible to run on Google Chrome and Microsoft Edge browsers we apply some patches mentioned in the following knowledge article: 


Post patching when we validated our EPM environments, all applications like Workspace, Essbase, HFM, HPCM, DRM, FDMEE are working fine. We haven't faced any showstopper issue/error in these applications as such.

But its important to note here that EPMA is not compatible with Google Chrome and Microsoft Edge browsers. It not like EPMA doesn't work at all on Google Chrome and Microsoft Edge browsers. You may face issue while using few of the EPMA functionalities.

One such issue is when we try to create Import Profile in EPMA Dimension Library (EPMA dimension library--File--Import--Create profile--New Profile--File Properties), there is a blank screen coming in place of "File Properties" page in Chrome and Edge browsers. While the same works fine in Internet Explorer browser. Please notice following screenshots depicting the same:

In Google Chrome and Microsoft Edge browsers (Blank Screen):

EPM 11.1.2.4: EPMA is not compatible with Google Chrome and Microsoft Edge browsers

In Internet Explorer browser (Working):

EPM 11.1.2.4: EPMA is not compatible with Google Chrome and Microsoft Edge browsers

So you can recommend your end users to use IE (Internet Explorer) only for EPMA related work. For other applications, Google Chrome and Microsoft Edge work all fine.

That's all for this post. Please let me know in comment box how the latest browsers support patching goes for you.

That's all for this post.
I hope this article has helped you. Your suggestions/feedback are most welcome.
Keep learning and Have a great day!!!

Share this post:
Read More

Tuesday, April 13, 2021

// // 2 comments

EPM 11.2 : 5 Ways To Find Oracle WebLogic Server Version in EPM 11.2

In this post, we will explore 5 ways to find Oracle WebLogic Server version in EPM (Enterprise Performance Management) 11.2 environment. Knowing your WebLogic Server version comes in handy especially when you are planning to apply latest Oracle patches to make WebLogic servers security-compliant in your EPM 11.2 setup. 

EPM (Enterprise Performance Management) 11.2 by default comes with Oracle WebLogic Server 12c (12.2.1.3). Since in Oracle WebLogic Server 12c, the installation directory structure has changed, the usage of registry.xml / java weblogic.Version is a bit different than 11g release. 

Method-1: Oracle WebLogic Server Administration Console

1-Login to your WebLogic Admin console.

2-In the left hand panel, under 'Domain Structure' menu, navigate to Environment—Servers and click on ‘AdminServer’ from the server list. Now click on the ‘Monitoring’ tab and you will see below screen showing your WebLogic version (WebLogic Server 12.2.1.3.0 as shown below):

5 Ways To Find Oracle WebLogic Server Version in EPM 11.2

Method-2: AdminServer.log

1-On WebLogic Admin server, goto the path: E:\Oracle\Middleware\user_projects\domains\EPMSystem\servers\AdminServer\logs

2-Open AdminServer.log file and search for "Version: WebLogic Server".

3-You will get output like below which will tell you your WebLogic server version (WebLogic Server 12.2.1.3.0 as shown below):

5 Ways To Find Oracle WebLogic Server Version in EPM 11.2

Method-3: registry.xml file

1-On WebLogic Admin server, goto the path E:\Oracle\Middleware\inventory.

2-Open registry.xml file and search for “WebLogic Server”.

3-You will get output like below which will tell you your WebLogic server version (WebLogic Server 12.2.1.3.0 as shown below):

5 Ways To Find Oracle WebLogic Server Version in EPM 11.2

Method-4: java weblogic.version

1-On WebLogic Admin server, open command prompt as an Administrator and goto the following path:
cd E:\Oracle\Middleware\wlserver\server\bin
2-Now run below command to first set environment variables for WebLogic server and then display your WebLogic Server version (WebLogic Server 12.2.1.3.0 as shown below): 
setWLSEnv.cmd
java weblogic.version | findstr "WebLogic Server" 
5 Ways To Find Oracle WebLogic Server Version in EPM 11.2

3-For Linux server, command will be like below:
setWLSEnv.sh 
java weblogic.version | grep "WebLogic Server"

Method-5: viewInventory.cmd

1-On WebLogic Admin server, open command prompt as an Administrator and goto the following path:
cd E:\Oracle\Middleware\oui\bin
2-Now run below command to see your WebLogic Server version (WebLogic Server 12.2.1.3.0 as shown below):
viewInventory.cmd | findstr "Distribution:"
5 Ways To Find Oracle WebLogic Server Version in EPM 11.2

3-For Linux server, command will be like below:
viewInventory.sh | grep "Distribution:"

All the 5 methods are equally applicable to Linux servers as well (with the corresponding change in command/script), in order to find Oracle WebLogic server version.

That's all for this post.
I hope this article has helped you. Your suggestions/feedback are most welcome.
Keep learning and Have a great day!!!

Share this post:
Read More

Friday, April 9, 2021

// // Leave a Comment

EPM 11.2: How to check FDMEE application patch version

Its important to know the current patch version of your EPM (Enterprise Performance Management) products/applications, especially when you are planning to apply any new Oracle patches or want to check the compatibility of existing EPM applications with any other products/software/tools.

For FDMEE (Financial Data Quality Management, Enterprise Edition), you can check its current patch version using following methods:

1. AIF_version.xml (more reliable method):

This is the most reliable method because when you apply any new patch to FDMEE, this is the file which will be updated with the new patch level so it always shows the current version of your FDMEE application.

On FDMEE server, you can find AIF_version.xml file in the following folder:

E:\apps\OracleEPM\Middleware\EPMSystem11R1\products\FinancialDataQuality\xml\AIF_version.xml

When you open this AIF_version.xml file, FDMEE version will be displayed as shown below:

EPM 11.2: How to check FDMEE application/patch version

2. Workspace (Not always the true reflection of the current patch level of EPM products)

To see your EPM products versions in Workspace, navigate to: 

Workspace-->Help-->About Oracle Enterprise Performance Management System Workspace, Fusion Edition

You would have seen on many occasions that the EPM products version number shown in Hyperion Workspace do not match the patch versions that have been recently applied in an EPM environment.

It happens because EPM java web applications versions shown in Workspace are sourced from Shared Services registry (logical web application entry--displayVersion property).

EPM 11.2: How to check FDMEE application/patch version

Further the versions displayed in Shared Services registry are sourced from some property/configuration files of the respective EPM products which get updated immediately after applying any new patches. For example, in case of FDMEE, its is AIF_version.xml file as mentioned in method-1.

Sometimes, applications version shown in Workspace or the displayed version shown in Shared Services registry does not get refreshed from the respective source file of that application. And that's when you see a mismatch in version shown in Workspace and the actual application version. And that's why method-1 is more reliable one to know the FDMEE current patch version.

That's all for this post.

I hope this article has helped you. 
Your suggestions/feedback are most welcome.
Keep learning and Have a great day!!!
Read More