Advantages of Gateways over ICF-based JSON service

[Former Member]

Hello experts,

I'm currently working on a thesis project thus I'm relatively new to the SAP ecosystem. So please bear with me

IN A NUTSHELL: What are the advantages of SAP Netweaver Gateway over the ICF-based REST/JSON service of this blog - besides nice little UI functionality?

DETAILED:

My application is to have a three layered architecture of SAP HANA, ABAP AS and SAPUI5. While researching how data might flow between the layers I found two approaches to exchange data between the ABAP layer and SAPUI5.

SAP Netweaver Gateways seems to be the solution of choice. However it comes with additional license costs. On the other hand I found a blog how to create REST/JSON based web service in ABAP to provide data for SAPUI5 ( ). This blog comes with the initial requirement of using ABAP and SAPUI5 without SAP Gateways. Skipping both the blog and information about consuming ODate with Gateways from SAPUI5 I wonder about the difference between the two approaches.

As what I can see the data will be handled just alike in SAPUI5 as it will become a JSON model or OData model - both are similarly bound. So from the UI perspective there shouldn't be a difference. Or am I missing something?

From the ABAP perspective I see that SAP Netweaver Gateway offers me a UI to create my OData service, whereas the linked blog needs additional coding to achieve that. However: the actual "doing" in the second approach should be easily repeatable for every object.

I would expect the Netweaer Gateway to provide me with additional functionality to build fancy new UIs if it demands licence costs. However all my research about "advantage of SAP Gateways" points to fact that it uses REST service. But that's exactly what the blog also does. If there's not more about SAP Gateways, I don't see a good argument to pay for SAP Netweaver Gateways (from the cost perspective of my boss).

I'm sure I'm missing something on that. But my research always points to the "cross-platform" argument based on the fact that Gateways offer me REST based services. Can anyone give me a hint? Or am I underestimating the amount of work for the approach in the blog?

Best wishes,

Philipp

[GrahamRobbo · Accepted solution]

Hi Philipp,

a few observations.

Firstly, as you rightly mention, the Gateway tools effectively generate the services for you without coding whereas you would need to code all this yourself if you chose to use your own ICF handler. This is not necessarily a huge task as with either alternative the back end functionality still needs to be built. It may be that you can use existing functionality or you may need to build it all yourself - this effort would be pretty much the same in either scenario. But having a single toolset such as that provided by Gateway to build, publish and manage the API's should make life easier, quicker and allow the developer to focus on the important business functionality rather than the plumbing.

Secondly, I do not believe there is any major differences in the licensing requirements no matter whether you use a Gateway service or your own ICF handler. As long as the end user is a so-called "named user" and therefore licensed to use the SAP backend for the functionality they are calling then my understanding is that the existing user license covers access to that functionality whether it happens via SAPGUI, Gateway, ICF handers, or any other method. If, on the other hand, your users connect as so-called "unnamed users" my understanding is that you will need to obtain appropriate licensing for such use. The good news about Gateway is that such a license arrangement in on the SAP price list. For a custom ICF handler you would need to figure that out with SAP. As always with licensing issues check with the SAP Account Exec.

Thirdly, there advantages to using oData services, such as those provided by Gateway, over the JSON example from the blog. Most obviously oData supports standard attributes that allow the client to request very granular subsets from a data collection. This has advantages if the UI controls, such as those provided by SAPUI5, also support oData. So, for example, a tableView control can just request the 10 records that it needs to display on the screen from a large collection and the Gateway service will ensure only those 10 records are returned. As the user navigates through the collection the tableView control requests the relevant chunks of data from the backend. This all happens without the developer having to code anything to support it.

Finally, Gateway includes a number of plugins for common developer tools such as Eclipse, Visual Studio and XCode that can accelerate the development process. There are also tools that allow you to take an entity data model file and import it into Gateway to create the service skeleton that can subsequently be implemented by the ABAP developer.

Cheers

Graham Robbo

[jmoors]

Hi Philipp,

You mention a 3 tier architecture, there is another possible option if you are planning to use SAP Hana, and that is The SAP HANA Extended Application Services (XS) engine which uses a combination of SAPUI5 and server side javascript.

SAP are currently running a free training course.

https://open.sap.com/course/hana1

Regards,

Jason