Microsoft Power BI

Management loves it, I love developing with it but getting certain others to adopt it can be a bit of a challenge.

1. Dax query is highly reliable when comes to slice and dice the granular level data based on time trend.
2. Embedded report and dashboard in any kind of business applications easily and it becomes part of it.

In light of the hype around this "Tableau destroyer" in recent months, I want to highlight some fundamental flaws in data connectivity and reports maintenance of Power BI, which the Product Team so far has turned down as "not in scope". In practice, though, this renders Power BI pretty useless for getting dara from any 3rd party products, in the cloud in particular.

This review reflects Power BI as of mid March 2017. I have gathered my knowledge from testing, community interaction and a dozen tickets with Power BI Pro Support. The focus lies on getting data via Web Services, much aligned with Microsoft’s «Cloud First» Strategy.

1) Power BI Online is in the cloud, but does not allow for HTTP calls. Power BI Desktop allows for HTTP calls, but only with static authentication parameters.
First of all, a distinction needs to be made between Power BI Online and Power BI Desktop. While Power BI Online is the "master" that ultimately allows you to share and publish your reports, user experience in design is diminished by HTML limitations (you may know from Word or Excel Online) and more importantly, data connectivity (Get Data) is limited to SQL Servers on Azure and about 20 to 30 plugins from 3rd party solutions at present. Take note that on Power BI Online, you cannot select or manage your Gateways, either.

This brings the attention to the Power BI Desktop client. Updated every one to two months, the Desktop client brings data connectors necessary to connect to a larger number of data sources.
With the Web connector, HTTP calls been configured, although with just static headers and parameters and Basic and Windows authentication only. Importantly, though, Power BI Desktop includes Microsoft Power Query, which you may know from Excel 2016 already. With M Scripts, you can script and customise in many ways and most interestingly, convert it into table form quickly. This is where Power Query shines. However, Power Query does not seem to call on methods for nonces and timestamps required in token based authentication (OAuth for example). (Should this be incorrect, please please let me know. I have been browsing the fora and nagging Support too long already.)
What’s really amusing here is that Microsoft Azure uses OAuth 2.0 themselves. So, you cannot run any reporting on Microsoft’s Azure AD or Resource Manager database for example, a notorious blackbox. Back to Powershell. (Power BI does not accept Powershell feeds.)
In short, while Power BI Online does not allow to get any data out of the web (except for those 20 to 30 plugins, mostly Microsoft Products), Power BI Desktop allows for Web calls, but only with static parameters and thus, basically with your user credentials.
That’s a big limitation in Data Connectivity.

2) With Power BI Online being the master, the HTTP calls cannot be scheduled or refreshed in the cloud.

Now that you have configured your HTTP call (with risky user credentials), you want to publish your report and have it refreshed on a scheduled basis, say every day.
Tough luck.
While you can publish your Report to Power BI Online and subsequently a broader audience, it’s a static image of your Desktop data. You cannot schedule a data refresh in Power BI Online (because there is no Web feature anyway) and you cannot even refresh the data manually as this requires republishing the Report anew.
You risk your management looking at outdated data whenever you forgot to republish your report and sneak the new URL into your dashboards and iframes.

3) The On-Premises Data Gateway is pretty useless for Web Services.
Yes, there is the On-Premises Data Gateway. Yes, you can configure Web Services in the gateway, although it’s pretty ironic to route web calls via on-premises infrastructure.
But did you ever try it? That is, you cannot specify any HTTP headers fort he calls at all, lest writing a Power Query script. And thus, we are back at authentication via Basic and Windows only and writing REST scripts in the data source for every single HTTP call because with no Headers and Body, all parameters need to be coded in the URI.
Will you do that?

At the end of the day, Power BI is Microsoft's long overdue acknowledgement that Excel and some Dynamics Reports do not cut it for Reporting purposes. Indeed, for reporting on SQL Server, Dynamics 365 (if you want to afford it), and Excel and Access databases stored in your OneDrive, Microsoft Power BI does a neat job.

However, as soon as you want to integrate with 3rd party systems or via web services in particular, Power BI presents so many limitations in authentication, Header and Body configuration, scripting, and scheduling that you need to configure an entire SQL Server environment (on Azure or On-Premises via feature poor Gateway) and write a SQL CRL interface or buy Azure Data Factory to get that data in.

For some pretty reports, do you really want to buy and customise all that BI infrastructure on Azure?

My advice to Microsoft: Work on Data Connectivity, especially in Power BI Online, rather than more visuals for those limited data sources. Your Microsoft clients will consider Power BI a given for the utter lack of reporting in Office 365, Azure, or Dynamics 365 (yes, pushing it there).
My advice to Users: If the connectors are not listed, look somewhere else. (And make sure it’s your use case that is listed. Power BI announced an Azure AD connector, but rather than reporting on Users, Groups, or Enterprise Apps, you can only see on a nice map where the last logins happened.)

Is it a Tableau destroyer? No. It’s a long overdue acknowledgement for necessary reporting with the potential of being a solid Business Intelligence solution ONCE focus comes to lie more on data.

If you can overcome a steep learning curve you’ll be presented with a sw package which allows you to not only analyze your data but drill down to it. You’ll be able to identify root cause for your actual results. The capability of “digging” through your data to get where you want going from an overall picture to a particular one has no prize. If you are analyzing you can create a report the way you want, and if you are presenting to a boss then he/she will be happy to know he/she can get to the bottom line.