Skip to Content
Author's profile photo William van Strien

Connect SharePoint 2013 to SAP via Gateway for Microsoft

SAP initially developed Gateway for Microsoft [GWM] as ‘Duet Enterprise beyond SharePoint’. Allow Gateway OData service consumption in other Microsoft front-end formats, like Microsoft Office clients (Outlook, Excel, Word, PowerPoint). In essence GWM can also be regarded as a trimmed-down Duet Enterprise 2.0 variant; provides some of the same basic integration capabilities, but not all. Question that arises: can you also utilize GWM to connect SharePoint to SAP?

The answer is a firm Yes you can! Which is logical, as SharePoint itself is a .Net application. You can apply multiple approaches to consume the SAP data through a GWM generated reference proxy into SharePoint:

  1. Connect to the Gateway service proxy from a SharePoint web part context [mind you, Microsoft urges us to step away from this SharePoint server-side model; but it is still possible and supported]
  2. Build a custom BCS Connector to connect to the Gateway service proxy, and use that connector from SharePoint to render the received SAP data via standard External List, Business Data WebParts, or a custom build web part that invokes the BCS Api
  3. Build a SharePoint WCF RESTful service to connect to the Gateway service proxy, and consume that service in a browser-based front-end; using a databinding library like knockout.js, Angular.js. This is an example of SharePoint 2013 App model, and can also be applied in Office 365 / SharePoint Online.

SharePoint version

SharePoint 2010 has been build “ages ago”, and has a hard dependency on .Net framework 3.5. In the current year, the .Net framework has progressed to .Net framework 4.5, and the latest version of SharePoint [2013] has catched up with that. And the same holds for Duet Enterprise 2.0 [which is actually for SharePoint 2013, if you have SharePoint 2010 you need the Duet Enterprise 1.0 version], and also GWM: both are .Net Framework 4.x dependent.

As consequence, I have to relax my firm statement a bit: Yes, GWM can be used to connect SAP and SharePoint 2013; but not for the older SharePoint versions (2003/2007/2010).

Simple example for Proofing

To demonstrate, I made up a sample scenario to retrieve SAP CRM data via GWM into SharePoint. I used the demo Gateway services as data source (see article by Martin Bachmann for instructions how to get access to the SAP Gateway demo system), and our own SharePoint 2013 environment as front-end. Further I have Visual Studio 2013, and necessarily also the latest GWM sp3 SP02 (versions preceeding sp3 SP02 will not install in Visual Studio 2013; but they do install in Visual Studio 2010/2012).

I applied the guidance provided in the GWM Developer Guide, but instead of Windows Forms project, choose SharePoint Visual Web Part template.

Create SharePoint 2013 Web Part.png

Next, you first need to add references to .NET WCF and GWM libraries. The easiest way to achieve that is by utilizing the GWM Visual Studio Add-In. Click on ‘Add SAP Service Reference’:

Add SAP Service Reference in Visual Studio.png

fill in as Service Url the url to GWdemo service, and press ‘Go’:

Add GWM SAP Reference.png

In the Service Explorer you can explore and inspect the OData entities that the GWdemo service exposes. Select one, and click ‘Ok’. Direct result is the inclusion of multiple GWM assemblies (note that they are still named with the older GWPAM naming) in the Visual Studio project references:

GWM references added.png

Next, open the visual webpart and put in some code to consume the GWM created proxy reference and display received data. As this is merely a short demo to proof the connectivity, I simple display the SAP CRM BusinessPartners through a plain GridView control:

Invoke GW service via GWM.png

Build the Visual Studio project, and deploy the SharePoint solution. Then browse to your SharePoint site, create a new page, and add the GWM-build web part. And voila, we have SAP data in SharePoint:

SAP CRM data in SharePoint via GWM.png

All in all, building this took me less than an hour. Of course it is only a simple retrieval example; and no effort spend whatsoever on achieving a good looking and behaving UI. Also for this simple example I relied on basic authentication. For a trustworthy enterprise context, this is not usable and either OAuth, X.509 or SAML must be applied. But still, the outcome is very promising with respect to the SAP/SharePoint interoperability capability of GWM.

Fixes needed to GWM generated code

Issue 1: Microsoft.Sharp not included in references

Missing .Net references.png

Solution: Add the missing assembly to the Visual Studio project references

Add missing assembly to references.png

Issue 2: Configuration Reader tries to read from windows form based path

ConfigurationReader attempts to access local system path.png

Solution: avoid the attempt to read from windows-forms based path.

Issue 3: The used GWDemo system gives error

GWDemo gives error.png

Solution: invoke another method 😉

Working GWDemo method.png

Honestly: this is an example of why in every SAP interoperability project also domain knowledge is required –> contactpersoncollection is connected to a business partner key, you cannot invoke this without one.

Does GWM replace Duet Enterprise?

The answer to this is a clear No: Duet Enterprise as framework has more capabilities as GWM: SAP workflow integration, SAP BW reports publication, roles synchronization, user profile synchronization. Also Duet Enterprise has complete self-contained support within for Single Sign-On between SharePoint and SAP, while with GWM you need additional infra to achieve this (e.g. X.509 certificates infra in your landscape).

The better question is however: in what scenario’s would GWM be sufficient? Well, it might be sufficient in scenarios where all you need is the connectivity from SharePoint to SAP for data CRUDQ actions, and you already have Single Sign-On supporting infra in your IT landscape.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hi William,

      thank you for this very intersting blog. Just one very small correction. You must have used GWM SP02 (not SP03) in your coding -- SP03 is not yet avaialble. We hope to release it with some nice planned features for Office 365 (as you know 😉 ) in the next few months.



      Author's profile photo William van Strien
      William van Strien
      Blog Post Author

      Hi Holger,

      You're right; being a member of the Customer Engagement Initiative I indeed already know of sp3 - but are not allowed to blog on that in depth 😀 - and got the versions mixed up. For Visual Studio 2013, you need to install GWM sp2; which can be downloaded from SAP Marketplace.

      Note: congrats with winning the World Championship [but you have not defeated us 😛 ]

      Regards, William.

      Author's profile photo Former Member
      Former Member

      Hello William,

      I'm currently trying to connect SharePoint Foundation 2013 to Sap Netweaver Portal 7.0. The old versions of SharePoint had an IViewWebPart, but currently this web part has been removed from 2013 version. I'm a little lost in terms of how to achieve this connection. Could you please shed some light on this?


      André Noivo

      Author's profile photo William van Strien
      William van Strien
      Blog Post Author

      Hi André,

      The SharePoint 2007 iViewWebPart (it was already deprecated and no longer standard deployed in SP2010) enabled 'on-the-glass' integration of SAP EP iViews as iframe in SharePoint pages. You effectively then mix SAP EP ui-experience/behavior into SharePoint based.

      This is very different from the type of integration that is possible via Duet Enterprise, GWM: these offer connectors to get SAP data into SharePoint context, which next can be visualized in real/native SharePoint UI controls: standard or custom UI.

      If it is sufficient for your scenario to offer the end-user 'on-the-glass' integration, then you can compensate the removal of iViewWebPart by custom-build alternative. See the thread "Sharepoint 2010 - SAP Portal - Integration" for a start on how to achieve that. Note that you will have to provide SAP EP logon-functionality yourself.

      Regards, William.