Skip to Content
Author's profile photo Krishna Kishor Kammaje

oData for Everything? may be not!

While building ui5 applications using oData, there were may instances where I had to make any adjustments to represent everything coming-out/going-into SAP in terms of oData. Most of the times, these were work-arounds thus telling me that oData is not the one-data-model-fits-all solution.

Think about a scenario where I need to validate a user entered VIN number on a UI5 application. All I require is a ‘Valid’ or ‘Invalid’ from this functionality. I can create an entity for VIN but that is an overkill for my functionality.

Some other scenarios I can think off are

     – “Update notes for a Sales Order”.

     – “Get drop down values/ dependent values ”

Wait! What about Function-Imports? Are they not designed for this exact purpose? Yes, they sound like. But either they return a complex type or an entity type or nothing at all. I do not want to create a complex type for knowing Valid/Invalid. Solution might be to allow Function-Import to return edm types, thoug NW Gateway is not yet supporting it (but part of oData 2.0 spec). Even with this feature, what about the various cover information part of the oData grammar? The other problem with the Function-Import is that it does not allow the request body, thus you need a work around even if you have a simple hierarchical information to be passed to the server.

I was going through HANA development training and found something useful. It allows creation of a XSJS service which solves most of these problems. I felt that HANA product has allowed XSJS services in addition to XSODATA services to suit exactly the scenarios I am talking about.

But we have ICF services in ABAP server which can do exactly the same by linking with an ABAP Class as request handler. But this would need enhancement to handle system aliases so that I can rout my ICF request from the Gateway system to the right back-end system. CSRF protection might be a good enhancement too.

Another solution would be to integrate the new ABAP push channel (Web-socket framework) to NW Gateway and allow it to make use of routing features.

But even with ICF services and ABAP Push channels not integrated with NW Gateway, UI5 developer can make use of these features for the scenarios I discussed, and need not always try to fit everything into an oData Entity.



oData/REST is just another language in HTTP world. SAP Netweaver Gateway is the translator tool, translating SAP data into oData/REST language. If that language does not suit you, explore other languages and translator tools.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Atanu Mallik
      Atanu Mallik

          Hello Krishna Kishor Kammaje , this is the feeling that many UI5 developer have when they work with Gateway and I also feel the same at this moment.

      Function imports come with their own capability and boundaries. In OData V4, Function imports come with more power such as payload passing in POST request. However currently Gateway does not support OData v4 and we have to wait until Gateway supports v4.

      Now on the following requirement,

      - All I require is a 'Valid' or 'Invalid' from this functionality

      - Update notes for a Sales Order

      - Get drop down values/ dependent values

      To achieve this you may use a plain function import that does not return anything. However you can send the 'Valid/Invalid' flag in the response header. I know, this is not a proper solution, but a handy one in similar situations.

      Another option to check for such scenario would be to use simple REST service. This a like what you mentioned by "ICF service", developed by the Gateway folks. Situations where you do not like to use the OData services, you may consider REST service. Here you can do GET/PUT/POST/DELETE operation without the any kind of "Grammar Overhead". However this would cost you the additional overhead of ROUTE handling, which anyway you can get by reading the SYSTEM ALIAS tables from Gateway(and maybe a little more).

      Let me know your opinion.



      Author's profile photo Krishna Kishor Kammaje
      Krishna Kishor Kammaje
      Blog Post Author

      Thanks Atanu for the comments and mention of Martin's blog Generic REST enablement with SAP NetWeaver Gateway. That seems to be the counterpart for XSJS service in HANA.

      UI5 developers using SAP as data source should definitely read this blog for alternate options to oData. Out of the box support to use System Aliases and XSRF protection would be an ideal solution.

      Author's profile photo Murali Shanmugham
      Murali Shanmugham

      Good info Krishna.

      Over the last few weeks, I have also bumped into these similar topics.

      1) Need to check if data keyed in SAPUI5 is valid or not  (based on config in backend)

      2) Pull out Drop down value and it dependent values.

      3) Retrieve numeric statistics - For example  - Total number of used Annual leave and Sick leave for each member in the team

      I too had Function Imports in mind to achieve this.

      But after reading the article on REST enablement, I am trying to realize how it could be more efficient approach rather than Function Imports. Can you share some info around this.



      Author's profile photo Krishna Kishor Kammaje
      Krishna Kishor Kammaje
      Blog Post Author

      Thanks for the compliment.

      Let us take an example of validating a Sales Order Creation process in UI5. We had a UI which was spread over 4 steps/screens to create a Sales order. In each screen, there were properties from different entities. Now, when I navigate from first step/screen to second step/screen, I wanted to do some business validations against data in backend. One option is to create entity for each step/screen and use a Function Import. But Function Import as per oData 2.0 does not take request body, so you will end up sending all the data as part of the URL. What if I have hierarchical data? You need several workarounds to pass this hierarchy info. Also when I have data from multiple entities, it is a challenge to send subset properties of each entity for a page. Even if I use outside-in approach to design entities, I would end-up with lots of one-time-use entities.

      Easier approach would be to create a simple ICF service and use POST, and use a json body, and raise suitable exceptions for validation.

      Let us take another example of dependent dropdowns. Consider a set of three dependent dropdowns, where I have Country, State and City. Creating entities for each of these seems a overkill for me. Another aspect is cover data in oData. When I know Country and State, I might have couple of cities to return, which might be of 20 to 30 characters of actual 'data'. But oData would return couple of hundereds of 'cover data' (namespaces, links etc.)  in addition to my 30 chars of actual 'data'.

      There is no doubt that Entities make a lot of sense for QCRUD, they may not be always optimum for all the scenarios.