Skip to Content

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.

/wp-content/uploads/2012/12/image001_161938.gif

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.

/wp-content/uploads/2012/12/image002_161939.gif

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.

Use Cases

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.

/wp-content/uploads/2012/12/image003_161940.jpg

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.

/wp-content/uploads/2012/12/image004_161941.jpg

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.

/wp-content/uploads/2012/12/image005_161942.jpg

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.

/wp-content/uploads/2012/12/image006_161943.jpg

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.

/wp-content/uploads/2012/12/image007_161944.gif

[SOURCE]

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.

Conclusion

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.

To report this post you need to login first.

10 Comments

You must be Logged on to comment or reply to a post.

  1. Thomas Wailgum

    Good post. Now, I just sat in on a webcast and heard all about “SAP HANA Cloud Integration” offerings. Where does that fit into this?  “…as if millions of voices suddenly cried out in terror (at SAP’s confusing naming conventions) and were suddenly silenced.”

    -Tom

    (0) 
    1. Richard Hirsch Post author

      My assumption is “SAP HANA Cloud Integration” refers to the old but still not in GA “NetWeaver Cloud Integration” offering.  I assume we will be seeing this transition in a variety of other areas as well (HANA Cloud Portal, etc).  The important thing is for SAP to describe why this name change is justified and why isn’t just “HANAwashing” (similar to “Cloudwashing“) – what does HANA really bring to these offerings beyond a new database.  A related question might be what this change implies in the future of the NetWeaver brand in the cloud. Working on a few new blogs on this topic right now.

      (0) 
  2. Fred Verheul

    Hi Dick,

    Good digging, again. But we really need more info from SAP to make sense of it, in my opinion. There is a reason that the on-premise Gateway product is positioned so closely to the backend system. You seem to lose that ‘advantage’ (it’s been presented more as a necessity AFAIK) in the scenarios above.

    But it’s exciting times for sure 🙂 .

    Cheers, Fred

    (0) 
  3. Graham Robinson

    Hi Dick,

    another great blog.

    Did you consider that GWaaS might be used to expose NW Cloud applications as OData services for consumption by other technologies?

    Cheers

    Graham Robbo

    (0) 
  4. Fons van Nuland

    Hi Richard,

    Nice blog. Might one of the advantages of GWaaS be that you can offer services that resides in the cloud? Consumers of the services do no longer need to connect to the corporate network on which resides your business data. They just connect to the cloud and therefore it is more secure than connecting directly to your on-premise systems.

    How do you think about that?

    Best regards,

    Fons

    (0) 
    1. Richard Hirsch Post author

      Yes – that is one of the main advantages of GWaaS – especially combined with the current Mobility as a Service offering.

      D.

      (0) 

Leave a Reply