Financial Reporting Studio firewall fun

Another quick blog from me, I was recently working on an 11.1.2.2 windows environment build with a customer who had a strict policy to enable the windows firewall between servers and the users accessing the system, I have never really had much dealings with firewalls as I have been lucky enough to work with internal networks which have been firewall free.

I had no issues with the server to server communication and the users were mainly accessing the system through the web using OHS on port 19000 and the Excel addin (it still lives on), these also proved to be no problem on the firewall front.

There were a number of power users who were also report building with the Financial Reporting Studio, now Financial Reporting has never been a friend of mine and it is has been designed to give me grief.

If you have ever configured a firewall for Financial Reporting Studio then this will probably be no interest for you and you can have a nice cup of tea and devote your time to a different blog :)

I stupidly though that by now in the 11.1.2.2 world that the FR studio will just go through the http server port 19000 and all will be good but no it still seems it living with its looks in prehistoric times.

Anyway, port 19000 was already opened to allow inbound traffic to the web server.

Ok, time to log into the Financial Reporting Studio on a client machine.

Now if you have never seen the above message before you have never used FR Studio, it basically means some sort of problem exists and you are going to have to spend time trying to work it out what because there seems to have been no investment in all these years FR studio has existed in error trapping and messaging.

I have lost count of the amount of times I have seen this message be posted on forums and if you search for the message in Oracle Support you will be inundated with articles.

A quick look at the “Oracle Enterprise Performance Management System Communication Flows” spreadsheet reveals the following:

So the Studio does not just communicate directly with the HTTP server and also requires the RMI default ports of 8205-8209 opening.

The RMI ports are added to the firewall rules so time to try again.

The login was successful so case closed; come on this is FR studio we are talking about life is not so simple…
Opening a report produced:

The communication flow document did not highlight any additional ports for the Studio use but obviously it does use some.

A Wireshark trace highlighted:

 The FR Studio was communicating on a dynamic port.

I referred to the ports section of “Oracle Enterprise Performance Management System Installation Start Here” and it contained more information than the flows spreadsheet by specifying that FR also uses an ADM server with dynamic ports which can be configured in a propertiesd file.

I always incorrectly thought the ADM communication was internal but apparently not though why does it need to be dynamic?
 

Just when you think that most of the properties have been moved to the Shared Services registry you find out there are more file based ones out there.

As you can see there is commented out parameter ADM_RMI_SERVER which must mean that it takes the default value or 0 and a dynamic port range.

I set the port to a value close to the other RMI service port range and restarted the Financial Reporting web app.

 The new port was added to the inbound firewall rules.

 

Opening financial Reports was successful and there were no other notable problems, now I know there is an article in Oracle Support on a similar topic but personally I find that trying to solve the issue first proves to be much more satisfying than being handed something on a plate.

One more thing if you do see the following error popup when you log into Financial Reporting Studio:

It might be down to the version of the Studio, in my case I was running 11.1.2.2 Studio and Financial Reporting had been patched to 11.1.2.300 so it is always good to make sure the versions are exactly in sync, this can simply be achieved by downloading Studio from Workspace.

Changing the EAS web console heap size

Recently I was asked about a heap size issue with the 11.1.2.1 EAS web console, now I have never seen the following error before and probably won’t again as business rules slowly merge into calculation manager.

The reason I had probably not seen it before is because I don’t think I have had to deal with many rules that are 2MB in size and trying to save the rule in EAS would generate the error.

Anyway I was not going to even attempt to get into the reason why the rule was so big and just increase the maximum java heap size for the console.

If this was the standard EAS console then increasing the heap size is straight forward and just requires an edit to:

<drive>:\Oracle\Middleware\EPMSystem11R1\products\Essbase\eas\console\bin\admincon.bat

Update the –Xmx value from the default 256MB and restart the console and that’s it.

Increasing the maximum JVM size for the web console does not seem as simple though I am hoping somebody comes along and tells me I am idiot and provides a simpler solution.

If you start the web console you can see the min and max size being passed into Java

The default heap sizes are min 32MB and max 256MB.

I originally thought I could override the settings through the Java control panel

This did not seem to make any difference and the clients Java control panel was locked down so it wouldn’t have been that simple to get it implemented if it did work.

When starting up the EAS web console it reads a jnlp (Java Network Launching Protocol) file to set the parameters passed into the Java application so the file must exist somewhere in the EAS web application.

I found an easconsole.jnlp file sat in the easconsole.war file which is deployed with the EAS web app server.

I updated the file to increase the value held in the max-heap-size parameter, deleted the EAS web application server tmp folder and restarted the web application.

Still no joy the jnlp file that was being delivered still had the default settings, surely that is the file that is being used…Well maybe it was in previous versions but it is not being used in 11.1.2.1

I should have just left it there but it would play on my mind if I didn’t find the right file.

After searching some more I found another easconsole.jnlp

This file was hidden away within a java archive file webstart_server.jar within the EAS console web application.

I updated the file to increase the max to 1024MB, cleared the EAS web app tmp directory and browser cache then started the web app up again.

Success, this time the file I updated was the one being used by the web application.

It worth mentioning that hacking the files in a web app does work but if you patch EAS server it could wipe out any configuration settings and they would need to be applied again.

Now I am sure there is an easier solution and in the end the option taken was to use the standard EAS console with the simple method to increase JVM.

I will probably never have to do that again but at least I have written it down in case. :)