NetWeaver Gateway: What about Java?

[hofmann]

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.