OBIEE 22.214.171.124 : New Dashboard, Analysis and Reporting Features
So apart from support for a new type of repository storage, and enablement of the Oracle Exalytics In-Memory Machine, OBIEE 126.96.36.199 brought in a number of new features that could be of benefit to end-users and dashboard/report developers. Let’s go through them now, starting with some new capabilities around ad-hoc analyses.
The 11g release of Oracle Business Intelligence brought in the concept of selection steps, something that Venkat covered in detail around the time of the 11g launch. Selection steps allow you to further manipulate the results returned by an analysis, to add, remove or keep certain dimension members, add groups or calculated items, or filter results based on conditions which could make reference to hierarchies. Selection steps are applied post-aggregration, whilst regular filters are applied pre-aggregation, and they preserve totals even if you subsequently add or remove members from the analysis view.
Up until 188.8.131.52, selection steps could only be added within the analysis editor (a.k.a. Answers), and there was no way to display to the end-user what selection steps had been applied, or any way for them to add their own steps. This changes though with 184.108.40.206, and now either the analysis developer, or the end-user, can add selection steps to the analysis by right-clicking on the view. Let’s work through an example.
In this example, we have a simple pivot table that returns sales by product category and a stores hierarchy. We’ve applied a filter to the results so that only certain months are included, and we’ve included the filter view in the compound layout so you can see what’s been applied. Here’s the view as seen in the analysis editor, with the stores hierarchy drilled-down to the regions level:
Now new within this release is the ability to right-click on the pivot table view, in this case, and add selection steps, which includes adding groups and calculated items. What’s in the selection step list depends on whether you’re working with attribute columns or hierarchy columns, with the former having less options.
So let’s add one of the new Selection Steps views into the compound layout, like this:
and then we’ll include the analysis in a dashboard page. Now, even in this “published” form, end-users can take the initial set of results, and as well as move the columns around and sort the results as provided previously, they can add their own selection steps. Let’s start by excluding Other USA from the list of Regions:
Now we’ll create a new group containing all of the SF regions, like this:
Now, I’m going to create a new calculated item that’s made up of Gifts and Snacks, and replace the existing two product category members with this new calculated item.
So now our analysis is starting to look a lot different, with the selection steps we’ve applied shown in the selection steps view under the main pivot table.
Now let’s add a column-level grand total for each region and grouping on the Y axis, to show the total sale amount for each row.
And then finally, exclude those regions that aren’t in the top three overall, based on Sale Amount across all categories.
So once this is all done, the final version of the pivot table as customised by the end-user, looks a lot different to when it was first viewed, and the additional steps that the user has applied are clearly visible under the pivot table view.
Now any changes that the user has made to this view are only visible to him or her, and haven’t changed the underlying definition of the view. But what if that particular user wanted to save these changes somewhere, so that they could see this customised version of the analysis whenever they logged in into their account? To do that, you can save this particular dashboard customisation, by selecting Save Current Customization… from the Edit Page menu in the top right-hand corner of the page, like this:
and then choose whether this customisation is available as an option for other users, and whether it gets applied automatically whenever this particular user accesses this dashboard page again.
From my perspective, for end-users this is the single-most important new feature in OBIEE 220.127.116.11 that I’m aware of, as it gives the end-user so much more power to customise and further manipulate the results of queries that you present to them in dashboards. When I was using 18.104.22.168 to write the Answers and Dashboards chapter of the book, but it wasn’t yet on general availability, going back to the restrictions of 22.214.171.124 on customer sites was a real pain, as I’d got so used to this new flexibility in presenting analyses to dashboard end-users.
That said, you may not want all analyses to be used in this way, so a new tab has been added to the Analysis Properties dialog to allow you to selectively disable these features should you wish.
Another change introduced with 126.96.36.199, but primarily aimed at Exalytics implementations, is the ability to remove the Apply and Reset buttons from prompts. In fact, every optimisation introduced into 188.8.131.52 to do with the dashboard front-end is actually available for all implementations, though you’ll need to consider whether your system is powerful enough to make proper use of them. In the case of removing the Apply and Reset buttons from prompts, you need to be aware that every time you select a value, or move the focus area out of the currently selected value in the prompt, it’ll cause the analysis to refresh and a logical query to be send through to the BI Server, which could get interesting if you’ve got a large data set and a number of users all accessing dashboards at the same time.
So you can disable the Apply and Reset buttons at the individual prompt level, like this:
or at the dashboard page level, like this:
or at the whole dashboard level, using the Dashboard Properties dialog, like this:
Then, assuming you’ve gone ahead and hidden these buttons, prompts will then cause linked analyses and other objects to change their values as soon as you make the selection, giving your users a very interactive and fast dashboard experience, assuming that your underlying database can handle the extra level of activity.
As mentioned earlier, by default dashboard prompts are visible when you install the stock version of OBIEE 184.108.40.206; however, if you’ve bought an Exalytics box, the installation procedure switches all prompts to hide these buttons by default, as the assumption is that you’d want this feature and the underlying database is able to handle the increased load, due to the presence of the TimesTen in-memory cache.
Another set of new features in 220.127.116.11 that this time are for Oracle BI Publisher, are around how you set up new reports and the templates that they use. In previous versions of BI Publisher, you first create a data model and then create a report definition, with the report creation process first prompting you to select a data model from the catalog. Now, when you go to create a new report (New > Report from the common header menu), you’re prompted to either select an existing data model, create a new one, or upload a spreadsheet which creates a corresponding data model for you. Presumably this is because usability reports showed that most people new to OBIEE didn’t realise you had to create a data model before you created a BI Publisher report, and this change makes the process a bit more obvious (plus provides a short-cut to creating reports based off of spreadsheets).
Then, when you actually come to create the report template, you’ve now got the option of going to the regular online layout editor, or you can step through a wizard to help you define the layout template.
This then takes you through a number of steps, where you can select the columns to include, and then further customize the report at the end.
So, a few interesting new front-end features in the 18.104.22.168 of OBIEE, and we’ll conclude this series about this latest release of OBIEE tomorrow with a look at what’s involved in upgrading from earlier releases.