About Me

Anjum Ara I am a technology enthusiast, an ardent reader. My latest interest is virtualization. In my free time, I love understanding child nutrition, child holistic development. I bake, read, paint, and do whatever it takes to improve myself every day.

Tuesday, April 19, 2016

A connection to the server has failed (Status=503)

We got this error when one of the long running rules was timing out. I knew I could fix this in a jiffy since we faced this issue multiple times but to my surprise that was not the case. I logged into the environment and found that there was no Oracle HTTP Server (OHS) , client had used IIS as the Web Server. I had to read quite a few documents related to Weblogic and IIS.

Here is first a little from what I understood about the two,
Weblogic uses IIS plugin. This plugin allows requests to be proxied from IIS server to the Weblogic Server. The static pages of the Hyperion website are rendered by the IIS server and all the dynamic pages like the JSPs, HTTP Servlets are rendered by the Weblogic (hfm.war) .


The directory structure of the epm instance will have a folder D:\Oracle\Middleware\user_projects\httpconfig\virtualdirectories
This contains folder for every location like Planning , HFM , Reporting etc.
Each folder contains a file IISPROXY.INI.

 Issue Screenshot


Cause:
 Timeout is set too low for current task to complete.


Solution for IIS Web Server
1.Go to the location of iisproxy.ini and add these values to the file

HungServerRecoverSecs=1800
WLIOTimeoutSecs=1800


Do not miss the '=' sign.
HungServerRecoverSecs is replaced by WLIOTimeoutSecs and





Solution for OHS Web Server

1. Go to the mod_wl_ohs.conf file and add WLIOTimeoutSecs to the respective location where issue exists.

<LocationMatch ^/aif>
    SetHandler weblogic-handler
    WeblogicCluster SERVERNAME:6550
    WLIOTimeoutSecs 1800
</LocationMatch> .



These settings can be done at the time of setting up the environment as a preventive measure. Saves a downtime and loads of frustrated users. 
Share:

Sunday, April 17, 2016

Improve Performance of slow running Business Rules - Hyperion Planning

Improve Performance of slow running Business Rule - Hyperion Planning


We had this client who complained that their rules take more than 8 minutes to run where it should have taken hardly 3 seconds. This was a vast difference. We were able to resolve this hurdle by doing the things below

1. Fine tune your rules. This is really important, make sure the rules are efficient. Since I am not from the Planning development side so I would know only little on this. An expert in writing rules will always craft efficient rules. 

2. Fine tune your environment: This makes a significant difference in the performance of the system.
Tune the Essbase Server , Hyperion Services - Planning, Shared Services, OHS, Windows System, Weblogic . Follow this guide -  Tuning Guide 11.1.2.X

3. Run Time Prompts (RTP) are a great help for more focused calculations. Planning validates the values entered. By default, the values for processed runtime prompts in the application are stored in the database and available for viewing from the Job Console (select Tools, then Job Console). If many users are running business rules with runtime prompts, tracking these values consumes significant system resources. To improve performance, you can turn off this function so Planning does not capture runtime prompt values. To do so, add the CAPTURE_RTP_ON_JOB_CONSOLE property to the properties table, with the property value of FALSE (to turn it back on again, change its value to TRUE). See more details here



Disabling this made the performance of the system super-fast. We were able to run the Business rules in less than 3 seconds. 

4. Use sample application: Using Sample Planning application will really be helpful in troubleshooting performance issue. I usually load the planning sample app and then test its performance against the system. If it works fine, I  know that the environment is not the one that needs further tuning but it is the application design , business rules that need a little makeup. 

5. It also depends on the network configuration of the environment. If the Essbase is in different Network zone from Planning, of course there would be lag. 
IPSec tables have caused slowness when applied between the server in the environment. 
QoS also caused slowness. Get the Network team to play around and tune down the network security to minimal limits between the server in a secure environment. 

Hope this helpful.
.


Share: