SAP Gateway for Microsoft sp3 – from productive App development to Microsoft cloud hosting
GWM Azure / sp3 provides support for developer productivity, and infro support to the cloud.
On 16 September, SAP released the latest version of Gateway for Microsoft: SAP Gateway for Microsoft Service Pack 3 – Embracing the cloud! The focus of service pack 3, codename ‘GWM Azure’, is to augment the development support provided in the first GWM versions, with enterprise ready infra support to deploy and run the build Apps into the Microsoft cloud.
In this article I briefly outline how the combined development + infra capabilities are used to productively create and deploy a new scenario that exposes your on-premise SAP functionality to Microsoft front-ends in the cloud.
- You have SAP functionality exposed via Gateway REST services
- You have Gateway for Microsoft (GWM) sp2 or sp3 Visual Studio Add-In installed on your .Net development machine(s)
- You have Gateway for Microsoft sp3 (‘GWM Azure’) deployed in the organization’s Microsoft Azure tenant
First step: develop your scenario using GWM Visual Studio Add-In
The first development step is to create a new project in Visual Studio. E.g. create a project for SharePoint 2013 App, a project to create an Office 365 task pane App that can be used in Outlook client and Outlook Web Access to access SAP data, or a Windows 8 / Windows Phone 8 App. In this Visual Studio project, use the GWM Add-In to generate the consumption of your Gateway REST service(s). For this, you select ‘Add SAP Reference’ from the Visual Studio menu. In the opened dialog you browse and inspect the Gateway REST services that are available in your on-premise SAP landscape. You can inspect each service upto their OData data structures, and even invoke the service to inspect life OData service results.
This developer support is very valuable. It enables .Net developers to explore the available SAP services direct from the familiar .Net development tooling. Instead of forcing the .Net developer to use the unknown (and very likely not even present on their machine) SAP GUI to explore the services via /IWFND/MAINT_SERVICE:
And the GWM Service Explorer also provides a more natural navigation to gain insight, by it’s capability to directly explore from Gateway service repository upto the life service data. /MAINT_SERVICE only provides a static view on the Gateway service repository, and to explore the life data in the SAP GUI you must use the separate GW_CLIENT transaction (or use RESTClient).
Click on ‘generate proxy’ to fully automatic generate all required artefacts to consume the SAP Gateway REST services within .Net application context. This beholds the datamodel classes to parse and hold the received OData JSON structures, webclient proxy, system monitoring and authentication handling. For GWM Azure based consumption, the datamodel classes are sufficient. GWM Azure namely out-of-the-box provides for the other parts to consume SAP data from the Microsoft Azure cloud context.
Use the generated datamodel classes to bind the SAP data into the .Net App, and build a rich and user-friendly consumer application.
Next step: deploy your scenario from Visual Studio into Microsoft cloud
This is standard Visual Studio 2012/2013 capability. You simple deploy the build GWM App to your configured Azure tenant, in which you also have installed GWM Azure.
After the App is deployed into the Microsoft cloud, run and test it. GWM Azure provides all the required infra capabilities: service connectivity from Microsoft Azure cloud to your on-premise SAP landscape, enterprise ready Single Sign-On to authenticate via SAML2 with Microsoft Azure AD credentials against the SAP Gateway system, monitoring of the chain Microsoft Azure – SAP on-premise.
The initial versions of Gateway for Microsoft focussed on .Net developers, and enables us to productively consume and operate against SAP functionality while abstracting from the SAP-proprietary internals of the SAP system. Application developers can utilize it to build rich .Net desktop applications, but also use it to bring SAP data within SharePoint 2013 (Connect SharePoint 2013 to SAP via Gateway for Microsoft).
The latest GWM version extends it’s applicability to Microsoft Azure cloud as consumption channel (and from there to SharePoint Online, Office365, Windows 8), while still supporting the developer productivity. In this, it supports both the .Net developer as the infra/operations role. A clear win in my perspective.
Hi William: Very Informative Post about GWM SP3. Which Operating system do you have for development environment? I can explore the services just fine but seem to be having some issues on when trying to consume demo service in Visual Studio. I have Windows Server 2012 R2 for my development environment.
Update: Figured out the issue. I hard coded the SAP service URL as it couldn't read from the config file.
mine was Windows Server 2008 R2, with Visual Studio 2013.
as GWM depends on .Net Framework 4.x, Windows Server 2012 R2 is also a valid client platform to consument Gateway services via GWM sp3.
What issues do you encounter?
Thanks William for the quick response. I'm able to get the data after I hard coded the URL to the OData service in the code. I have to figure out why it is not reading from the config file.
I've had same issue when using GWM in webapplication (SharePoint) context; a bug in GWM sp2 was that configuration reader expects a Windows Form based path.
see another post: http://scn.sap.com/community/interoperability-microsoft/blog/2014/07/14/connect-sharepoint-2013-to-sap-via-gateway-for-microsoft
William: Thanks for sharing your post. I got the GWM SP3 working with a Windows Form Application but when running the same code in an ASP.NET Web application, I get the following error:
"The authentication type BASIC is not supported currently".
Please let me know if you run into any authentication related errors. I have followed the instructions at the following site:
Working with SAP Service Reference to Generate Proxy Classes - SAP Gateway for Microsoft: Visual Studio Add-In - SAP Lib…
I figured it out. GWM SP3 generates slightly different code in the BusinessConnectivityHelper.cs for a web app as compared to a Windows Form app. I looked into SSOProviderFactory and was able to use overloaded method GETSSOProvider that accepts basic creds.