Tag Archives: Obiee
New Knowledge Articles: Support of BIApps with OBIEE 12c
|
|||
|
|||
|
These articles provide information for those that are planning to use OBIA 7.9.6.4 or OBIA 11.1.1.9.2 /11.1.1.10.1 with Oracle Business Intelligence Enterprise Edition (OBIEE) 12.2.1.0. The notes discuss how to perform the 'Out of Place Upgrade' of OBIEE to ensure compatibility. To assist in locating these article for future updates, they can be easily bookmarked.
Once bookmarked the star will become yellow, and article quickly accessed from the "Favorites" drop down menu. A listing of Information Centers and Upgrade Advisors for Business Intelligence (BI) and Enterprise Performance Management (EPM) can be found in the index page: Information Center: Business Analytics Index (EPM/BI)
|
|||
|
|
|||
Action Links in OBIEE 12c – Part 2
Introduction and Scenario
Part 1 of this series on Action Links had us creating a simple navigate action and left us in suspense with the promise of a new means by which to filter one report from another. Now time to deliver! The scenario: say we’ve got a company dashboard that is pretty locked down in terms of adding any new user-facing content, and as a developer you occupy more of an analyst role where you can build analyses all day, but dashboards are a no go. So how then can we drive some of our own detail analyses from dashboard selections? The answer? Hidden driving documents! In a nutshell, these documents store selected dashboad values and act as a filter for our detail analyses, utilizing OBIEE’s “filter on the results of another analysis” filter option. It should be noted that we could simply set the target analysis’s filters to be equal to the presentation variables generated by the source dashboard prompt. However, the following technique is simply to illustrate a possible technique, say when you’re going between two different subject areas, that might be applicable in your current situation or at least spark an idea to get you headed in the right direction towards a possible solution. So, let’s start by getting the pieces to our puzzle together.
Start with the dashboard and prompt. We are going to navigate from a monthly sales trend to a detail report displaying product sales detail.
The Solution
Now that we’ve determined the dashboard analysis from which we want to navigate, we can set up our driving document. Again, the overall concept of a driving document is to act as an intermediary container for selected values that then get passed from one report to another. So let’s set this up. Given that our trend is prompted on Year, Company, Region, we need to place three dummy columns on our driving report to store the presentation variables generated by each prompt. I used the same three columns in my driving report for consistency, however any column will do. Note that the columns in the picture have custom names already are not the native columns from their respective tables.
Edit each column to store the presentation variables generated by your dashboard prompt. If the dashboard prompt does not have a presentation variable for each column prompt, go ahead and get those set up before completing this step. My year column variable in this example is appropriately titled SALES_YEAR. Be sure to put single quotes around your variable as in ‘@{SALES_YEAR}’ when entering it in the Edit Column dialogue.
You can now save your driving report and place it on your dashboard. Right away you should see that your driving report picks up the values in each column prompt. Note the use of a default value {2012}. Using these is ideal so that if we want to edit our driving document, we at least have some values to pass it, as opposed to it throwing an error on the Results tab.
Now for some bad news. You might have noticed an obvious limitation to this approach, which is the driving report’s limited selection of only one column value from each column prompt. Nevertheless, let’s run this thing through to the end and see what happens. The next piece of the puzzle is setting up your target analysis.
Our analyst in this scenario wants to set up two reports to be driven off of our dashboard selection. The first will be a top 10 report for products based on the selected month. The second will be another top 10, but for sales reps instead. Navigating to our desired subject area, let’s bring over the needed columns, formatting as needed. In this example, we’re going to include a custom calc which gives us the percent variance to the prior period which has also been conditionally formatted to indicate positive or negative growth.
We have placed the columns necessary to build each report and also added filters, as seen in the proceeding picture.
Now comes the crux of this neat trick. We need to add the proper filters to the analysis so that any values we pick from both the dashboard prompt and the source analysis itself will drive our target analysis.
In the target report, we added a filter for each column that we’d like our analysis filtered on and likewise, comes from our source report.
To set this filter, simply apply the ‘is based on results of another analysis’ filter to each column. Then, browse for the driving report we made and apply the ‘is equal to any’ Relationship option. As our driving report values will only have one value for each of the filtered columns, our target report columns should filter on each of these. Lastly, use the drop down to choose the corresponding column from the source analysis. In the following pic we are selecting the Region column from our driving report so that our target report will be filtered on whatever Region is selected on our source dashboard.
As the last steps in our target analysis, make sure you’ve set all the filter columns to respond to the driver analysis and that you select the ‘is prompted’ filter for any additional dimension columns on your report that are not driven by a dashboard prompt. In the example, this is going to be the Month column. This will ensure that our target analysis “listens” to whatever month is selected in our source analysis, that is, our sales trend.
Don’t worry if your Results tab shows no values as this is expected behavior (we haven’t sent any values over yet!). If you’d like to set it up so that your target report actually yields results without clicking on the action link, simply apply default values to the presentation variables in your driving document, as described above in the Year example. The last piece of this puzzle is finally assigning the action link to our respective column. Follow the instructions outlined in the first part of this post in order to navigate to our target analysis. In our example, this is going to be our Sales column.
Now that we’ve got all the pieces of the puzzle, let’s put it all together and see what happens. Clicking on any sales point on our trend line, we should be taken to the target analysis which should be filtered on both our dashboard prompt values as well as our Month. In this example, I’ve applied a filters object to the target analysis to make sure the target analysis responded to all applied filters.
Looks like everything works great! At this point you can hide the driver report on your dashboard and get rid of the filters object on your target analysis. I’d like to hear about some neat ways people have used this technique or modified it to suit their particular business/use case. Feel free to post in the comments! Stay tuned for part three of this series on Action Links where we go in depth about the GoURL syntax and how it can be a powerful and customizable tool in navigating to web pages and OBIEE 12c content.
The post Action Links in OBIEE 12c – Part 2 appeared first on Rittman Mead Consulting.
Becky’s BI Apps Corner: Oracle BI Applications, where art thou?
Hello! I would like to take a moment to introduce myself. My name is Becky Wagner and I’ve been working with Rittman Mead America since the beginning of the year. I have a background in data warehousing and ETL with a state government agency, where I was part of a project upgrading from DataStage to ODI 11g with Oracle Golden Gate in Oracle’s early adopter program for Oracle BI Apps 11g. Since coming to Rittman Mead, I’ve taught several ODI 12c bootcamps, designed and delivered custom trainings for BI Apps and ODI and been involved in ODI 11g, ODI 12c projects, and OBIA 11g projects.
Recently, I was putting together a BI Apps for Oracle Data Integrator (ODI) custom training for a client who is upgrading BI Apps and will be using ODI for the first time. On the Virtual Machine I was building for the training, I wanted the version of Oracle BI Applications to match the client’s installation. I found that Oracle’s recent website facelifts changed the way I was used to getting older versions of software. Oracle’s Downloads and Technetwork sites both have the most recent version of Oracle BI Apps available (currently 11.1.1.10.1) but no earlier versions any longer. Edelivery has the earlier versions as well as the current version, but the site has changed enough that it took me a bit to understand how to get to the Oracle BI Apps software files to download.
Downloading Oracle BI Apps from Edelivery
From your favorite browser, go to https://edelivery.oracle.com and sign in.
Accept the Export Restrictions (of course, only after you have read, understand and agree to them.)
Fill in the Product* box with ‘Business Intelligence Applications’. You won’t see Business Intelligence Applications in the dropdown that appears as you start typing. What you do see are other Products that your company would have purchased to allow you to have a license of Oracle Business Intelligence Applications, such as Oracle Financial Analytics or Oracle Human Resources Analytics. Select the product (or one of the products) that was purchased by your company.
Click on the Select Platform button and check the box for your appropriate platform, such as Linux x86-64 or Microsoft Windows x64 (64-bit). Then click the Select button.
Once the Product you selected is displaying in the window, click on the Continue button.
Now Oracle Business Intelligence 11.1.1.10.1 is showing. Interestingly, it doesn’t say Oracle Business Intelligence Applications, but currently OBIEE doesn’t have a version of 11.1.1.10.1, so we can be confident this is actually Oracle BI Apps. However, this still isn’t the Oracle BI Apps that you are looking for. Below the Available Release, you will see the option to Select Alternate Release.
This will allow you to drop down the box to select an earlier version.
With any version of Oracle BI Apps, there are several different components to download, which you can see by clicking on the triangle to the left of the Available Release. Once you have selected your desired version of Oracle BI Apps, click on the continue button to begin the download.
Please don’t forget to read the license agreements carefully and if you agree, check the box and click Continue.
At this point, you can now see the files to download. You can click on each blue link individually, or click the Download All button to use Oracle’s downloader tool. Also, for the Linux, Red Hat, and Solaris folks, notice at the bottom the WGET Options.
Downloading ODI for Oracle BI Apps from Edelivery
Get the downloads started for these files. We aren’t quite finished yet, though. ODI needs to be downloaded as well. Return to the Products page. Please note that to get the correct version of ODI, you must type in ‘Oracle Data Integrator for Oracle Business Intelligence’ (again, it probably means Oracle BI Apps, but points here for consistency at least). Select a Platform. Then click Continue.
Notice we are showing Oracle Business Intelligence 11.1.1.10.1 again. You will want to click on Select Alternate Release, and pick the same version you selected above. This will save you from interesting OPatch errors later during the install process, but I will leave those fun errors for another blog post. Then click Continue.
And that is how you navigate the new Oracle EDelivery site to get Oracle BI Apps download files and previous versions. I would love to hear your thoughts if you found this helpful or confusing. Also, please leave comments below if you found other alternatives for downloading earlier versions of Oracle BI Apps, and/or your suggestions for ways to rename the V#####-##.zip files to something more descriptive that better identifies the zip file. Keep an eye out for more Becky’s BI Apps Corner coming soon and if you’re interested in OBIEE or ODI training (or even a custom Oracle BI Applications course), give us a shout at training@rittmanmead.com!
The post Becky’s BI Apps Corner: Oracle BI Applications, where art thou? appeared first on Rittman Mead Consulting.
An Alternative Front-End for OBIEE using Web Services and d3
Working with OBIEE, it is common to get reequests to add visualisations or otherwise improve the UI. Typically this has been done by using narrative views to embed HTML and Javascript to provide data driven, custom visualisations. To cope with the former, Tom Underhill developed the Rittman Mead Visual Plugin Pack (RMVPP), a web based plugin to allow configurable visualisations to work natively in OBIEE through the use of narratives. This technology is uses configurable Javascript templates for each plugin. Each plugin has a render function which will receive the dataset from OBIEE as well as any associated information. The features of the plugin are then only limited by the ability of the JS developer and current web standards. Plugin developers could be further aided by sharing common functions for display and data manipulation, and external libraries can be included simply.
Above shows the process of creating a Sankey diagram using the RMVPP framework. The code then produces the corresponding narrative required to generate this visualisation automatically.
When RMVPP was being developed by Tom, I was investigating the use of web services in OBIEE. Several of us at Rittman Mead had used the exposed web services to interface with OBIEE to automate various tasks programmatically, such as regression testing and web catalogue auditing. A client had a requirement to execute an OBIEE query on a webpage outside of the OBIEE front end in order to power a fairly sophisticated 3JS application that was not rendering within OBIEE (via a narrative). It appeared that the shortcomings were due to attempting to render the WebGL within the complex div and table structure of an OBIEE page. Soon, I was able to use the web services client side, in Javascript (so long as the page was hosted on the same server as OBIEE) as opposed to server side in Python or similar. Combining this breakthrough with Tom’s RMVPP framework seemed like the next logical step – as it would allow us to totally modify the OBIEE front end whilst retaining the benefits of using the BI Server like security and physical query generation.
An Alternative Front-end for OBIEE
The following section will describe and show some of the features I have developed in my alternative to the OBIEE front end. It uses the plugin framework from RMVPP but with a custom interface that works differently to OBIEE.
Creating a Visualisation
Below is a screencapture showing creation of a basic bar chart.
The column mapping tab is configurable by the plugin developer and specifies the parameters that each visualisation will use. As a user, OBIEE presentation columns (displayed on the left) are mapped into these parameters. A flag can be set on a parameter to allow multiple columns to be chosen for that parameter. The plugin developer can then use the resulting data set accordingly. The columns selected here are effectively the Criteria from vanilla OBIEE as they determine which columns are used in the logical SQL. The parameter mapping allow the developer to use the correct columns from the data set in the render function.
The configuration screen shown there is customisable by the plugin designer, allowing developers to specify a list of options and UI elements that get fed back into the render function for the visualisation. UI options include:
- Textboxes
- Dropdowns
- Radio Buttons
- Colour Pickers
Filtering
The next screen capture shows a Sankey chart and applies a filter to the query. The filter mechanism also has an sub search facility similar to vanilla OBIEE.
Conditional Formatting
The next example shows a pivot table being created and the conditional formatting functionality available.
The conditional format tab allows you to choose the columns to apply formatting to as well as the formatting rule that should be applied. Additionally, a plugin developer can specify custom conditional formats to be available for specific plugins. The heatmap formatting style is one such example for the pivot table.
Adding and Editing Columns
Similar to vanilla OBIEE, columns formats and formulae can be edited and added for visualisations.
Saving/Loading
Visualisations (and dashboard pages) can be saved and loaded to and from the web catalogue. This means that security can be applied to them in the normal way.
They are saved to OBIEE as analyses with Static Text views in them containing the necessary information to build the visualisation with my API. OBIEE however, will not be able to render these properly and I’ve stopped developing that functionality for a number of reasons I won’t go into in this post. The screencapture shows a brief glimpse of the webcat explorer in my app, which is basic, but filters out any vanilla OBIEE objects, only allowing you to view and open custom objects that were created by the app.
Dashboards
The interface allows the user to create dashboards from the same app, without having to save individual visualisations first.
After creating and configuring a visualisation, they can be temporarily stored. Once stored, the user can switch to dashboard mode, which will have a blank canvas, allowing the user to add any stored visaulisations. The edit button in dashboard mode will allow visualisations to be freely placed on the canvas.
Interactions
The interactivity framework is probably the feature with the biggest benefit over the vanilla system that I’ve added.
Plugin developers are able to create triggers as part of their visualisations. These triggers can be fired in most situations and tied to the data so that dynamic interactions between visualisations are possible. Users can specify what data should be passed to the target reaction. By default, every plugin can be hard filtered by an interaction, which modifies the query and goes back to the BI server. Plugin developers can also write their own reactions, allowing for interactivity only limited by the plugin designer’s web development capability.
Drilldowns
Drilldowns between custom dashboard pages can be defined using the same framework as the other interactions.
Users need only enter the webcat path for the target page in order for the drilldown to function. Each visualisation of the target dashboard will be automatically filtered (if the subject area matches) on the criteria specified by the interaction.
Dashboard Prompts
Some of the vanilla features in OBIEE are very useful, so I replicated the functionality in my app.
This shows the implementation of prompts to a dashboard page. Unlike OBIEE, it is not required to set an ‘is prompted’ filter on each target. Rather, the prompt will automatically filter any visualisations on the page that are from the same subject area.
Column Selectors
Column selectors can be added as either dropdowns or radio buttons.
The user chooses an array of columns to be in the column selector. If any visualisations in the dashboard contain a column in this array, it will be swapped when the column selector is updated.
Map Visualisations
Two of the visualisation plugins I have made are map based, for geographical data.
Both use LeafletJS, an open source Javascript mapping library. The first, is a bubble chart which relies on longitude and latitude being stored in the database and exposed via OBIEE. The second is a choropleth which requires a TopoJSON file of the regions in order to function. Additionally, the json file needs to have an attribute attached to each region which will act as a key to join it onto OBIEE data. So that region attribute needs to have a matching key exposed via OBIEE.
Summary
So that wraps up the major features of the app. I don’t know if it’s going to be useful, if there’s any mileage in further development or any of that, but was an interesting PoC while it lasted. If anyone has any comments, ideas, features or just want to know more about the app and how it works, feel free to comment.
The post An Alternative Front-End for OBIEE using Web Services and d3 appeared first on Rittman Mead Consulting.
Driving OBIEE User Engagement with Enhanced Usage Tracking for OBIEE
Measuring and monitoring user interactions and behaviour with OBIEE is a key part of Rittman Mead’s User Engagement Service. By understanding and proving how users are engaging the system we can improve the experience for the user, driving up usage and ensuring maximum value for your OBIEE investment. To date, we have had the excellent option of Usage Tracking for finding out about system usage, but this only captures actual dashboard and analysis executions. What I am going to discuss in this article is taking Usage Tracking a step further, and capturing and analysing every click that that the user makes. Every login, every search, every report build action. This can be logged to a database such as Oracle, and gives us Enhanced Usage Tracking!
Why?
Because the more we understand about our user base, the more we can do for them in terms of improved content and accessibility, and the more we can do for us, the OBIEE dev/sysadmin, in terms of easier maintenance and better knowledge of the platform for which we are developing.
Here is a handful of questions that this data can answer – I’m sure once you see the potential of the data you will be able to think of plenty more…
How many users are accessing OBIEE through a mobile device?
Maybe you’re about to implement a mobile strategy, perhaps deploying MAD or rolling out BI Mobile HD. Wouldn’t it be great if you could quantify its uptake, and not only that but the impact that the provision of mobile makes on the general user engagement levels of your OBIEE user base?
Perhaps you think your users might benefit from a dedicated Mobile OBIEE strategy, but to back up your business case for the investment in mobile licences or time to optimise content for mobile consumption you want to show how many users are currently accessing full OBIEE through a web browser on their mobile device. And not only ‘a mobile device’, but which one, which browser, and which OS. Enhanced Usage Tracking data can provide all this, and more.
Which dashboards get exported to Excel the most frequently?
The risks that Excel-marts present are commonly discussed, and broader solutions such as data-mashup capabilities within OBIEE itself exist – but how do you identify which dashboards are frequently exported from OBIEE to Excel, and by whom? We’ve all probably got a gut-instinct, or indirect evidence, of when this happens – but now we can know for sure. Whilst Usage Tracking alone will tell us when a dashboard is run, only Enhanced Usage Tracking can show what the user then did with the results:
What do we do with this information? It Depends, of course. In some cases exporting data to Excel is a – potentially undesirable but pragmatic – way of getting certain analysis done, and to try to prevent it unnecessarily petulant and counterproductive. In many other cases though, people use it simply as a way of doing something that could be done in OBIEE but they lack the awareness or training in order to do it. The point is that by quantifying and identifying when it occurs you can start an informed discussion with your user base, from which both sides of the discussion benefit.
Precise Tracking of Dashboard Usage
Usage Tracking is great, but it has limitations. One example of this is where a user visits a dashboard page more than once in the same session, meaning that it may be served from the Presentation Services cache, and if that happens, the additional visit won’t be recorded in Usage Tracking. By using click data we can actually track every single visit to a dashboard.
In this example here we can see a user visiting two dashboard pages, and then going back to the first one – which is captured by the Enhanced Usage Tracking, but not the standard one, which only captures the first two dashboard visits:
This kind of thing can matter, both from an audit point of view, but also a more advanced use, where we can examine user behaviour in repeated visits to a dashboard. For example, does it highlight that a dashboard design is not optimal and the user is having to switch between multiple tabs to build up a complete picture of the data that they are analysing?
Predictive Modelling to Identify Users at Risk of ‘Churn’
Churn is when users disengage from a system, when they stop coming back. Being able to identify those at risk of doing this before they do it can be hugely valuable, because it gives you opportunity to prevent it. By analysing the patterns of system usage in OBIEE and looking at users who have stopped using OBIEE (i.e. churned) we can then build a predictive model to identify those with similar patterns of usage but are still active.
Measures such as the length of time it takes to run the first dashboard after login, or how many dashboards are run, or how long it takes to find data when building an analysis, can all be useful factors to include in the model.
Are any of my users still accessing OBIEE through IE6?
A trend that I’ve seen in the years working with OBIEE is that organisations are [finally] moving to a more tolerant view on web browsers other than IE. I suppose this is as the web application world evolves and IE becomes more standards compliant and/or web application functionality forces organisations to adopt browsers that provide the latest capabilities. OBIEE too, is a lot better nowadays at not throwing its toys out of the pram when run on a browser that happens to have been written within the past decade.
What’s my little tirade got to do with enhanced usage tracking? Because as those responsible for the development and support of OBIEE in an organisation we need to have a clear picture of the user base that we’re supporting. Sure, corporate ‘standard’ is IE9, but we all know that Jim in design runs one of those funny Mac things with Safari, Fred in accounts insists on Firefox, Bob in IT prides himself on running Konquerer, and it would be a cold day in hell before you prise the MD’s copy of IE5 off his machine. Whether these browsers are “supported” or not is only really a secondary point to whether they’re being used. A lot of the time organisations will take the risk on running unsupported configurations, consciously or in blissful ignorance, and being ‘right’ won’t cut it if your OBIEE patch suddenly breaks everything for them.
Enhanced Usage Tracking gives us the ability to analyse browser usage over time:
as well as the Enhanced Usage Tracking data rendered through OBIEE itself, showing browser usage in total (nb the Log scale):
It’s also easy to report on the Operating System that users have:
Where are my users connecting to OBIEE from?
Whilst a lot of OBIEE deployments are run within the confines of a corporate network, there are those that are public-facing, and for these ones it could be interesting to include location as another dimension by which we analyse the user base and their patterns of usage. Enhanced Usage Tracking includes the capture of a user’s IP, which for public networks we can easily lookup and use the resulting data in our analysis.
Even on a corporate network the user’s IP can be useful, because the corporate network will be divided into subnets and IP ranges, which will usually have geographical association to them – you just might need to code your own lookup in order to translate 192.168.11.5 to “Bob’s dining room”.
Who deleted this report? Who logged in? Who clicked the Do Not Click Button?
The uses for Enhanced Usage Tracking are almost endless. Any user interaction with OBIEE can now be measured and monitored.
A frequent question that I see on the OTN forums is along the lines of “for audit purposes, we need to know who logged in”. Since Usage Tracking alone won’t capture this directly (although the new init block logging in > 11.1.1.9 probably helps indirectly with this) this information usually isn’t available….until now! In this table we see the user, their session ID, and the time at which they logged in:
What about who updated a report last, or deleted it? We can find that out too! This simple example shows some of the operations in the Presentation Catalog recorded as clear as day in Enhanced Usage Tracking:
Want to know more? We’d love to tell you more!
Measuring and monitoring user interactions and behaviour with OBIEE is a key part of Rittman Mead’s User Engagement Service. By understanding and proving how users are engaging the system we can improve the experience for the user, driving up usage and ensuring maximum value for your OBIEE investment.
If you’d like to find out more, including about Enhanced Usage Tracking and getting a free User Engagement Report for your OBIEE system, get in touch now!
The post Driving OBIEE User Engagement with Enhanced Usage Tracking for OBIEE appeared first on Rittman Mead Consulting.
