SAP Netweaver Gateway - Another Strategy for Microsoft BI + SAP Interoperability?

  • Article

Hi folks - thanks as always for reading my blog.

 

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 @ https://thepoweroflightswitch.com/