Limitations or Redundancy in SAP Gateway Product
I have been using SAP Gateway from one month and feel that there is too much of redundancy and Limitations. Let me brief in points :
1) Entity Relationship
ODATA has an obligatory requirement for a Primary Key Relation between in the input and output parameters of the FM......For instance, if there is a INITILIZATION web service created that calls an FM to export 5 tables in the response , the GET ENTITY SET Query executes the FM as many as 5 times to the get the details which could be done with single execution of FM Here each table is addressed as an Entity which is not apt is what I feel...
I had to use ASSOCIATION to get 5 tables and why would anyone do that !
2)Custom Code in the Methods
When it comes to flexibility and altering a code , the custom code written in the methods ( GET , CREATE , DELETE , UPDATE , GET ENTITY SET ) is erased when the user hits a GENERATE button....
3)Redundant Data Returned
There is a set of redundant data that could effect the JSON response size unnecessarily for instance below....why is the metadata is in reponse....can that be avoided.....
The POST/CREATE web service does a GET method that calls the FM once more with the same data. This redundant code can be commented out but then the regeneration of the code would get that working again !!!
I want know if am following the right standards or am having half baked knowledge in SAP GATEWAY SERVICES !!!
Please let me know if am going in wrong way all together....
1. Not always you can say that there would be no relation between the tables returned by the FM based on some inputs.
Some times yes though no real Association exists between then, we need to model that in a best possible way to get all those details in one call considering the performance aspect here.
Association & Navigation really helps in navigating between different entities.
2. Its the correct behavior that new code is generated in MPC and DPC classes when we do any change to the service in SEGW.
Any custom code to be written has to be written in MPC_EXT and DPC_EXt classes. So that your hand written code will not be erased each and every time you generate the run-time objects after performing some change to the service in SEGW.
3. JSON / XML response is always encapsulated with all those details and this cannot be removed at the GW level and we do not have control over it. Its the standard way that the response comes.
4. READ is called after CREATE when you use ' Map to Data Source ' option for mapping and implementing both Create and Read operations in SEGW. This is the standard behavior.
If you do not want this behavior you can implement only the Create_Entity method in DPC_EXT class. So that only create is called.