Microsoft’s Power BI is a powerful and popular self-service BI application. It allows reports to be developed at an incredible pace without compromising visualization flexibility or design, in addition to being many times more affordable than traditional Enterprise BI applications.
However, as great as Power BI is, it suffers from some of the same problems that all self-service BI applications do. Chief among them is the accuracy and security of the reporting data. Lucky for us, we still use our Enterprise BI application, which guarantees accuracy and security through a governed data warehouse. Leveraging our Enterprise BI application as a data source, while developing reports with Power BI, we can create a secure, accurate, and reliable workflow.
We’re not out of the woods yet, though. Let’s dig into some examples of how these aspects may become compromised by looking at some common workflows when using Power BI with an Enterprise BI application. For our purposes, we’re going to be using Oracle BI (OAC and OBIEE) as our Enterprise BI application.
Standard Integration Methods
The easiest method is to export an Oracle BI report to either an Excel or CSV file. In fact, most Oracle BI users already do this on a daily basis, so it’s an obvious and convenient method.
Exporting an Oracle BI Dashboard to Excel
Excel and CSV files can be imported into Power BI with no issue, making this option typically the primary choice. What if we’re looking for something with less manual labor?
The other approach we will consider is using Oracle BI as an ODBC connection. This approach is straightforward save for two exceptions: initial configuration (which we will cover later) and building queries. This approach requires the end user to be aware of and know, at a functional level, Oracle’s Logical SQL (LSQL). While some users may have knowledge of LSQL, we’re now adding Oracle BI requirements to the position of a Power BI report developer. That being said, at a functional level, this approach works.
Shortcomings of These Methods
The approaches above are relatively simple, but they do have some drawbacks.
Excel or CSV exports are static in nature and can’t be updated automatically once exported from Oracle BI. This requires a new export to be periodically performed to ensure the data is up to date. It never looks good when a decision-maker asks why the numbers don’t match.
The last thing you want to see as a decision-maker.
A simple workaround for this is to use Oracle BI Agents, but a more sinister problem is exposed with these static data exports: data security.
Once a set of data is exported from Oracle BI, it no longer restricts the data based on any security rules. If your developers aren’t careful, sensitive data may become exposed to other parties. While not usually a showstopper, the disrespect of security is dangerous and must be approached seriously.
However, ODBC techniques do not suffer from the same shortcomings with data accuracy and security. Instead, they suffer from implementation complexity.
As said previously, end users are now expected to have an operational understanding of LSQL. While not a major downside, it can be inconvenient for developers. The more prominent issue is with configuring Power BI to utilize the ODBC connection Oracle BI exposes. There are several approaches to implement this functionality, all of which are outside the scope of this article.
That being said, none of the approaches are as simple as “build an ODBC connection string.” Most revolve around either modifying the RPD, re-distributing the DLL’s including in the Administration Tool, or putting the Oracle BI Server behind a custom interface. Suffice to say, we may want something more straightforward to set up and use.
Now that we’ve gone through some of the standard approaches, let’s think about what the perfect solution requires:
- The approach should require no additional modifications to the Oracle BI environment.
- The data should respect the security model and pull up-to-date data directly from Oracle BI.
- Power BI user workflows should not be majorly altered or inhibited by the solution.
Unify BI for Power BI hits all of the above marks and is the best method for using Oracle BI data in Power BI.
Using UnifyBI for Power BI
Let’s take a quick walkthrough of using UnifyBI for Power BI:
- First, we connect to UnifyBI in our browser and authenticate using our Oracle BI credentials.
- Once authenticated, we build the Oracle BI query using the UnifyBI workspace. This workspace allows the developer to use all Oracle BI functionality in a simple to use interface.
- Once the Oracle BI query is complete, we save the query by clicking the export button.
- Now, in Power BI, we use the UnifyBI connector to get the data.
- We supply our Oracle BI credentials once again, and also select the saved Unify BI query.
- The query is then executed using our authenticated user and returns the data to Power BI.
Compared to the other approaches, that was simple! We don’t have to make any sacrifices for our developers – the familiar Oracle BI functionality and familiarity is available without impeding their workflow.
UnifyBI for Power BI grants report developers the accuracy, security, and flexibility needed to perform their jobs quickly. With minimal setup and configuration, UnifyBI enables your organization to realize the greatest return of both your self-service BI and enterprise BI software solutions.
