Is it possible to customize OData response after Create

[PavelPenaz]

Hi all,

When we invoke invoke Create to post data against NW GW, the response includes the listing of the whole entity created - it seems that Read statement is invoked automatically and its response content is provided as a response body for the Create command. Is it possible to customize the Response body? So that it would for example only return HTTP Status '200'? To save downstream bandwidth?

Thanks a lot.

Pavel

[former_member184867 · Accepted solution]

After a CREATE, Gateway Framework does not fire a READ call. The response content is  provided in parameter ER_ENTITY of method /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CREATE_ENTITY of your DPC .

[Former Member]

Hi Pavel,

I agree with Sreehari. While you have a degree of control by altering code, you also need to adhere to OData standards. Ashwin, you might also consider this before offering workarounds that break the standards

The correct response to a POST is code 201, not 200. Stated in both HTTP and ODATA specs.

A POSTed entity is returned by the server (OData spec and to some extent implied by http spec). One reason for this is that the server may transform the body that you gave it, and therefore the state is different to when you sent it, e.g. timestamps, created by user, etc that are based on server-side values and logic.

Regards

Ron.

[AshwinDutt]

Hello Ron,

I think you got me wrong

In the problem statement its written on invoking CREATE - ' it seems that Read statement is invoked automatically and its response content is provided as a response body for the Create command ' .

That means understanding is that Create would be implemented in SEGW by performing mapping by using map to the data source option.

Now we are bound to get a warning ' Mapping of Create operation without Read may cause an error at runtime ' and now this demands implementing Read & would be mandatory.

So When we fire the Create service, after successful CREATE GW will intern call READ and now the response would be 200 OK displaying the data which is recently created as part of Read response. This is how calls will happen as per the standards.

Again its written in the problem statement - ' So that it would for example only return HTTP Status '200'? To save downstream bandwidth? '

That means now understanding is only status code 200 OK is expected and not the data fetched when GW frame work calls the Read as in the problem statement  there is also a question to regarding saving the down stream bandwidth.

Based on the above points my response was ' it makes no sense to forcefully make the response null to just save the down stream bandwidth and display only 200 OK status'.

If at all modelling is done in SEGW and implementation is manually done in Create_Entity in DPC_EXT then Read is not fired and we get  201 Created status with all the details.

My response to the problem statement is not to suggest any workaround which will break the GW Standards and modify the standard response body & HTTP Status.

In fact my response was to convey it makes no sense to forcefully make the response null which intern says not to make change in any standard responses of Odata.

Regards,

Ashwin

.

[sreehari_vpillai]

So When we fire the Create service, after successful CREATE GW will intern call READ and now the response would be 200 OK displaying the data which is recently created as part of Read response. This is how calls will happen as per the standards. 

are you sure about this ?I mean , automatically triggering a read statement on successful creation ! - there can be chances that, I never allow someone to read an entity, but allows to create it. I don't think, it will go for a read operation after a successful create . 

[AshwinDutt]

We have SAP_GWFND 740 SP 05.

The Status would be 201 and not 200. My mistake and sorry for that.

However if you see still the behavior is same.

Behavior which we are seeing is,

When Create operation is implemented through Mapping Operations in SEGW i.e., Through Map to Data Source Option, we are bound to implement a Read as well for the same entity or else at the run-time it dumps.

Framework will look for a Read to perform on successful creation and this will return 201 Status with the data which is recently created. The data displayed is the data fetched as per the Read operation.

If at all you want to allow someone to only Create and never want to allow to read that particular entity then do not use Map to data Source Option.

Model the service using SEGW ( I mean to say define the model ), Generate Run-time Artifacts and manually implement Create_Entity in the DPC_EXT class by inserting the Business Logic.

[sreehari_vpillai]

Pavel,

OData Create operation will return the created record along with the status code. It is OData protocol standard. You are not supposed to manipulate it .

  . I don't think it will trigger a GET operation, but just returns the created record..

Sreehari

[yaripirala]

Hi Sreehari, I'm also facing the same issue. After CREATE operation, system is calling the GET operation and am seeing response from GET, not from the CREATE. Is there any way we can avoid it? Because I need to return the response from CREATE method with newly created record. Thank you. Kishore

[AshwinDutt]

Hello Pavel,

You mean to say you need only 200 OK Status with out any data as part of READ response after CREATE correct ?

May be you are expecting GET operations to work like how UPDATE & DELETE works correct ?

Where only 204 No Content Status is shown in case of successful Update / Delete.

You cannot have only 200 OK Status code as part of response of your GET operations.

You are bound to get the response data as well.

If data is fetched response will have data or else it will be null response.

However Map the response structure with empty data/Null values back to GW in your DPC_EXT class, so that you will not see any data as part of response.

You will see only our entity name as part of your response which is ideally a null response.

But i feel doing this way will not make any sense.

It is always makes sense to expect the response data when you fire any GET operations.

May be if you can explain little more what you would like to achieve, it helps to suggest.

Regards,

Ashwin