By Andreea Vaduva on Jan 29, 2013
Defining security in multidimensional databases like Essbase is a subject that some administrators would rather prefer to get around. Anyway it’s no rocket science and follows a clear logic, how read, write or no access should be applied to applications, databases or numbers in the database, by using filters, in order to achieve the respective settings for making data available to users – or even not available. But there is another, fourth setting available in Essbase filters, which some administrators are not yet aware of, or at least not aware of how to apply it correctly: the so called Metaread access setting. So let’s have a look at this very useful option and shed some light on its efficient use.
Not only giving or denying access to the data and figures in an Essbase database is frequently required, but also in some cases blocking the user’s ability to see members and hierarchy, in other words parts of the metadata. This is what the Metaread filter addresses. But Metaread in various ways is different from the other three filter options, None, Read and Write. First of all, as it does not apply to the data/numbers in the database like all the others, but to metadata, where it limits visibility of members and parts of the hierarchy. Also it doesn’t know an AND logic, but only OR. And finally it overrides definitions made with Read or Write in the way, that even granted Read or Write data access on given members or member combinations cannot be executed, when Metaread definitions exclude these members from being seen at all by the user.
So how does it work in detail: Usually users can display all metadata, meaning they can see all members in the hierarchy, even if no Read or Write data access is given to them on these members. Metaread now adds another layer to existing filter definitions and enforces them by removing certain members or branches from the user’s view. It only allows users to see the explicitly defined members and their ancestors in the hierarchy, where for the ancestors only the hierarchy/member names are visible, while for the declared members always at least read access for the respective data is granted. In the case that data Write access would be given at the same time for the members defined in Metaread, this access would be maintained as Write and not reduced to read-only. Siblings of the defined Metaread members are not visible at all. This is illustrated in the example below.
For all other cells not being specified in the Metaread filter, unless not defined differently in another filter, the minimum database access applies, first the one defined at the user access level, or with second priority the setting from the global database access level, like this would be also the case with the common filter definitions.
Of course, also for Metaread, overlapping definitions might occur, but here we have to watch out as they are again treated in a different way, like the following example referring to the hierarchy seen above shows:
This definition, unlike for None, Read or Write, would not grant data access to California and West. Instead it would allow data access only to California, but not to its parent West, for which only the hierarchy would be shown. In order to avoid these conflicting settings for Metaread, it is recommended to define all members from the same dimension in one single filter row, hence the correct way to define data access on both members would be:
So as you can see, Metaread is a bit special, but not that complicated to use. And it adds another helpful option to the common None, Read and Write settings in Essbase security filters.
Want to learn more?
If you are also interested in other new features and smart enhancements in Essbase or Hyperion Planning stay tuned for coming articles or check our training courses and web presentations.
You can find general information about offerings for the Essbase and Planning curriculum or other Oracle-Hyperion products here (please make sure to select your country/region at the top of this page) or in the OU Learning paths section , where Planning, Essbase and other Hyperion products can be found under the Fusion Middleware heading (again, please select the right country/region.
Please drop me a note directly if you have any questions: email@example.com .
About the Author:
Bernhard Kinkel started working for Hyperion Solutions as a Presales Consultant and Consultant in 1998 and moved to Hyperion Education Services in 1999. He joined Oracle University in 2007 where he is a Principal Education Consultant. Based on these many years of working with Hyperion products he has detailed product knowledge across several versions. He delivers both classroom and live virtual courses. His areas of expertise are Oracle/Hyperion Essbase, Oracle Hyperion Planning and Hyperion Web Analysis.