Limitations or Redundancy in SAP Gateway Product

[Former Member]

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.....

"__metadata": {

                    "id": "/sap/opu/odata/sap/ywebservice/initAhsWebservice('RETURNLINK')",

                    "uri": "/sap/opu/odata/sap/ywebservice/initAhsWebservice('RETURNLINK')",

                    "type": "ywebservice.initAhsWebservice"

4)CREATE calls

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....

[AshwinDutt · Accepted solution]

Hello Chethan,

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.

Regards,

Ashwin

[Former Member]

Thank You Ashwin and Atanu......

[former_member184867]

Here are my thoughts,

Question 1:Here we are trying to compare two types of models - one is the DB model and the other one is the consumption model. Obviously DB models are vast and offer many features and may not be suitable for building UI unless you directly show the database view in the UI.

Here comes the need of consumption models which are suited for UI designs and behaviors. Entity Data Model(EDM) is suitable for lightweight people centric applications. The model that you see in OData is based on EDM modelling.

It is not always very easy to map the underlying data sources such as FM, RFC, BAPI etc to OData  Model, the reason is they were never designed to cater to OData Services. They were designed to provide lots of information to huge transactions with numerous fields and   cater to complex behavior.

As you are trying to map two worlds there would be open threads. In such cases you need to be careful when you build the closest model that fits your need.

However building a wrapper Z function module around the standard BAPI/RFC and then mapping the Z function  module in SEGW would give you more control.  

Question 2: Ashwin Dutt R is correct. Put your code in _EXT classes. There has been similar discussion in this forum,refer to them.

Question 3: In later versions of OData, '__metadata"' is dropped  to reduce the payload size. It is still not supported in Gateway.

Question 4: May be this is the behavior as you are doing 'Map to Data Source'. I am not sure about it. But if you do a code based approach for CREATE_ENTITY and return the value in parameter 'ER_ENTITY' in method '/IWBEP/IF_MGW_APPL_SRV_RUNTIME~CREATE_ENTITY' extra READ is not called.