Skip to Content

Gateway allows consuming SAP data by REST and OData, but only for ABAP. Why isn’t SAP offering the same way of consuming data for the Java-based applications?


After all the years where SAP when was promoting web services as the only way for connecting and consuming data, without a doubt, NetWeaver Gateway is a paradigm shift of how SAP data can be consumed. Something is wrong when solution architects want to route all traffic between two systems over a PI system. Why Web Dynpro Java has to use a web service model that is retrieved from PI to talk to an ABAP system is not really obvious, especially when on the PI side no additional business logic is applied. Using PI as a web service proxy is an unnecessary overhead.

With Gateway the way to connect is more obvious. Without all the problems associated with web service, consuming REST/OData is relatively easy; and it can be done by Javascript. Not impossible when talking to a web service, but not as easy as with Gateway. From the different Javascript libraries and frameworks out there SAP created its own: SAP UI5: and that can talk directly to the data provided by Gateway.

And there we get a problem: Gateway publishes ABAP data. But what if your data is stored in a Java system? Gateway can show its true potential in combination with SAP UI5 or mobile applications. Here it is about giving end-users access to data. Without a doubt by far the largest part of data is stored in an ABAP system; but ignoring the Java part is ignoring the need of the end-user to access SAP data. Not talking about the clients that are using Java based solutions from SAP or developed their own solutions in Java.

A front end for SAP UI5 can be a portal. A portal is defined that it allows integration of data from different backends, thus breaking the information silos. NetWeaver Java or the SAP Portal allows integrating various SAP and non-SAP backends in a central place, with user management and single sign on in place. Using this infrastructure makes sense. As you can put SAP UI5 on top of NetWeaver Java, the consumption of the data there is not so easy with SAP UI5. Somehow the data needs to be made available. As there is an extensive API available, it’s meant to be used inside a Java application like a servlet or bean. So why not do a Gateway for Java? That`s not really complicated from a technical perspective.

For consuming Java data you can use beans. For consuming ABAP data, you can use the connector framework, JRA or CAF. Every one of these technologies allows for consuming ABAP data (BAPIs) in Java. For displaying them using REST and JSON, the developer can choose between a manual mode or by using a solution like Jersey.

Developers can choose between a more purist way and do everything by hand and gain full control over the JSON output or use CAF for designing the beans and then just consume the bean and transform it into JSON. Especially Jersey is a mature solution. Not only allows it for XML or JSON representation of the data, it comes with additional features like REST and OData support. The data representation can be configured in great detail and because it is an add-on solution it can be upgraded independently. Beans, POJO, the representation, as long as it`s Java it can be exposed and the way of doing so con be configured. That means: flexibility.

Plus, if I`m not completely mistaken, consuming SAP data by NetWeaver Java means that the business suite users are not charged by additional license costs.

To report this post you need to login first.

7 Comments

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

  1. Martin Bachmann

    Hello Tobias,

    SAP NetWeaver Gateway was designed by us to provide OData access to ABAP-based systems. In case other technologies require OData exposure you can have a look at the OData page – here you find libraries that can be used to OData-enable also e.g. the Java World. (http://www.odata.org/developers/odata-sdk) .

    Also for accessing NetWeaver by any other technology a valid user is required.

    Best regards,

    Martin

    (0) 
    1. Tobias Hofmann Post author

      Hi Martin,

      OData may be the original plan, but isn’t Gateway also getting JSON by popular demand? My question is: why no REST / JSON / OData solution for Java from SAP? No plans at all? Still waiting to see if Gateway survives and gets adopted by clients? Or is SAP waiting for an SAP partner to jump in and offer an endorsed solution?

      Yes, a valid user is required, but if I’m not completely wrong, business suite users can use something like jersey that runs on NetWeaver Java and consume data, may it be Java or ABAP, without the need to pay additional licenses, right?

      (0) 
  2. Fred Verheul

    Hi Tobias,

    Like I said on twitter: I still don’t fully understand your point. I do understand now (upon third reading 😀 ) that it’s about developing a framework on Java that exposes data (whatever data) in a restful OData/JSON way.

    I think I can see why SAP hasn’t done that yet: there is NO business data residing on the Java side: all (as far as I know) business data is kept in the SAP Business Suite, which is ABAP-based, and the SAP Java products that exist are not business applications (with the all-important business data we so desperately want to expose, open up, etc), but more tooling-oriented, like the NW Portal, Composition Env., PI (now PO), etc. Even if some customers use these platforms to write their own business apps and store some data there (which is perfectly possible, don’t get me wrong), it by far isn’t enough to warrant product development from SAP to make another Java-based Gateway. And to channel ABAP-data to Java, and then expose it from there (instead of using Gateway directly from ABAP), looks like a cumbersome solution to me.

    Besides: since all Java-based business applications (with business data) are custom built anyway (within the SAP Universe at least), why not let the customers that have such applications build the RESTful exposure too? Like you said, there are frameworks for that already, so what is the problem? (Maybe that is why I don’t understand the point you’re trying to make).

    So, to conclude: there is so little data to be exposed on the Java side, and there are enough frameworks out there already to do it, that IMHO it’s not necessary for SAP to do it again.

    Thanks for reading this comment (if you made it so far), and at least I’ve clarified my thinking for myself ;-).

    Very interested in the (differing?) opinions of others though.

    Cheers, Fred

    (0) 
    1. Tobias Hofmann Post author

      Fred,

      First, not all Java based business applications are custom applications. Environmental Compliance is (pure) Java, and comes from SAP (ok, after SAP bought technidata, but …!).

      SAP developed and promoted for years tools for Java developers like JPA, CAF, GP to develop business applications. And for years it was / is possible to expose SAP data on Java using REST (and oAuth, OData, XML, JSON). Now SAP developed Gatway that gives also access to SAP data using REST/OData, and everybody says: wow, that really was missing, great work SAP, finally we have REST and you can easily consume SAP data via Javascript. The small fact that this was already possible is not very well communicated. I`m not aware of a guideline from SAP that states: you can also use xyz for REST and not necessarily Gateway (that comes with its own license issues). Or is there an official guide from SAP?

      So we have there a J2EE server, several developer tools, an easy way to expose SAP data without installing an additional server / add-on, with SSO in place. So: why not use what is already there? Why exactly REST from SAP only for ABAP?

      Is some kind of REST/JSON/etc interface available for Neo? Or do customers / partners have to find their own way of exposing Java-based SAP data via REST?

      (0) 
      1. Mithun Kumar

        Hi Tobias,

           That’s really interesting to learn that some other way already existed before GW to expose ABAP data as REST/OData…

        If you don’t mind, can you please mention any of those ways, and any (even minor) references to those ways?

        (0) 

Leave a Reply