oData for Everything? may be not!

[kammaje_cis]

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.

Summary:

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.