Kscope wouldn’t be the same without checking out Jake – one of the best. The amount of time and effort he puts into his presentations is crazy and it shows. If you want to learn something new, below is schedule. If you get a picture of him in his formal wear (you will know what […]
For most Essbase applications, user and group security will be a necessity. Here are the steps to set up individual filters and then apply them to a group in Shared Services.
One of the problems with giving users of Hyperion Planning the ability to run calculations is opening up the possibility for all of them to run the same calculation at the same time.
Having been working on an ASO project for the last couple of months, I have learned a lot about Essbase and its related software. One of the things that gave me trouble at first was the syntax of CrossJoin in ASO’s MDX language. More specifically, I was having trouble trying to nest multiple CrossJoin’s together when I was trying to clear out a certain portion of data that included more than two dimensions. A CrossJoin is simple; it returns the cross-product of two sets from two different dimensions. But what if I want to return the cross product of four different dimensions? That one proved to be a little trickier
Creating security filters and assigning them to different users/groups can be a time consuming process, especially if it is done manually. Luckily, there are some simple MaxL statements that can be used to significantly expedite the process. Here are the 3 that I’ve found to be most useful:
- Create Filter
- Alter Filter
- Grant Filter
By default, only data values can be loaded into Essbase. However, sometimes it is helpful to load dates into an application (i.e. Product Inception Date). Follow these steps to enable an Essbase application to accept dates as data.
What is a Smart List?
- Allows for creation of custom lists that can be used in data forms
- Goes beyond the limitations of Essbase: these lists are not limited to numbers only
- Users select a member from a designated list (each Smart List cell has a dropdown arrow that expands to allow member selection in web forms)
In Hyperion 188.8.131.52, there is a change in how security is deployed. If you are having an issue deploying Planning security with Essbase adhoc access, and the user can’t
- Access Essbase Adhoc
- Access FR reports using an Essbase connection
- Access Essbase directly
you are not alone.
The generic rule in Essbase is that calculations FIX on sparse members because sparse members are what define the number of blocks. When you want to limit the members of the block on which the calculation is executed, an IF statement is appropriate.
How many times have you been in a situation where you have to traverse through hundreds of lines and errors from an Essbase data load only to figure out that all the rejected records are caused by an issue with one member? You load the file again and wham – another error file with issues you didn’t see the first time.
Although this is typically less of an issue in a production environment, these situations are very likely in the development and testing phases of a project.
In2Hyperion is introducing another free tool that will navigate through errors and summarize the reasons for the rejects.
The introduction of Hyperion 11.1.2 has some fantastic improvements. Many of these have been long awaited. The next few articles on In2Hyperion will describe some of the enhancements to Hyperion Planning, Hyperion Essbase, and Hyperion SmartView.
If you have been developing Planning applications, you are probably very familiar with the XREF function. This function is used in business rules, calculation scripts, and member formulas. It provides a method to move data from one plan type (Essbase database) to another plan type. It is executed from the target database and pulls the data from the source. XWRITE was actually introduced in later versions of 11.1.1.x, but is very stable in 11.1.2.x. XWRITE is executed from the source and pushes data to the target. This function is a huge improvement over XREF.
Although implied shares can improve performance by not storing the same data multiple times, it has many negative impacts. For example, implied shares cause problems in Hyperion Planning at the load level (level 0). A parent with a storage property of Stored that has one child (or only one child that consolidates) will create an implied share. This results in level 0 members being locked, preventing web form data entry. In Essbase/Planning, the storage method of any parent with one child has to be changed to Never Share to allow user input.
For those of you who have been snake bitten by this, you will welcome a relatively unknown Essbase configuration setting in the Essbase configuration file (essbase.cfg).