SAP Gateway is positioned by SAP as a light-weight, connectivity component which allows all kind of devices to connect to SAP systems (typically ERP back-ends) to work with ‘data’ using the ‘Open Data Protocol’ (ODATA) without a need for any ABAP programming skills.
ODATA is a light-weight protocol built on top of REST (HTTP) & ATOM protocols – it offers the light-weight basic connectivity provided by REST and the semantics & metadata services offered by the ATOM publishing protocol. Combined they provide a light alternative towards SOAP (web services) which tend to become rather ‘too heavy & complex’ in terms of processing … especially for small devices likes smart phones, tablets, etc. ODATA seems to become the new ‘standard integration protocol’ for SAP … It is also supported as a default data model in SAP’s new webUI ‘SAPUI5’.
SAP provides a ‘test drive’ system to play around with this new system so it was about time we got our hands ‘dirty’ and get some insights and experience …
I decided to build a custom data model which would allow me to test most basic functionality and still have some ‘affinity’ & fun with the data… I got my inspiration in the world of gaming (one of my customers) and ended up with the following simple model:
- Games Materials
- Games Families
- Games Categories
I defined the necessary data dictionary elements and built RFC function modules to support the basic create, read, update and delete operations (CRUD) which are typically provided by the REST protocol. SAP recommends using the ‘SAP Gateway Services Builder’ transaction to develop any new (ODATA) GW service.
It allows you to ‘model’ your service and its underlying components and takes care of the generation of the underlying ABAP OO implementation classes for certain standard SAP objects like BOR object methods and/or RFC function modules. The builder works in its typical ‘stubborn’ SAP way but does the job fairly well … it still lacks some fine-salted functionality and is not ‘forgiving’ if you have to change stuff … in some case you’d better delete and restart …
Anyways, I managed to implement my service rather smoothly with ‘out-of-the-box’ , generated code support for the CRUD operations … returning ‘lists’ & ‘details’ for materials, categories & families worked directly ... Creation, updating & deletion took a bit longer to figure out in terms on how to populate the actual content … getting back cryptic error messages did not really help in an easy error resolution. The system provides all kind of error analysis tools but in the end I found myself debugging the core ABAP code to find out why stuff went wrong … not exactly user-friendly.
In general the generated code base works fine for the basic CRUD operations … however once you start digging into the more ‘advanced features’ of ODATA like ‘navigation paths’ or ‘raw media content’ (well not ‘advanced’ for ODATA but it does seem to be for SAP) then you will notice that you are soon ‘on your own’ in terms of coding implementation … SAP provides an API for handling most functionality but the generated code won’t help you in using that … so you are forced to implement your own logic via ‘OO inheritance’ … In my honest opinion though, SAP missed an opportunity here to really use Object-Oriented design principles to their maximum extend … why not use controlled inheritance with protected specialized methods instead of just one big ‘all’ or ‘nothing’ method which is provided now … hopefully this will change in the future.
With some custom coded logic I was able to support ‘the navigation’ from ‘a category towards the materials belonging to that category’ … and to return back ‘a raw media type’ – an image of the game material. Luckily, there are some guides and articles available on SCN that can point you into the right direction (but do note the SP they were written for because a lot changed in how to develop services between various SP).
Overall I believe that SAP Gateway has definitely its place in the SAP landscape and it is capable of providing light-weight ODATA services without any ABAP programming knowledge required. However, the ODATA protocol is not supported completely which might give you some surprises (see various SAP notes for a clear understanding) and you soon end up writing ABAP code if you are up to something more then using the basic CRUD operations based on standard SAP objects …