So I'm here at a marketing event today - working the booth.  This time, I have the pleasure of working with a Perceptive Pixel display in my booth.  And Power BI looks pretty darn cool on the PPI device.

No special installation instructions or user training required.  The gestures take just a little bit of getting used you, since you are forced to use your arms.  Heck, we can all use the "exercice", right?

Here's a quick demo of the Power BI/Win8 app + Power Map running on the PPI device.  If you'd like to check out the experience, contact your local Microsoft Technology Center for a guided tour.

https://www.youtube.com/watch?v=5qQUTvMnGZ0

Microsoft quietly released a new version of Power Map for Excel.  It's still in Preview mode, but there were some notable performance and stability changes.  You may also notice some net new functions in the ribbon for Power Map (e.g. 2D Charting options).

If your copy of the add-in still says "GeoFlow", you don't have the latest and greatest.  You can get that here:

http://www.microsoft.com/en-us/download/details.aspx?id=38395

If you already have GeoFlow (the former codename for Power Map), go ahead and uninstall that before you install the new add-in.

I created a quick demo of the latest Power Map functionality - you can check it out here:

https://www.youtube.com/watch?v=l90-g_aUaG4

I use US Census data for this one - The data set is pretty straight-forward - just population statistics.  I don't get into the most of the demographic items - just raw population by county.  You can grab a copy of the data here:

http://www.census.gov/popest/data/counties/asrh/2012/CC-EST2012-ALLDATA.html

I use the CSV file that contains the entire US. 

Here's what I learned along the way:

1) If you want the time-based animation, you must mark some aspect of your PowerPivot model as a Date Table.  Since I don't get one from the Census, I just fabricated something to get the animation working.

2) Power Map doesn't like a plain County Name - how can you tell the difference between Cumberland County in PA, MD, and NJ?  So I load the data via Power Query and fabricate a concatenated column of County + State.  Power Map likes using this flavor of geography much better.

3) When things start to look messy on your map, consider using the "Thickness" control to slim down some of the column chart points.  Usually does the trick for me.

Enjoy!

UPDATE September 30 2013

Here's the "official" list of changes with this iteration of the add-in:

If you are reading this article, I hope you have had a chance to read my first post on the topic.  If you haven't, you can access it here.  It covers Microsoft's white paper on SAP/Microsoft BI interoperability - plus some of my color commentary on the topic.  For the most part, I'd suggest that the options cover Enterprise-style scenarios (requiring bulk data movement, sophisticated modeling, perpetual business needs, etc.)  Even with a well-designed BW InfoCube and a self-service scenario, our current go-to-market strategies suggest the involvement of some intermediary processes (ETL, third-party adapters, etc.) to assist the analyst.

Do you want an easier approach to wiring up Microsoft BI tools (in particular, Power BI) to *any* chunk of data within SAP (from your ECC database to your BW models to RFC calls and beyond)?  Well, I do have another option for you.

Net-net: When configured properly, SAP's Netweaver Gateway can expose all sorts of data inside SAP as OData feeds.  You can ingest data into your PowerPivot and/or SQL Tabular models directly via those OData feeds.

The approach sound rather promising, as Gateway brings Power BI (via either Power Query or Power Pivot - your choice) much closer to SAP source data.

For a synopsis of what SAP Netweaver Gateway is all about, I encourage you to check out this quick 2-minute video on the topic.  For those (like me) that aren't necessarily SAP experts, here's what I have learned about Gateway so far:

• Gateway is another server/service in SAP Netweaver's portfolio of offerings - introduced in 2011
• It was originally designed to support some SAP initiatives - particularly around mobile device access to SAP data (among other use cases)
• Gateway can technically support both read-only and read-write scenarios.  For our purposes (in a BI context), we generally care about read-only access.
• In SAP lingo, you use Gateway to build out a "service". Think of a "service" as a logical sequence of steps that:
• Locates source data in SAP (BW, ECC, RFCs, ABAP programs, whatever)
• Configure the columns/datatypes/other metadata that will be materialized through the feed
• Configure the OData feed itself (the name, the outgoing data, etc.)

SAP tends to use the term "lightweight" quite a bit when talking about use cases for their Gateway offering.  When I spoke with one of SAP's product managers for Gateway, he confirmed my thinking - you're probably not going to hoist 10TB of data out of Gateway and into Power BI via OData feeds.  However, there are plenty of times (especially in self-service scenarios) where you don't need a metric ton of data in SAP.  In those kinds of cases, Gateway looks to be a rather viable option.

Clearly, some work needs to be done in SAP Netweaver Gateway to set up this "service" prior to doing anything in Power BI.  For a 10-minute overview, check out this demo.

And even you - yes YOU - can utilize a demo SAP Netweaver Gateway instance (for development / educational purposes, of course).  Check out the link here to get signed up for a trial.  SAP will send you trial credentials pretty quickly, if your experience is like mine was.

Paul Aschmann @ SAP wrote an excellent article/tutorial on how to get Power BI talking to Gateway.  Once you have signed up for the trial account, you'll be able to use Paul's demo feel (classic Sales data).  If you have already created your test account, you can access the feed directly from this URL:

https://sapes1.sapdevcenter.com/sap/opu/odata/sap/ZGWSAMPLE_SRV/SalesOrderCollection

In Paul's article, he uses Power Pivot to pull in rows from the feed, and then present it back to the audience in Power View.  You *can* take things one step further by introducing Power Query into the mix.  Paul's feed has nested tables for Order Details - something that Power Pivot will generally ignore when wired directly to this feed.  With Power Query, you can expand the context of the feed to expose the nested details.  Very cool stuff. 

I highly encourage you to review Paul's article.  In addition, I would love for you to check out a quick demo I put together on the topic - which basically piggy-backs on Paul's example. 

Please check out my demo here: https://youtu.be/ncNmrPamRSg

Ultimately, I want to put together an end-to-end demo that shows *both* the creation of the SAP Netweaver Gateway service to Microsoft Power BI.  I'll post a follow-up once I get some interesting services built out on my own in Gateway.

With a net-new strategy at our disposal, it's worth considering some of the questions you're bound to encounter:

• Licensing: As I understand things, Gateway does *not* require any sort of Open Hub licensing agreement.  AFAIK, *any* SAP user that is properly licensed for traditional SAP tooling can access SAP data via Gateway.  In most cases, I think many of my customers will be fine here.  However, you might need to think about extranet scenarios here - do you need to provide SAP data to non-employees via Gateway?
• Scale: SAP calls this a "lightweight" approach.  Common sense dictates that you're most likely to get good results when analyzing OData volumes in the megabyte range, not the terabyte range.  At the moment, I am not aware of a specific data source size at which the OData feed approach breaks.
• Roles: In terms of roles and responsibilities, who should own the creation of the Gateway service?  Is it the same audience of analyst-types that tend to use Power Query and Power Pivot extensively, or is there some specialized role required there?  And what does a company's data governance guidelines suggest about things? 
• Production-izing: Unlike a conventional Power Pivot-based app (that can be promoted from the desktop to SharePoint to SSAS Tabular), I wouldn't expect one of these "lightweight" scenarios to auto-magically transition into some enterprise grade approach (as discussed here). 
• Security: Everyone's favorite topic, isn't it?  Expect the need to lock-down your Gateway services so that only the "correct" people in the audience can access the OData feeds.

I certainly don't have pat answers for each of the considerations above, and - as always - your mileage may vary.  That being said, the SAP-to-MicrosoftBI-via-Gateway path looks incredibly promsing for any number of self-service scenarios I have encountered.

By the way - I need to give tons of credit for this article to my colleague Chris Finlan.  Chris recently joined Microsoft - coming from SAP - and he was gracious enough to educate me on this approach.  Chris is a huge addition to my local team (Mid-Atlantic USA) - check out his blog @ http://thepoweroflightswitch.com/

Yesterday (8/12/2013), Power BI received some attention from the press.  Here's one of the articles that I had seen talking about the "release" of Power BI:

http://www.neowin.net/news/microsoft-releases-power-bi-office-365-for-windows-8rt

Some of us inside Microsoft had to address all sorts of questions around this one.  For the most part, the questions revolved around the *scope* of what was actually released.  You have to remember that Power BI is a broad brand name that takes into account:

* Power Pivot/View/Query/Map (which is available now, for the most part)

* The Office 365 hosting of Power BI applications with cloud-to-on-premise data refresh, Natural Language query, data stewardship, etc..

* The Mobile BI app for Windows and iOS devices

Net-net: we announced the availability of the Mobile app (in preview form).  At present, it is only available on Windows 8 devices (x86 or ARM) - no iOS just yet.  The rest of the O365 / Power BI offering is yet to come.  Check out this article to find out how to sign up.

http://blogs.msdn.com/b/ajmee/archive/2013/07/17/how-can-i-check-out-power-bi.aspx

So, the headline story is really all around the Mobile app.  You can grab it today from the Store - just search on "Power BI" and it should be the first app that shows up.

Yep it's that dark-blue app in the top-left corner of the list.  Install that, and you'll be able to play with the app.

When you fire up the Power BI mobile app, you have the option of using three sample applications (Healthcare, Olympics, and Car Sales.) 

I'm guessing, though, that you may want to see your own data pop up in the app.  You can surely do this with the preview edition, but be aware of the following:

* You'll need an Office 365 Enterprise tenant to host your workbook.  You can get a free trial here: http://office.microsoft.com/en-us/business/office-365-enterprise-e3-business-software-FX103030346.aspx

* The Power BI mobile app is still in preview mode.  Some aspects of Power View (e.g. maps, scatter plots) will not render with the initial version.  As with other apps downloaded from the Microsoft Store, you can expect simple updates to bring along new/fixed features.

Here's how it works - you create an Excel workbook that includes your Power Pivot models and some views of the data.  Views can be built out with either conventional PivotTables/PivotCharts and/or Power View.  Once you have created all of the content, you publish it to your Office 365 site.  From there, you can point the Mobile BI app (using the "Browse" feature) to your Office 365 site,  Your Power BI mobile app is now connected to your data - and you'll see the content coming through the app.

I put together a video demo of how to get things working with your own data.  If you know how to create a Power Pivot model, these steps should be easy-peasy.

https://www.youtube.com/watch?v=q1qD5h7iUc4&feature=youtu.be

Keep in-mind that the mobile app lets you browse and interact with BI content.  It is *not* a tool that can be used to create any reports/dashboards/etc...

Enjoy!

One of the sessions was focused on wiring up Microsoft BI to SAP - an ever-interesting topic.  During the session, it was announced that a customer/partner-ready whitepaper on the topic had been published. 

You can grab a copy of it here.

The whitepaper does a very good job outlining some of the options available.  Unlike wiring MSFT BI to a database, per se, SAP offers more/varied integration points.  If you want the Cliff's Notes version, I think about three core questions we need to ask. 

• Enterprise or Self-Service: are we thinking about a conventional, IT-led implementation of BI (using Integration Services, Analysis Services, etc.), or is the Power Query/Pivot/View/Map route more appropriate?
• ECC or BW: do we have a BW implementation to which we can connect, or are we pulling raw ECC data from SQL Server/Oracle/DB2/whatever database SAP runs against?
• Is SAP the "Center of the Universe?": Do we assume that SAP contains the entire breadth of data required for every BI activity, or are there other data sources and applications that need to also be analyzed (and potentially blended with SAP data for comparative purposes)?

Here's a decision matrix that I use to help rationalize the conversation.  Of course, a combination of strategies may very well be appropriate for your particular implementation.

You'll tend to find the classic tradeoff when considering duplicating SAP data vs. leaving in-place.  While "duplication" may not be great from a storage perspective in some cases, you generally get the performance benefit out of the investment (especially when wired to the xVelocity engine).

Of course, there are plenty of other considerations to take into account - Open Hub licensing considerations and data governance being two that come to-mind immediately.  Hopefully, though, the whitepaper and/or my decision matrix will help get the conversation started.

If I have missed anything here, I'd love to hear your thoughts - thanks for reading!

• Power BI delivers self-service BI modeling, transformation, reporting, and geospatial via Office 365.
• Of course, you can run both the traditional (SQL/SSAS/SSRS/SSIS) and self-service (Power Pivot/Power View) by provisioning capacity through the Azure VM role. 

We're still very early in the game, of course.  Azure IaaS is still pretty new, and Power BI has a few months and some rigorous testing before it's released.  So my guidance here is far from complete.

However, it does make sense to think of the scenarios where one approach may be better than another.  At present, I find it may be a stretch to see many "better-together" stories (i.e. where BI is provisioned through both Azure VMs and Office 365) - but I'm sure an exception or two will pop up.

Here's my first stab at rationalizing the choice - I'm sure the thinking will need to evolve over the coming months.

You can grab Power Query and Power Map from this location: http://office.microsoft.com/en-us/excel/power-bi-download-add-in-FX104087144.aspx.  Note that the Power Map add-in still uses the old "GeoFlow" code name as of this writing.

You can, of course, get Power Pivot from http://www.powerpivot.com if you are running Office 2010 at present.

In my example, I use the Foursquare API.  Documentation for their API is available here:

https://developer.foursquare.com/overview/

You'll see that any user-specific Foursquare queries (e.g. you might want to know how many check-ins did Foursquare see at Location X) require OAuth authentication.  At the moment, I'm not sure how you can *easily* bypass the OAuth requirement of Foursquare's API when using Power Query.  For now, we'll use their "Venues" endpoint.

The demo is available below.  Nothing too glamorous here - just wanted to share how you configure Power Query to sift through JSONs to get the data you need for your analysis.

Enjoy!

[View:https://www.youtube.com/watch?v=OdrVLrsCals]

Now, I get it.

The easiest way to think about Power Query vs. Power Pivot is to look at things as ETL vs. business modeling.  In the conventional Microsoft BI stack, you have SSIS for ETL tasks and SSAS for modeling.  In no way would someone expect your cube development, for example, to simultaneously address integration/cleansing/manipulation kinds of tasks.  The same sort of principle applies to Power Query and Power Pivot.

So far, I've noticed the following real-world uses for Power Query:

• You can pull data from sources that aren't readily available in Power Pivot - Facebook, MySQL, and Hadoop are notable data source types built right into Power Query.
• Inline transformations are a breeze.  When your inbound data isn't exactly how you'd like it, Power Query provides some built-in transformations (splitting columns and un-pivoting data are two popular tasks) that can help square up data prior to modeling in Power Pivot.
• If your transformations wind up being fairly involved, Power Query provides a nice "Steps" view that recaps each transformation.
• My favorite - materialized tables!  Let's say you have a single table (with the same structure) in two different databases (perhaps one is located in Europe and one is in North America) that you want to analyze as one all-up entity.  By itself, Power Pivot cannot automatically consolidate multiple tables into one.  With Power Query's "Append" and "Merge" functions, it's pretty easy.
• When calling Web APIs, the data is often produced in a structure unlike a flat source or relational database.  JSONs, in particular, don't lend themselves to directly feeding a Power Pivot model.  With Power Query in the middle, Power Pivot is able to ingest data from Web APIs.

So is Power Query necessary for *every* Self-Service BI use case?  Nope - if you're wiring things up to a well-designed data warehouse, and the DW has everything you need, you probably don't need to pull Power Query into the mix.  Short of that, you may find Power Query to be a really helpful addition to the arsenal.

I recorded a 30+ minute demo on Power Query and Power Map - illustrating how to grab data from Craigslist and plot some dollar figures on a map.  Hopefully, it'll show why Power Pivot alone would not have been able to solve for this particular requirement.  The demo starts with the raw data (RSS feeds, in this case) and ends with a completed (albeit thin) Power Map illustration.

[View:https://www.youtube.com/watch?v=_BnVGNlYuP0]

https://www.youtube.com/watch?v=_BnVGNlYuP0

Hope you enjoy it!

If you know me already, I'm grateful that you followed me over here.  If not, here's the quick story on my background:

• At Microsoft, I am a Principal Specialist for Business Intelligence - aligned to enterprise accounts in the Mid-Atlantic USA.
• I came to Microsoft in April 2006 as part of its acquisition of ProClarity.
• I started with ProClarity in the days of SQL 7.0 (i.e. the initial version of SQL Analysis Services).
• I have been in the BI space since 1994.

I won't bore you all with the bio minutia.  I'm thrilled you're here and hope you keep visiting.

My posts all reflect my own perspective on things - in no way do I represent the "official" Microsoft position on any and every statement I make :)