Sunday, 9 November 2014

Planning 11.1.2.3 – 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 11.1.2.2 that allowed to set the maximum cell retrieval but unfortunately this had not made it into the on-premise 11.1.2.3 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 11.1.2.3.501 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 11.1.2.3 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 11.1.2.3 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 11.1.2.3 the option to deploy Essbase in standalone mode is still available though I expect that to be gone from 11.1.2.4


In a recent Essbase PSU 11.1.2.3.504 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 11.1.2.3 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.

Wednesday, 1 October 2014

11.1.2.3 LCM – Classic planning dimension import changes

I know 11.1.2.3 has been around for a while now but I have been asked a few times about the differences with  how LCM loads dimensions between 11.1.2.3 and earlier.

I have meant to write a quick blog post on the subject for ages and never got round so here it is and then I can forget about it ?

Prior to 11.1.2.3 if you load dimension metadata using LCM to a classic planning application then the hierarchy between the source and target application will match, so basically it is replacing instead of merging, this goes against other artifacts being loaded into planning with LCM as they will follow the update/insert method and never delete.

I have always wished for an option to delete on target with LCM and Planning but that is a different story.

So let’s take an example in 11.1.2.2 and is true for earlier versions, say we have the following entity dimension which is identical between a source and target application.


The shared member “E03_310_1000” in the source application is deleted and use LCM to extract dimension.

If you take a look at the LCM output the dimension metadata is contained in an xml file.


Examing the xml file before the member was deleted it contained the following.


Obviously after the member was deleted the above information is removed from the LCM xml output.

After using LCM to load the Entity dimension into the target application the source/target should match and member “E03_310_1000” will have been deleted.


Moving on to 11.1.2.3 the method LCM uses changes and unless I have missed something in the mass of documentation I don’t see it mentioned, please let me know if I have missed it and I will update.

Running the same LCM example in 11.1.2.3 the source/target will not be matched and members in the target will not be deleted, members will only be updated/inserted.

Examining the LCM output in 11.1.2.3 you will notice that the dimension files are no longer xml and are csv.


Opening up the csv reveals the changes, now there is some xml embedded in a header block which relates to the dimension properties.


After the header block there is something very familiar if you have used the planning outline load utility, yes the format looks exactly the same.


In the planning documentation there is further information to back up the fact that the outline load utility might be used in 11.1.2.3, the admin doc has information about the header block and is reserved for internal use, I doubt you would have seen anything about HEADERBLOCK if you have been using the utility before.


The theory also holds true for the utility being used because the default load operation is update which means members will be added, updated or moved.

To confirm the utility is being used I updated the csv file to delete one member.


I added in the operation field which does not exist in the LCM export, the field has the following options:


The LCM import completed successfully.


Checking the hierarchy before and after the LCM import you will see it successfully deleted the shared member “E03_310_1000”



That pretty much confirms that LCM does use the outline load utility, it is also worth pointing out that a planning refresh will automatically happen with LCM, this is an additional parameter if the outline load utility is being used directly.


So what are the options for deleting members, well you can update the LCM csv file, use the outline load utility or the planning web version or even manually delete.

I still believe it would be nice to have an option in Shared Services to select whether it should be merge or replace import mode like that is available for EPMA.


If you intend on using LCM to migrate a planning application from a previous version then look at updating to the new format otherwise it may be painful ?

Thursday, 18 September 2014

APS 11.1.2.3.502 diagnostic report failure

If you are running 11.1.2.3 and a Provider Services version before patch 502 then if you run a diagnostics report you should hopefully see a pass for the Essbase web services.


If you decide to apply patch 502 or later then there are some changes that have been made to the web services.

After applying 502 the diagnostics report should report two failures with the Essbase web services, one for the web application and one for the http server.


If you use the web services or are interested in why the report has suddenly started displaying failures then within the readme there is a hint under the documentation updates.

WSDL URLs for Essbase Web Services
The WSDL (Web Service Description Language) URLs for Essbase Web Services are disabled by default. Before using Web Services, enable WSDL using the Oracle Enterprise Manager user interface. See the Oracle Enterprise Manager documentation.


So it looks like there has been a change and the WSDL URLs which were previously enabled by default allowing the Essbase web services to be used  are now set to be disabled.

If you would like to enable the web services then this can be done in Enterprise Manager which is deployed by default in 11.1.2.3, start up the WebLogic admin server and go to:
http:// <server>:7001/em



Select the Provider Services WebLogic managed server and then Web Services



Select the “Oracle Infrastructure Web Services” tab, under the Web Service Name click “AdminServicePortType” Endpoint Name and then the configuration tab.


The WSDL will be set to false which was previously set to true, set the value to true.

Also set WSDL to true for the following Endpoint names “DatasourceServicePortType” and “QueryServicePortType

Once set restart the provider services web application.

If you run the diagnostic report again this time it should pass for the Essbase web services.


If you don’t intend on using the web services then it is probably not worth enabling and putting up with the failures as they are harmless.

Sunday, 17 August 2014

Understanding product versions in workspace

Have you ever wondered how the display version operates in workspace or questioned why the version has not been updated after a patch has been applied, if so then this might be of interest to you.


I know I have been asked on many occasions by customers why the version number in workspace does not match the patch that has been applied in an environment, I usually say that workspace should be not be counted on as a true reflection but never gone into detail why not.

I am going to attempt to go through the main core products and show where the version number is populated from, you might be naïve and think that it is one standard for all but please remember this is EPM and still under the covers it is a mishmash of products all working in different ways.

This is going be based on 11.1.2.3 but it should be relevant for 11.1.2.2 and possibly earlier depending on product.

So let’s take the workspace and UI version first.


The above versions are contained in two property files within the workspace web application.

Located in
<MIDDLEWARE_HOME>\EPMSystem11R1\products\Foundation\workspace\InstallableApps 
is the enterprise archive file workspace.ear and contained within the packaged file is the web application archive file workspace.war

 

The two property files contain the current version number.


To prove this I updated the version number in the files and repackaged them.


 A restart of foundation is required to deploy the changes.


Ok so that shows where those versions are sourced from.

Now let’s move on to planning which is currently displaying the following version in workspace.


For the majority of java web applications the version number can be found in the Shared Services registry.


If you run a registry report and look at the logical web application entry then you will see a displayVersion property which workspace reads in when selecting the help > about menu.

This is fine but when you apply a patch there is usually no interaction with the registry so the version must originate from somewhere before the registry being updated.

For planning there is a property file located in the java archive file
<MIDDLEWARE_HOME>\EPMSystem11R1\products\Planning\lib\HspJS.jar


The PlanningConfig file contains the planning version.


Once again I will update the version and repackage the file.


When the planning web application is restarted the version in the file is checked against the display version in the Shared Services registry and if they don’t match the registry is updated.


Restart the foundation web application again and the version in workspace should be updated.


On to HFM which is again slightly different to where the version is sourced from.


The version is contained within the web application archive but this time it is derived from the manifest file in the META-INF directory.


The manifest is a special file that can contain information about the files packaged in an archive file and in this case the version is read from the Implementation-Version line.

To confirm this I updated the version in the manifest file.


Restarted the HFM java web tier service and checked the HSS registry.


The display version is updated in the FM LWA and ADF LWA entries but workspace only uses the version in the ADF entry.

Restart Foundation and the new version is displayed.


Now you should have got the concept I will quickly go through some of the other core products, each of them the version is read from the HSS registry in workspace but the version is updated in the registry from the following source files:

Provider Services – This also uses the manifest located in the ess_es_server java archive file



Financial Reporting - This also uses the manifest located in the HReports java archive file


FDMEE – Yet again a slightly different way of maintaining the release version and is stored nice and simply in an xml file.


Calculation Manager uses the build version within a property file in the calcmgrcommon java archive file


EPMA is always different and there is property file file within the structure of the java web application archive.


The version displayed is a combination of the awb.display.version and build.number property.

The Reporting and Analysis Framework version doesn’t look to me like it gets updated unless there is a direct change to the display version in the HSS registry for the RA_FRAMEWORK_LWA entry.

You may have noticed I have not mentioned Shared Services and this is because in 11.1.2.3 it is embedded in workspace and unless I am missing something there is no option to view the version in workspace.

In previous versions when Shared Services was separate the version was available by using the help > about option in the Shared Services console.


The version is not read from the HSS registry and is sourced from the manifest in the interop-sdk java archive file.


The version displayed is a combination of the Current-Version and Drop-Number properties.

I think that covers the majority of product components and if you find that a version is not updated in workspace when a patch has been applied then it could be down to the file that contains the versions is not part of the patch or the file has not been updated.

At least you should be able to trace it back to the source and impress others, just remember where you heard it from :)