Forward-thinking companies are integrating OBIEE with Essbase to capitalize on the game-changing benefits of providing a continuous view of their data. If you are one of these organizations taking the leap from siloed data to integrated, read on about some of the most commonly asked questions when utilizing OBIEE integrated with Essbase.
Question: Can we create standard “measures” so we don’t have to set them up in each dashboard? For example, current year volume, prior year volume, current year VI, prior year VI, etc. or do we create a template with them all in as our starting point for creating new dashboards?
Answer: Yes, this can be done using time series functions: Ago, ToDate, and Rolling. Details on time series functions are available in online help. You can use the function in a column formula while you are building your report. Assuming your accounts dimension is flatted, another way is to add the YAGO measure in the OBI repository then move it into the subject area (this approach is more user friendly).
Question: In the modeling process can we say for this dimension do not bring it over to OBIEE and always default it to ‘X’?
Answer: Yes. Add a filter clause to the properties (OBI repository) for either the dimension or fact logical table. If you add it to the dimension only, it will apply only to reports that use that dimension in its analysis. Furthermore, if you add it to the fact table it will apply to reports that use that fact in its analysis. You can also add it to both.
Question: What happens if we bring in a dimension “flat” and add members? Do we have to rebuild?
Answer: It does not require a rebuild, but it does require a configuration change to the OBI repository to add the new account members to the subject area (ez process). Note: rebuilds are the last resort. Minor outline changes can be managed with simple configuration changes to the OBI repository.
Question: What are the issues with only bringing over certain members in a dimension?Answer: The rule of thumb is to bring everything over into OBI, but in the Subject area you should expose only the measures needed for your reporting requirements. As we flatten the Accounts dimension it creates hundreds of measures, many of which are not be relevant. Also, you may want to add additional derived measures such as “Year Ago Variable Income.”
Question: What if we only want certain dimensions flattened and others left hierarchical? Is that an issue? How much effort is it to have the accounts both flattened and hierarchical, and what are the pros and cons of each?
Answer: No, it’s not an issue, it can be done. The main difference lies in how you want to arrange and present the measures in your analysis. Keep in mind that all other OBIEE subject areas (e.g. GlobalSIS, Procurement, etc) have flattened measures, and so having flattened Essbase measures (e.g. “Revenue”, “Gross Profit, etc.) will be more familiar to non-Essbase users. Flattened measures are required if you wish to have OBIEE derive new calculations or if you want to federate Essbase with other data sources (i.e. use both essbase and ebs data on one report). On the other hand, users familiar with both OBIEE and Essbase will be more used to having the Accounts dimension and may prefer using it.
Question: We wish to federate two Essbase applications together. Customer dimension members do not conform: they are not at the same level with each other. How do we account for this when we wish to include all customer groups?
Answer: This is best done in Essbase, not OBIEE. In Essbase, create a transparent partitioned ASO reporting cube. You can partition both cubes together in the OBI repository, but it can be a complex and challenging task.