Sunday, 9 November 2014

Planning – setting the cell retrieval threshold update

In a previous blog I went through the reasons why setting the cell retrieval threshold was important if you want to maintain a healthy JVM and how to interrogate a heap dump using third party software, if you have not read the post then it is probably worth having a read through it to gain some background information.

In the blog I highlighted that a patch was available for that allowed to set the maximum cell retrieval but unfortunately this had not made it into the on-premise as of the .500 PSU even though it was available in the cloud version, I had this light hearted message for Oracle.

Now I know Oracle would have not taken any notice of it but luckily with the recent planning PSU the following defect was addressed.

18663876, 18259065 - When retrieving data through Smart View Ad-Hoc Analysis, any number of rows or columns is retrieved, despite the preferences which were set.

After applying this patch, the below mentioned property need to be set in Administrator -> Application -> Properties screen ERROR_THRESHOLD_NUM_OF_CELLS -> Value for this property will be the maximum number of cells for which the error messages is shown to the user during Ad-hoc Grid operation.

Note 1: This fix applies to Planning data simple forms, SmartView Ad-hoc and Financial Reports against Planning application.
Note 2: Unless overridden, default value of this property -ERROR_THRESHOLD_NUM_OF_CELLS is 250000 cells.

So the functionality has finally made it to and to be sure it was working I had to test it out.

After applying the .501 PSU I created and opened an extremely large form in planning that would pass the default threshold of 250,000 cells.

Good news the functionality has been implemented, so how about a large ad-hoc Smart View retrieve through the planning layer.

All good, it is working as expected.

The remaining test it to set the planning property ERROR_THRESHOLD_NUM_OF_CELLS to control the threshold.

It is shame you still have to restart the planning web application server to apply the changes.

Running a large form confirmed that the new threshold of 10,000 cells has been honoured.

The same positive results with a Smart View ad-hoc planning retrieve.

If you are running planning and want to use this functionality then get patching to 501 or newer.

Essbase standalone mode is no more

I am sure some of you are wondering what the hell is Essbase standalone mode anyway, well before the days of System 9 and Shared Services there was only the Essbase native security mode to manage security, the days where each Hyperion product was a separate entity and then came along System 9 and the start of central security integration through Shared Services (yes there was the hub prior to that but in my experience it was not commonly used).

As the product set increased it made more sense to manage security in one location and over time Shared Services was the new home to do this for the core products.

This meant that Essbase standalone mode became more of a rarity and it was only really used if a customer had just purchased Essbase and had no interest in Shared Services.

Even now in the option to deploy Essbase in standalone mode is still available though I expect that to be gone from

In a recent Essbase PSU readme there was the following statement:

Essbase Native Security Mode Is No Longer Supported
Caution! Oracle strongly recommends not using Essbase native security mode because of security concerns. If you are currently using Essbase native security mode, you should convert Essbase Server to EPM System security mode and migrate users to EPM System security using Administration Services Console. See “Converting Essbase Server and Migrating Users to Shared Services” in the Oracle Essbase Administration Services Online Help. After you complete the conversion and migration tasks, Essbase security is managed as described in the Oracle Enterprise Performance Management System User Security Administration Guide.

So basically standalone mode is no more, I am finding more and more that Oracle seem to be releasing information in Readmes and I find it gets lost in all the noise, with the amount of different patches it is not easy to remember where you read the information and because it is a patch it doesn’t seem to make it to the documentation until the next major release.

Also I have noticed that Oracle are going back to patch readmes and updating the information in them, the native security is no longer is a prime example because now that has appeared in PSU 503, I checked the original readme and it was not in there, also you can see the date release in Oracle Support has changed.

The information is not in PSU 502 so I assume it came into force in 503.

It is annoying the fact that the readmes are being updated without being informed, I know patch 500 was a classic as it now contains much more information in the readme that it did when it was originally released, it would nice if Oracle provided some versioning on the readme so you can easily find out what has been added or changed, most people use versioning on documentation so I don’t see why Oracle can’t.

The moral is each time you patch go and have a look at the readme again in Oracle Support because it may have changed from one day to the next.

Anyway if you are using Essbase native security in then it is time to change and if you currently using it and are going to upgrade then be aware it is no longer supported.