In a session at the recent Sapphire in Madrid, Executive Vice President SAP NetWeaver Björn Goerke mentioned a new NetWeaver Cloud “Gateway as a Service” (GWaaS) offering that has a considerable impact on other existing SAP offerings.
Note: Björn’s presentation came with the usual disclaimer slide exonerating SAP of any responsibility to actually implement any of this stuff but let’s just pretend that they will actually do it.
A Caveat: There is actually very little additional information available for the new offering so I have absolutely no further details regarding what the service really contains. But this ignorance also provides me with a certain degree of flexibility in my exploration.
NetWeaver Gateway: Background
What is Gateway?
The SAP NetWeaver Gateway is a set of ABAP add-ons to your existing SAP Business Suite system that provides easy access to your business information in a simple, people-centric manner and lowers the data consumption barrier to the point that no prior knowledge of an SAP system’s internal workings is required. [SOURCE]
The product makes extensive use of OData which is sent to various consumers.
The architecture of Gateway is non-trivial and involves a large number of components – the majority of which ABAP-based.
Gateway as a Service: Analysis
My assumption is that the functionality of GWaaS in NetWeaver Cloud is closely tied to the requirements of the new Mobile as a Service offering. This new mobility service originates from the Sybase Unwired Platform where NetWeaver Gateway plays a central role. The main focus of the GWaaS offering will be to enable services to push OData to the MaaS and other applications.
The most interesting question is why GWaaS is even necessary at all since many existing OnPremise customers might already have a Gateway server present in their landscape. If they don’t, then the presence of a GWaaS might remove the necessity of purchasing a Gateway server which would be counter-productive to SAP’s sales.
I don’t think that the functionality of the GWaaS can equal the functionality of an OnPremise Gateway server. The fact that the OnPremise Gateway servers are based on ABAP and NetWeaver Cloud is based on Java means that a direct port isn’t possible and architecturally is probably impossible.
One interesting thought is the possibility of a ABAB-based Gateway Server (perhaps based somehow on the ByDesign technology stack) that is hosted in the SAP Cloud infrastructure and which has the ability to support multi-tenants in one instance. Although theoretically possible, I don’t think this would work.
What sort of use cases might be possible with this new service?
Use Case: Providing an OData interface for SAP OnPremise assets
One interesting similarity between the OnPremise Gateway product and the GWaaS revolves around interaction with backend systems. In the NetWeaver Gateway environment, this is provided by the Data Source Providers.
Data provisioning implementations done on Gateway as a hub usually need to access business suite systems either via RFC or Web Service. The Content Provider Connectivity abstracts from such protocol specifics by means of a System Alias, which can be configured by the administrator to point to the desired RFC and/or Web Service destination.
In the NetWeaver Cloud, a similar functionality is provided by the Cloud Connector.
Currently, the Cloud Connector is primarily focused on the connectivity-related aspects (authentication, security, etc) of the interaction.
Thus, one possible scenario might be to use the Cloud Connector to access OnPremise assets and then use GWaaS to enrich the data via OData.
There is already documentation showing how use to the Cloud Connector to execute REST-enabled RFC calls.
Currently, the Cloud Connector only allows the access to REST-enabled back-end systems. In the future, other protocols will be possible as well.
Although there are similarities between the NetWeaver Cloud and NetWeaver Gateway in this regard, there are also some differences (For example, the ability to use screen scraping and Subscription Push scenarios) which show that Gateway is still more advanced – perhaps because of its greater maturity.
The best situation would be if the advanced functionality remains in the NetWeaver Gateway product and not in the GWaaS offering. Customers with such requirements would then be forced to buy the OnPremise offering. GWaaS should be for more standard business requirements. This would also help SAP justify the costs of the OnPremise Gateway infrastructure.
Use Case: Providing an OData interface for non-SAP OnDemand assets
In this case, GWaaS wraps other OnDemand services and provides an OData enhancement.
I have no idea how this might work – which tools might be necessary – but it is a possibility
Use Case: Wrapping existing OnPremise Gateway installations
Another possibility is that the NetWeaver Cloud ‘Gateway as a Service’ just wraps existing Gateway services.
Note: It is also possible to deploy Gateway in the Cloud. Fellow SAP mentor John Moy has already written a series of blogs about deploying Gateway on AWS. So this use case might also be relevant for such cloud-based instances.
This doesn’t appear too logical inasmuch as you would be adding a layer of complexity plus additional costs and just duplicating functionality.
I can only think of the scenario where a partner develops an application – which requires OnPremise Gateway – that is deployed on NetWeaver Cloud across multiple tenants. Then you could use bundle everything together and the GWaaS might hide some the involved complexity (for example, tenant administration, etc).
Although this use case was officially described in the slides, it really doesn’t make sense to me.
The important thing is that SAP describe which use cases are appropriate for which deployment model. In some cases, the use of GWaaS is probably warranted. Customer and the ecosystem at large need more details here. With such information, the sales of OnPremise Gateway installation may be detrimentally affected as some sales prospects may assume that GWaaS is the same as an OnPremise installation.
Although I have absolutely no details, one important distinction between GWaaS and an OnPremise installation may involve the respective pricing structures. A subscription-based pricing model – which I assume will be present for GWaaS – may be a better match for some customers – for example start-ups.