SAPUI5 applications – is SAP Gateway always necessary?
In a lot of blogs and presentations SAP Gateway is mentioned as the communication layer between the SAPUI5 application and a SAP backend system. One of the main advantages of SAP Gateway is that the communication is handled with the ODATA protocol. This protocol is amongst other responsible for the navigation between entities in a service (like a sales order and its positions) and handles part of the security of the communication.
Is SAP Gateway always necessary? See for example the following scenarios:
- A company does not have a SAP Gateway system available and/or the current SAP backend system has to be upgraded in order to communicate with SAP Gateway;
- The requested application contains only a simple overview without any navigation;
- The application will only be used within the own (company) network en there is no need to call the application from outside this network.
In the above scenarios the advantages of ODATA (and to some extent SAP Gateway) are not as clear as in other scenarios. Another possibility here is to use a direct communication between the application and the backend system with help of JSON.
SAPUI5 is perfectly capable of handling JSON formats (e.q. standard libraries available for JSON model) and a SAP Netweaver ABAP stack also has several tools for processing this format.
A SAPUI5 application can, as mentioned, use several models, like for example an ODATA and JSON model. This document presents a way to communicate with a SAP backend system without the use of SAP Gateway.
One of the possibilities to send a response to a SAPUI5 application in JSON format, is to create an own handler class which has to be linked to a (new) ICF node. This class will have to implement interface IF_HTTP_EXTENSION, which is needed for processing the request. This (new) ICF node will be directly linked under the ‘DEFAULT_HOST’ node, which shortens/simplifies the navigation path from outside the system. The handler class can determine what kind of request has to be done. Dependent of the type of request the data collection will be executed and the data will be returned in JSON format.
That’s all about the theory! Let’s have a look at an example and configure the system so the data will be displayed in a SAPUI5 application. The first step to be executed is the creation of a handler class with will process the request.
First determine in method HANDLE_REQUEST which type of request has to be executed (this is only needed when the ICF node is used for multiple types of requests).
Next step is to perform the data collection and after this step the retrieved data is transformed into a JSON string.
Finally the JSON string has to be added to the response (don’t forget to set the content type as well) and the status should be set to ‘successfully processed’.
The handler class is ready now, next step is to define an ICF node which will be the access point for the SAPUI5 application.
The handler class has to be attached to the node.
The backend configuration is completed now. Next step is to enable the SAPUI5 application to communicate with the created ICF node.
Create the connection between the fields in the internal table (in this case SO_ID) and the columns of the table in which the data will be presented.
The last step is to link the created model to the table and also indicate which node will be called in the JSON file.
See the results of all performed actions, where the content of the internal table is displayed in a SAPUI5 application.
When completing (or reading) the article, it hopefully becomes clear that converting an internal table into a JSON file with help of you own handler class, is an easy way to publish data into a SAPUI5 application. So in case of the scenarios earlier mentioned, this solution is a good alternative for using SAP Gateway.